Slashdot Mirror
Sneak Peak at Java's New Makeover
SadatChowdhury writes "Aside from templates as already reported in a past slashdot article , a little snooping around revealed the details of the following newly revealed features in the upcoming release of Java 1.5 (codenamed: Tiger) : Autoboxing , Enhanced-For-Loop, Enumerations and Static Imports . Must read for Java fans."
In related news: jdkane writes "Sun Microsystems delays a much-anticipated Java specification by three months to comply with guidelines designed to keep Web services interoperable. Says Ralph Galantine, group marketing manager for Java Web services at Sun: "We thought that this change was important for the industry, so that there was no conflict between J2EE 1.4 and the WS-I, "We thought it was worth taking out to the summer." It's very refreshing to hear that a big software company is looking out for the industry, instead of just their own."
Possibly the "most different" feature that will probably come in. Here.
I'm not too sure I like them, as they do add a completely new and different and more cryptic syntax to Java, but I can definitely see the use for them. No more clumsy casting when you retrieve something from a List.
Daniel
Carpe Diem
I am in awe of the new for() statement. Instead of all that fooling around with the C-style syntax (great for procedural, sucks for OO), they just go ahead and adapt it for collections much like iterators in other high-level languages: for (String s : c) { //do stuff on s's in c
}
Wheeeee!
ph34r teh p0w3r 0f th3 c0w
There are some other interesting changes coming to provide a more coherent memory model, vastly improved concurrency support, and intra-JVM application isolation. Java is getting much better at providing access to the capabilities of the underlying OS, and the JVM working more like a little multi-process OS itself...
Larry
"Autoboxing"
Hmm... extremeley Microsoftesque. Much like VB5 and 6's variant data type and C#'s boxing rules.
Seriously, with a language like C you can feel like you actually know ALL the rules, and it makes you feel safe. With the beasts that are VB.net/VB6 and C#, and the one that Java is becoming, you always have that lingering "What If" in the back of your head. Seriously, you end up programming with the idea "Nah, they wouldn't let me make that mistake" constantly in the back of your head.
I for one will like the new features Java is gaining. All too often when programming in Java for school (the main place I use Java), I often find myself wishing and wanting some of the features of C++. I've even gone so far as to write a perl script to allow me to create my own templates and have it convert the template to a proper .java file. Has anyone else resorted to this hack?
On the other hand, Java still is not my preferred language. C\C++ will probably always be my language of choice. They are what I learned first, what I enjoy programming in most, and which I plan to never quit using. Being able to use several design paradigm's is extremely nice, which is why my other favorite language is OCaml. However, I am still picking up its nuisances so things are subject to changing.
I would like to know, however, why the professors at my school bash C and C++. I for one can see the weaknesses of the languages, yet I can also find weaknesses in many other languages including the languages of functional and declarative paradigms. I think a lot of their disdain for C and C++ are due to memory management. However, manual memory management has never really been a huge problem with the way I write my code. Anyone else care to respond on if this is an academia thing to hate C and C++ or just my school? Perhaps all my teachers have their heads on tripods just like the people they complain about. Especially since, they do not work to try and improve the current programming languages.
Reserved Word.
... a terse notation for anonymous inner classes with one method.
// do the operation // with a terse notation for one-method anonymous inner classes that could become
// do the operation });
anonoymous inner classes can be used a little bit like blocks in ruby, only the syntax for anonymous inner classes is so verbose. Imagine this:
ArrayList list = new ArrayList();
ArrayList list2 = list.map(new UnaryOperation() {
public object call(object o) {
});
ArrayList list2 = list.map({ |object o|
It may not be possible because the exact interface to implement in the anonymous inner class would have to be derived from the method being called, which might be overloaded.
Anyway, I'd love to be able to use the terse rubyesque style in java, it feels a lot more declarative and communicates much better than all the explicit looping in java, c, C++, C#, VB, VB.net etc.
Nothing like a little competition. Notice how we go for years with Sun assuring us that the language is "just fine, trust us, we know what's good for you, you don't, all you need are more libraries, you're not a language designer but we are, trust us, you don't need any more features in the language itself, you just don't get it....".
C# comes out with a better language, and suddenly for the first time since inner classes were added in the mid-90's, the language starts evolving useful C#-looking features....
What I want next from Java is for Sun to invent delegates and properties.
Competition is a wonderful thing, and it's good to finally have some in the Java space.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Wait, LISP programmer?
Ah yes. You can always spot them from far. May the Lambda be with you, brother!
(Btw, I completely agree with you. Always a challenge to move to bracy languages from LISP)
More than mere navel gazing.
Most of the new language features are copying or implementing similar to the C# features Sun has persistently decryed!
... same as boxing in C#
... well both languages have/will have generics now ... still not 100% convinced but prefer to have them than not to have them ;-)
... C# has them same as C/Pascal, now suddenly Java is getting them (are they going to revisit the library and clean up a lot of their class constants into enums now??)
... being able to add custom metadata to any method/property, for example how to serialise to XML correctly, is great!!
... competition is great for Java!!!
Autoboxing
the for-iterator [for(Sting s: Collection)] statement is actually "nicer" (in that intent is clearer from the code) in C# [foreach(String s in Collection)]
Generics
Enumerations
I propose they go full how and add the extremely powerful attributes from C# as well
In short
- templates from C++;
- a new style of emun that does everything the Pascal enum does with a syntax that looks like a C enum except that it can have methods, AND MORE;
- a whole new foreach syntax that has the stellar advantage that the syntax doesn't resemble anything on God's green earth except Smalltalk, which is a pure prefix language like Lisp instead of an algol block language like C, C++, Java, C-hash, pascal or Ada (where the other features come from);
- generics using the template model from C++, which was a horrible hack on top of C++ because it was hard to make a backward compatible syntax (so instead we got ANOTHER class of macro to add to the #define) when C++ was a horrible hack on top of C so that at least C++ could compile C programs (except now it can't);
- a grammar that is going to be about LL(497) (doesn't anyone remember how ugly parsing C++ got to do templates, and how long it was before it worked?);
- and a whole wonderful new term ("autoboxing") for the notion that primitive types and class types ought to both have all the properties of types.
I know I'm probably just getting old, but Jesus!, why do we need to repeat all the mistakes of the past?Just like one of the top requests for enhancement in the Java bug-parade states, covariant return types could have done most of the work of Generics without the additional clumsy syntax. (i.e. sub-classes could override return values of overriden methods to return sub-classes of the original return values instead)
overall, I'd rather have this than nothing...
The poster is a little off in calling the new feature "templates", and you're correct in calling them "generics".
Templates were C++'s way of simulating generic types. The difference is that templates are essentially macros in fancy clothing, and generate a different flavor of the class for every combination of type parameters, while generics are a much cleaner, more abstract construct, better grounded in the theory of types, which use polymorphism to achieve their genericity.
Don't know if that made any sense....
In any case, this will be a fantastic feature, and they're done a much better job with it than C++ did with templates.
The colon syntax is not random. It's well-known and well-understood mathematical notation, namely Zermelo-Frankel set comprehension notation:
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
I mean, you can always do:
...
Iterator i = obj.iterator();
while (i.hasNext()) {
}
If you need a count, then add it at the top or bottom (depending on need) -- This just seems like syntactic sugar gone awry.
So is there some kind of strange, dark, Mason-like secret society which causes people exposed to a sufficient amount of Lisp to think that Lisp is the One True Way, and other languages are correct only to the extent that they are completely identical to Lisp?
OK, OK, I'm just griping -- and I actually, I really like Lisp quite a lot -- but I do think that sometimes it's easy to judge by familiarity, and Lisp pundits seem especially guilty of that.
There's rarely a single One True Right Way of implementing a language feature; we really need to judge each implementation in the context of the language it's implemented in, and look for a clean, consistent, orthogonal, well-closed meshing of the feature into the language's feature set.
With that in mind, to your items:
(1) The new Java enums are not C-style enums at all (nor are they Lisp's symbols). They are a special variant of classes with a stronger class-level contract than normal classes (a fixed instance pool being the big one), an approach which works very well in an OO language with strong static typing. (For those of you following at home, Lisp is, for the most part, a dynamically typed language.)
(2) Lighten up. The for(x : c) syntax is lovely to a Java programmer's eyes, and fits the existing constructs well. Lisp's approaches, unsurprisingly, fit Lisp well, but wouldn't make much sense grafted into Java. I am glad, however, that Lisp also solves this problem. That is good to hear. Thank you for sharing.
(3) Java's original designers had two concerns: first, primitives are a potential performance gain; second, the semantics of arithmetic get sticky when integers can be null. Other language (e.g. Smalltalk) have addressed these problems reasonably well, but it's still a very debatable issue.
If I had it to do myself, I'd probably not have introduced primitive types. However, as a Java programmer, what really matters to me is that they pick an approach and make it consistent. The autoboxing JSR does a good job of adding convenience without breaking this consistency, IMO.
(4) The only similarity between Java's generics and C++'s is in the syntax. Java's generics are "true" generics in the sense that they spawn new types, and rest on polymorphism instead of a sort of specialized macro expansion. (C++'s more macro-like templates make sense for C++, where static binding would preclude many aspects of Java's approach.)
I'm not quite sure what your complaint about them not being "true" is supposed to mean. Perhaps you're worried about the runtime typing semantics of generics? If so, I'd like to see you hold your own in an argument with Gilad on the subject.
But then, what the hell do I know. I'm just a Lisp junky.
I think the answer is fairly obvious: you know a lot about Lisp, and not enough about Java to be as opinionated as you are. I know much more about Java than Lisp, and I'm sure I'm guilty of the reverse.
But I don't think I need to be an expert in either language to say that we should judge each in its own context. Does C suck because it doesn't have lambda expressions? (If you are tempted to answer yes, I hereby sentence you to writing device drivers for three years.)