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

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

[abies]

I'm surprised to see that there are still people out there which use 'interpreter' argument...

Anyway, there is a plenty of native compilers for java. I'm not sure if you have heard about certain compiler from free software group called Antilope or something like this - I think it is called gcc. They have a frontend for java, gcj, which compiles java source/bytecode to same intermediate stage as other compilers, thus sharing optimizing backed. If you don't care about paying few bucks, JET is very good compiler, written specifically for java, supporting 1.4.1. There is also few others, but I can tell only about these two from my experience.

Both these compilers are available for few years now. Problem is not with lack of native compilers, or performance of java in mixed mode offerred by Sun hotspot - problem is with mindset of poster. If you are not willing to use java - no problem. But please say it is 'religious' - everybody will agree with you, as you can have any beliefs you want. But do not try to back up religious statements with fake arguments.

Re:good and bad ...?

[bramez]

but wouldn't it be nice to try and keep the java language *simple*?

isn't syntactic sugaring all about making code more readable? I think boxing , generics, typesafe enums, static imports make the java language more simple to use.

It's just looking over the fence to the "sibling" languages (c++, c#) and copy what they do better.

Re:Too litttle, too late.

[mrright]

"Without seeing (in the Java source code) how the templates are implemented I can't say that I agree or disagree with your statement that they will be inefficient, though I'm inclined to disagree based on your example."

Slashcode swallowed some brackets even though I was in text mode :-(

What I mean is the following: If you create for example an ArrayList of ints, the most efficient way to store these ints internally would obviously be an int[] and not an Object[]. But even though java uses templates, it still stores primitive types such as int in an Object[], so there is a huge temporary object creation overhead. Whenever you store an int in your IntArrayList, a new Integer object is created on the heap and an old Integer object has to be garbage collected. In .NET you just store a 32bit value in an array, which is a single operation on most processors.

The .NET templates will create a different class for each primitive type, so that primitive types will indeed be stored in their corresponding primitive arrays without creating objects on the heap. For classes, the .NET implementation behaves similar to the java implementation: There is only one internal class created for all reference types.

"Templates or not, objects are going to be stored the same way. The difference is how those objects are retrieved. Right now you have to cast everything coming out of an ArrayList (unless the Object reference is sufficient)...not only is that being moved to the language but you also gain compile-time type checking. That will only serve to reduce errors and make the software more reliable. Templates are optional anyway - you don't have to use them. I'm looking forward to them."

Me too. It is not that I dislike the new features. I just think that they could have been implemented better, faster and earlier.

"I don't think you're ever going to see VM sharing. If applications can share VMs then one rogue app could bring down other apps by trashing the VM (never supposed to happen) or by poor thread management."

VM sharing does not mean that all java programs must run in one process. But for most desktop applications this would make a lot of sense. You are right about the thread management, but you could always restrict the number of threads an application can create. Just have a nice XML file which describes how much resources each application may allocate. That is the way .NET does it, by the way.

If sun will not do VM sharing, you will never see decent client applications written in java. Just think about it: for each java application you start, the whole swing library has to be JIT-Compiled anew. What a huge waste of processing power!

Re:The problem: Improving programmer productivity

[MSTCrow5429]

JavaScript has nothing to do with Java, other than their similiar names. JavaScript, originally LiveScript, "was renamed by Netscape marketers who licenced the name to ride Java's Buzz" (Wired, July 2002, pg. 61). Javascript is actually an offshoot that sprung from both C++ and ANSI C (C89). JScript and ECMA Script sprung from Javascript.