Preview of Java 1.5

gafter writes "An early access prototype implementation of the proposed new J2SE 1.5 language features is available. The prototype includes generics (JSR 14), typesafe enums, varargs, autoboxing, foreach loops, and static import (JSR 201). In other words, all the new language features planned for 1.5 except metadata (JSR 175). The prototype includes full sources for the compiler, written in the extended language. You can download the prototype from java.sun.com. It requires J2SE 1.4.1 and provides some examples of how to use the new language constructs. The prototype includes an experimental type system (variant type parameters) for Generic Java that is being considered for Tiger (1.5) based on a paper by Igarashi and Viroli at ECOOP 2002 . Comments and votes for the new type system are being gathered at bugParade."

Comments

good and bad ...?

[bubzer]

Some of these things are certainly nice (typesafe enums...) - but wouldn't it be nice to try and keep the java language *simple*? There are iterators for doing stuff like foreach-looping ... varargs? Why? It is an object-oriented language - take use of that polymorphism!

Re:good and bad ...?

[cookd]

Iterators should not be used to replace the counting case:

for(i = 0; i < count; i++) { ... }

You can use iterators for this, but (depending on the implementation) it is likely to be slower, since the object in question must create an iterator instance.

Iterators should be used (in fact, are pretty much a necessity) on types that are not easily indexed, such as hash tables or linked lists. As long as the Java language doesn't have support for iterators, developers creating non-indexable container classes have to design and implement some kind of iterator themselves. With language support, the language enforces a particular design (making programs more consistent) and provides help with the implementation.

Yes, it is sugar, but it is useful sugar.

Varargs are also sugar. You could always just make the user create an array of objects as the variable parameters. But that takes a few extra lines of code for each call, and confuses the purpose of the code. You have to deal with the distraction of constructing an array instead of dealing directly with your problem.

Varargs makes a few tasks just a little bit simpler. It doesn't add any functionality, but it adds convenience.

CallStoredProcedure(db, "MyStoredProcedure", param1, param2);

Isn't that nice and simple? Syntactic sugar, when used appropriately, should simplify life for the programmer. In my opinion, "sugar" is appropriate if it provides a clean way to do something that would have been messy before. It should be avoided if it provides two equally good ways to do something. In the case of varargs, I think both criteria are met. In the case of iterators, the first is met, and the second is met as well as long as developers understand when iterators are appropriate and when they are not.

Sounds like what C# has that makes it better...

[Anonymous Coward]

Surprisingly (!!!) all the things C# had (or will have - generics) that made it superior. This is going to be fun seeing these two compete. So far I am on the C# side but who knows :) this is really fun.

Simplicity lost

[abies]

While, as a java developer, I'm looking forward to most of these changes, I'm a bit afraid that java may lose it's positions as simple OO language which can be used for teaching in schools. Java was originally built with idea that you can read every java program in the world without problems. A lot of expresive power was sacrificed because of that - most notable preprocessor (to avoid people designing their own 'languages' for each project and library, as it is done in C).
Anonymous inner classes was first major ugliness which came into language - not very clear, hard to explain to a newcomer. But with all these new proposals, significant complexity is added to code in terms of visual overview. This is not critical for developers - perl hackers are faring very well, despite of having language 10 times as complicated as java as far as syntax is concerned - but pure-OO, java-is-new-pascal-for-algorithms academic society will probably start looking for a new language soon... (ok, maybe not really 'academic', I'm thinking more about secondary-level school programming basics).

Interested in learning more about these generics

[smittyoneeach]

You could troll and say that Java has finally caught up with where C++ was better than a decade ago.
More constructively, maybe the implementation will improve on things from all that time and experience.
Java is the best defense against the .Net onslaught. Good luck, Java.

Generics

[The Bungi]

There's an apropos article over at kuro5hin. Well written, I think.

It seems to me that languages like Java and C# really don't need them.

Re:Generics

[be-fan]

One thing I never understand about anti-C++ rants. Where's the beef? All I see is a whole bunch of hand waving and vague references to pseudo object orientation, incoherency, etc. No real meat at all. So from my point of view, some real evidence:

1) C++ is a systems programming language. The lack of pointers would make it entirely unsuitable for that purpose. For normal use, you should use references or smart pointers. Not doing so is no excuse. Using a C-style array when you don't need it is akin to deliberately writing an infinite loop. It's entirely the programmer's fault.

