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."
Java is becoming more like Python!
At least *I* think it's reason to rejoice...
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've already seen this language.
...
Except it was called C# and didn't have such a crufty set of libraries
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.
So, to summarize the changes:
...
...
...) construct. Second, (dolist ...). Third, (mapcar ...) and family. Four, defmacro, which makes these superficial things all seem kinda silly.
1) C-style enums, because Java is too weak to support a true symbol type.
2) Enhanced for-loop for iterations.
So:
for (String s : c) {
}
Is now shorthand for:
for (Iterator i = c.iterator(); i.hasNext(); ) {
String s = i.next();
}
They did this, of course, because it was the least obvious, most ugly way possible to add this to the language.
They said that it seemed "too late" to add a new keyboard to the language, but apparently not too late to add new syntax.
The principle of least surprise tells me that something along the lines of:
foreach (String s, myStringCollection) { }
might be a bit easier to read than their seemingly random for( : ) syntax.
3) Autoboxing to automate the wrapping of Java primitives in classes.
This seems to be because Java didn't want to go pure OO. They wanted to keep their primitives, and yet be mostly OO, which turns out to just be a pain in the ass and gives rise to classes like Integer and Double.
4) C++-Style Templates, because Java would now like to get even closer to their goal of being "Almost all the power of C++, without any of the speed." Templates are pretty much a bad idea in any language. They are a work-around for a bad type system.
But then, what the hell do I know. I'm just a Lisp junky.
For the curious, the Lisp solutions to these problems are, in order:
1) Symbols.
2) Too numerous to count. First, the (loop
3) What? Variables with types? I don't understand! Variables don't have types, values have types!
4) See #3, plus true generics in CLOS.
Justin
... 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."
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
zero_offset: any books you would recommend on .NET or C#?
- 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 nice thing about the syntax of Lisp is a design feature essentially boils down to a new function or library.
The bad thing about the syntax of Java/C/Perl/etc. is that a design feature is a design feature, adding to the complexity of the syntax.
"You can't pass primitives by reference in Java so the function:"
//the object byref //the same as java, class data byref (but not the object) //data byval //o is only in the function scope
in Java you can only pass the class data byref not the object.
void setmyclass(Object o){
o=somthing;
}
Doesn't work, o is passed byval, the data in o is byref.
C++ allows lots more stuff
void setmyclass(Object &*o){
o=new Object;
}
void setmyclass(Object &o){
o.value=123;
}
void setmyclass(Ojbect o){
}
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.
Someone made an alternate proposal:1 1/27.html#a 113
http://radio.weblogs.com/0108103/2002/
I can see a few kinks in it, but overall it's a great way of adding "foreach" without intruducing any backwards incompatibilities
Does anyone know about the status of true multidimensional arrays in Java?
Just curious--last I knew they were being considered but hadn't made it into any of the specs.
for ( c : i ) { //blah blah blah
}
foreach $c (@i) {
#blah blah blah
}
I can't wait! Next thing I want:
System.out.println("YES!") if (a==b);
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
Perhaps reading Modern C++ Design would show you that templates are much much more than just generic types.
On the other hand, expecting a Java programmer to trade simplicity for power is just futile. Likewise, asking them to learn something hard to produce something great is likewise a waste of time, they are much more set out on the learn something easy and produce something mediocre mindset.
A conforming C++ compiler is Turing complete, which means you can basically compute anything computable at COMPILE TIME, not just in the binary it produces.
It's official. The flame wars have begun.
It didn't take very much digging but in order to save others time who might be looking for it, I found the 'official' JSR for these items:
http://jcp.org/en/jsr/detail?id=201
The JSE is implemented as preprocessor. Why wait for Sun to add new language features, add your own.
Has there been any word about how difficult it would be to add support for such features to GCJ? Any word regarding how long it'd take for such support to be added?
The features being added to Java are mainly features from C# being copied in an attempt to keep Java as popular as it has been. If one wishes to use C# with the JVM and Java class libraries, however, the GNU Portable.NET project has a compiler available.
The truth about Michael
I think it's a bad idea, even if it is easier.
...." actually means something.
One of the most important things in coding is readability. Frankly,
for ( String blah : bleh)
doesn't really say anything on it's own, the reason they call it a programming "language" is because it reads like a language.
"for , string c colon f " means shit.
"for string s equals c iterator
Please god don't butcher this language.
--noodle
Is it just me or does the news icon thing for java look less like a steaming cup of java and more like a overflowing garbage can of steaming shit?
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.)
I like the new language features a lot. Let me preface this with, I am a big Python fan, and Jython has most if not all of these features already (I am the author of a Jython book by Addison Wesley).
Generics make sense, and they look a lot easier than C++ templates.
The new for construct, also make a lot sense (very python like).
As well as the new auto boxing feature. (Why should I have to worry about this..... let the compiler do the work for me!)
My opinion is that if the compiler can figure it out, then why bother me with it.
Make the compiler smarter so I have to type less.
Less code that I write means less code I have to maintain!
Back before Java became popular, I was a C++ bigot. I programmed in nothing but C++. I lived, ate and breathed C++. If it wasn't C++, it was rubbish. I thought C++ was the alpha and omega of object-oriented programming. I had "operator overloading" for breakfast, "templates" for lunch and "multiple inheritance" for dinner, and I always went back for seconds.
Then a funny thing happened. I got a new job at another company as a C++ programmer. But they pulled the old bait and switch. Once I started working, someone suggested writing a good portion of a large project in a scripting language. I protested - I would not condescend to program in any other language but C++.
Shortly after I started at this new company the following edict was put forth: "Thou shall use a scripting language." Thus I was forced by management to write a good portion of the project in a high-level scripting language. They told us to glue components written in C++ together with this scripting language (in addition to writing components in C++). At first I hated it, as any self-respecting C++ bigot would. Then, gradually, the productivity of my team - and me - skyrocketed!
The higher level you can make Java, the more productive it will be. These features they are adding make so much sense to me.
I hate purity for the sake of purity. I dogmatically dislike development dogma. Life is full of compromises. There is no pure Java langauge... Let Java grow! Let it become higher level. Heck, there are a few features from Ruby that I'd like to see Java adopt.
I am not saying that Java should one day be like Perl. I think things have to be added judiciously, but let the language evolve!
rick hightower dot com