 |
Search |
 |
|
|
First Class Java: Call of Duty 4Posted by evanx on March 25, 2008 at 4:24 AM PDT
So i had this vague idea some weeks ago for some blog articles to keep myself amused if no one else. The idea is... to dream of a Java Refined. Not something totally different like JavaFX Script, or Scala et al, but some kind of evolution of the Java language that would be dreamy with a dollop of double-thick cream on top... So i started making a list of things i would want, which went something like: first class properties; first class meta stuff like methods (FCM), fields and what-not; better annotations; better generics; structured literal data (eg. XML) and queries and what-not in the language; first-class handling of externalised data like localisable text and customisable what-nots.
Anyways, i remember that when i looked at my list, i thought, what i want is "first class" this that and the other. So i thought lemme call this exercise "First Class Java." But enough about me, what about you - how would you evolve the Java language? I'll collate all ya all's ideas, mind-meld them into some kinda concensus of me, myself and you, and write them up in some ongoing fashion for further consideration and discussion, just for the hell of it... Having said that, if i win the lottery, i'll sponsor a team to create a slightly new, very Java'esque language with Netbeans support et al. To be honest, first i would buy myself a few first-class houses, sports cars, jets, yachts, etcetera, then after i've bought all that, i'll sponsor some first-class schools and clinics and what-not in my country (hey i also wanna help Obama make the world a better place), and then after that, i'll sponsor First Class Java with the petty change. Heh heh. »
Comments
Comments are listed in date ascending order (oldest first)
Submitted by tompalmer on Thu, 2008-03-27 15:20.
Rather, I meant "finally" (the keyword) is vital everywhere.
Submitted by scolebourne on Tue, 2008-03-25 14:44.
I think that there is definitely a desire in the wider community for a 'better Java' - something that fixes the flaws in Java but is 90%+ compatible. First Class Java isn't a bad name either :-)
It will include all the favourites like properties, method/field/constructor references, value classes, better string handling, more literals (but not XML). It would also handle nulls properly (non-null by default). The key however is for it to instantly be readable by a Java developer - existing developers must be able to make an accurate educated guess at each piece of the new syntax.
Submitted by tobega on Tue, 2008-03-25 15:08.
- more support for immutable objects and pure functions. A little marker on each method that mutates state would be nice, too.
- pattern matching, something like:
match(n : inputStream.read()) {
n == -1: blabla
n>=0: blabla
}
plus a way to mark the return value(s) of a method so that you are forced to pattern-match it.
Submitted by edsonw on Wed, 2008-03-26 06:50.
The Pizza Language (http://pizzacompiler.sourceforge.net/ ) implemented Generics, function pointers, case classes and pattern matching. The Generics idea was imported (almost with the same syntax) by Java 5.0; why don't import the other ideas as well?
Submitted by aberrant on Wed, 2008-03-26 08:43.
I also vote for properties and method/field/constructor references. I've messed around with FCM and found it very productive. From that experience I feel that properties will also be very useful.
@scolebourne - I'm unfamiliar with the term "value classes" could you explain a little? Collin
Submitted by scolebourne on Wed, 2008-03-26 09:19.
By value classes I mean simple final, immutable classes. In particular == could be defined to mean .equals() for value classes. In a way they have some of the functionality of enums, but where the developer has to still write some code. Example uses are date and time, but also Integer/Long/Double and Complex. Basically the aim is to make writing simple immutable 'value objects' easier.
Submitted by tompalmer on Wed, 2008-03-26 23:11.
Scolebourne is right on the money in many cases. I'd also add that the checked exception model needs reworked or removed. I've learned several languages from before and after Java, but I've never seen another with checked exceptions. And it's not for lack of people being exposed to Java. I know it's a polarizing topic, but any "better Java" needs to make it easier to deal with errors correctly. And I'm absolutely convinced that even just making checked exceptions go away would do that.
Side note on the "==", that should always do a fancy "equals()" call, for all classes, just like Groovy. It's just that implementing "equals()" for non-value classes is an anti-pattern.
Reified generics would be great, but sadly incompatible until the JVM supports at least the runtime generics info for all generic classes/functions. You can't be better "Java" and have ArrayList work differently from classes defined in the new language (where type info could technically be secretly stored). Failing JVM support, all generics really should be just considered that covariant casting is fine. Make wildcards an endangered species.
The FCM vs. BGGA thing is vital since to "look like Java" might require looking like whatever syntax wins for Java itself in this arena. Unless the popular forking happens now.
For "better Java" to win, it also might need Sun's blessing before too long. And it definitely needs strong IDE support.
Finally, I'd recommend that Kijaro would be a great place to start the "better Java" (just watching for trademarks, of course). Just impose the incompatible rules based on a compiler switch or perhaps a different file extension.
Submitted by tompalmer on Wed, 2008-03-26 23:13.
Oh, and a primary goal needs to be that "better Java" should be simpler than Java. Fewer rules for beginners while staying better for experts (again without more rules).
Submitted by evanx on Thu, 2008-03-27 00:07.
thanks for the comments - please keep them coming! and please point me towards any literature/proposals i might incorporate in this exercise eg. to blog about further.
I doubt i will implement anything, not even a code convertor/generator (from an "enhanced java" to regular java), or Netbeans module providing some convenient views, and certainly not compiler changes, cos i don't have the time or skills.
What i would enjoy doing is dreaming about and writing about an impossible ideal i.t.o. beloved Java :)
Submitted by aberrant on Thu, 2008-03-27 08:03.
@tompalmer
You are right, exceptions is a polarizing topic. I have the opposite opinion. I believe RuntimeException should go away, but I'd never push for that. I've just had to deal with one too many 3rd part libraries that decide to throw RuntimeExceptions instead of actually telling me something could go wrong. Then errors happen in the field that can't possibly have been planned for. I do agree that some of the pain could could be removed. The is why I want A reusable exception handling system.. It would allow one to create standard ways of dealing with checked exceptions. If you choose to re-throw them all as RuntimeExceptions great, have fun. I want to be able to handle a specific type of error condition once and never have to write the code again.
Collin
Submitted by mikeazzi on Thu, 2008-03-27 08:11.
On the specific issue of "improved generics", which I very strongly support, I particularly like this piece by Howard Lowatt on artima.com. It argues for simplifying generics by removing wildcards, and making generic parameters co-variant by default like arrays are. I really like that. We've got to put an end to what's termed "generics hell" painful experience in Java that's mainly caused by wildcards.
Submitted by tompalmer on Thu, 2008-03-27 08:20.
Also, if you have easy multi-line strings, replace JavaDocs with annotations. No need for redundancy.
No need for named parameters if you have good object literals, like Groovy. Groovy operator overloading is also the best idea I've seen along those lines.
Also, get rid of public fields (at least without extra pain). Appearing to declare a public field should really just be generating getters/setters - and a private field if not abstract (or in an interface). Both Groovy and Scala do this nicely.
Another last thought. I'm not a big Groovy user, but a lot of their thoughts have been "how can I make this better than Java while still looking like Java". Backporting much (obviously not all) of that into "better Java" would not necessarily be a bad idea.
Submitted by tompalmer on Thu, 2008-03-27 08:26.
@aberrant/Collin - The way I look at it is, "Life is exceptions, and anyone who says differently is selling something." (Well, maybe not quite but movie references are worth using sometimes anyway.) Or rather, Java requires you to always assume that an exception could be thrown at any time. And I don't there's any realistic way to get around that. I've never seen anyone do better in any other language either.
Submitted by aberrant on Thu, 2008-03-27 10:26.
@tompalmer - Given your assumption every line of code would need to be wrapped in a try catch block. Why then would you want to remove checked exceptions? The try catch block is going to be there anyways. The only reason to remove checked exceptions is to be lazy and not care if something goes wrong. Anything that can be caught by the compiler is a bug that will never go through the test/report/fix/submit process.
Submitted by tompalmer on Thu, 2008-03-27 15:19.
Right. I think people (including myself) are lazy. I also think exceptions shouldn't be caught. Except by default at the top of the control loop and also in specific circumstances when you know why you want to catch an exception. If you know when and why, you'll take care of it correctly. If you don't, you'll corrupt data. Finally, on the other hand, is vital everywhere, and that's one reason why closures (or ARM blocks) are so important.
|
|
|
||
What is the point of this exercise you ask? To have something to think about and doodle about when i'm in my favourite coffee shop, and a topic to blog and converse about like now.
Now i can't remember all of my wishlist exactly because i left it at home and i'm quite literally a thousand miles from home at the moment...
|