2) The object model doesn't lack anything that Java's model has, except introspection (which is fragile at best). If anything, Java's model is equally broken, because everything is not an object. What exactly about the object model is missing?

3) What's wrong with the C++ syntax? How is it that different from Java's syntax?

From my POV, peoples' biggest problem with C++ is that it doesn't prevent you from hurting yourself. That's okay. I hate all the consumer protection bullshit, and Nader and his "don't run with scissors" party, so I have no problem with my language having some teeth. I do a lot of low level programming, and I find that C++, more than any other language, allows one to do that will still maintaining a high level of abstraction.

Is the single instance of VM in?

[Kjella]

...because there's nothing like running a 2kb calculator and a 2kb notepad and both have them run on separate 10-15mb VMs. That is a real drag for any non-monolithic use of Java (yes I do know of servlets etc.)

Kjella

Dylan

[oodl]

Sounds like they are adding a lot of features that the Dylan programming language has had since it's release (approximately 1995).

But whereas the features were elegantly incorporated into Dylan since the beginning and are consistent and easy to use, I suspect that in Java they are a hack.

Wasn't Java designed to be a simple language?

The problem: Improving programmer productivity

[BjornStabell]

These additions seems to put Java on par with C#, but to make a quantum leap in expressiveness you need a dynamically typed scripting language.

Most applications these days can be written in higher-level languages, resulting in 5-10 times less source code compared to Java/C#, and making them correspondingly simpler to code and maintain.

Java doesn't really have a kick-ass companion scripting language. In MS world, VB plays this role. VB is really popular, but (I think most people would agree) a crap language and not really that high level. JavaScript just doesn't seem to cut it (pretty much only used in browsers).

Why doesn't Sun take a hint and phase JavaScript out in favor of a powerful multi-purpose high-level language like Python or Ruby? That'll put them miles ahead of Microsoft in terms of increasing programmers' productivity... and programmers' quality of life.

Re:Java Vs .net

[Billly Gates]

Speaking of mercy and fud responses from the pro .net/mono crowd you can always mention the SCO effect. Corporations obsses with legal costs and potential lawsuits. Company Image is not something that is easy to get back if its hurt. This is important when picking a solution

Most major corporations who are planning on moving to Linux if they have not done so are cancelling and puting their plans on hold thanks to SCO.

If you use mono at work assuming its mature enough and ms pulls a sco you can kiss your linux workstation goodbye.

According to MS halloween documents, legal fud got a negative response form %80 of all bussinesses.

More Wrong Choices

[ChaoticCoyote]

I program Java for several customers, from scientific to business apllications.

Autoboxing is yet another way of hiding overhead; the wrapper classes still exist, but are now a big "secret" masked by autoboxing.

Why add autoboxing to make containers look more "natural with POD types, then ignore the crying need to operator overloading in scientific and engineering applications? Why one piece of syntactic sugar as opposed to another?

Overall, I'm not terribly impressed. The new generics seem weak; I don't see an emphasis on fixing bugs, stability, or independent standardization. Much as I like Java, 1.5 does not address most of my needs.

Re:Why a Large Bank Junked Java

[bokmann]

I'm tired of hearing that 'java isn't used in real-world applications", then some stupid example touted as proof. Java is used in plenty of real-world scenarios. The U.S. State Department uses java, and so do a large number of countries around the world to aid in the export control of nuclear, chemical, biological, and other hazardous materials.

Re:I'll care when native compilers become the norm

[Glock27]

Buuuuzzzzzz! Wrong! Nu-uh!

That is impossible. Java has to do the same as the C code, plus the extra overhead of doing the JIT. There is no way Java can be "as fast".

Ah, the "impossible" word. ;-)

You're presuming that the ahead-of-time compiler can "know" everything that the JITC can. That isn't true, in many common cases.

Another point regarding JITC compilation is that it can be for the exact target processor, something not typically the case for traditionally compiled programs.

All that said, current JVM performance certainly varies between 'better than C++' and 'worse than C++', with pathological cases in both directions.

The current 1.4 JVMs actually took a hit on some math operations, though that is supposed to be fixed in 1.5.

I hope gcj gets to the point where it supports the latest language spec. The libraries are tougher, and many of them aren't needed for interesting projects. For certain applications, an ahead-of-time compiler is nice.

By the way, for a good example of a 'fast' Java program, check out Eclipse from www.eclipse.org.