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."
"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.
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."
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?Yes, but people that have old code with variables or methods named "foreach" (methods being the more likely one here...I have written several classes with a method called foreach()) will still compile with the new compiler. Backwards compatibility doesn't mean that new code will work with older compilers; it means old code will work with the newer compiler.
--Be human.
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.
Pfft, this isn't flamebait. Sure, I don't like Java, is any sort of dissent always some sort of troll? If you like the new for(), be an adult and rebute me, tell me why adding new syntax that is inconsistent with the rest of the language is a good thing. Give me a good argument, and I'd be happy to concede that you're right.
The fact of the matter is that it's a show of the weakness of Java that to add any feature- however small- the syntax has to be extended. More mature languages in the same/similar class as Java can achieve this without adding a new syntactical element everytime some little feature is requested. Smalltalk and Lisp manage fine. Hell, even languages that may be arguable as less mature as Java like Python and Perl can manage to add features without adding new syntax.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
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});