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."
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
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
I agree with you fully when it comes to VB and Java, but C# does not deserve to be lumped into this category. Everybody knows VB wasn't really "designed", it just sort of "happened" over the years. Java had a lot more design work behind it, but it still suffers from weird evolutionary lumps that always "feel wrong" when you're using it. However, C# went through a very long and intensive design period, with more well-defined goals than Java (the set-top-box language), and I believe with a LOT more R&D-phase input from the real world (as anybody who participated in Don Box's .NET listserv discussions can tell you).
C# is a lot like C in that the language itself is limited and well-defined, although not to the extreme basics of a 12-keyword universe like C, owing primarily to the additional keyword overhead needed to express certain modern concepts, many (most?) of which are OOP-related. In that sense it's a little like C++.
For an experienced programmer, the trick is to first understand the .NET class hierarchy (hint: avoid books that harp too heavily on web services buzzwords; web services are just a few pieces of the very large .NET puzzle). Next, understand the C# language on it's own. Most of the books out there seek to tackle both of them simultaneously, and that's a big hinderance to learning, and probably what causes people to make statements like that made by vandel405, above.
Don't judge the subject matter by the quality of instruction...
Slashdot quality declines as the number of hot grits posts decreases. - Provolt's Law, Apr-09-2005
I am in awe of the new for() statement. Java was designed to be logical and readable, but unfortunately for (String s : c) means nothing to most developers.
The JCP is a classic case of committee design: everyone has their own ideas based on their experience, and doesn't really understand the purpose or path of the Java language. Most JCP suggestions are calls for Java to look more like C++ or Python.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
- 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?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});