Isn’t that the same as saying being stuck on 1.4 since your app is still running on Tomcat 4?

The fact is that BEA Weblogic Server 10 has been released and it (of course) supports JDK 1.5. Heck, even Weblogic 9, which has been out for quite some time, supported JDK 1.5 and even took advantage of some JDK 1.5 specific features. E.g. annotations for webservices, using the XML parser from Java 5, etc. See http://edocs.bea.com/wls/docs90/notes/new.html

Again, some ultra conservative businesses simply never upgrade any of their software (e.g. banks still running on mainframes dating back to the 70-ties), if you’re in such a business the blog obviously doesn’t apply to you. But for companies that ‘merely’ have a 1 year behind or 1 version behind policy there is very little excuse not the use Java 5 (including upgrades for the layers on top of it).

Most companies however have a one year behind or one version behind policy, instead of a 5 years behind or a 3 versions behind policy.

Also, websphere itself is certified for running on JDK 5 since more than a year. See the info page about Websphere 6.1 (2006): http://www-306.ibm.com/software/webservers/appserv/was/features/

The thread-safeness issue could be attributed too to not being able to code to an interface (so a specific thread safe implementation can be passed in). On the other hand, arrays have a small advantage in thread-safeness when iterating over them. Even the best internally synchronized collection requires external synchronization when iterating (even when only readers access it). E.g. Collections.synchronizedCollection’s Javadoc states: "It is imperative that the user manually synchronize on the returned collection when iterating over it"

Since for arrays the index is by definition managed by the code using the array (and is thus not internal to the array), it’s thread-safe to iterate over a shared array when you can guarantee that only readers access it.

The reifiable types issue is a good point too. I typically blame Java for this because of the type erasure. I.e. you also can’t do a new T(); so it feels only logical you can’t do a new T[]; either, but it’s a very practical disadvantage for native arrays indeed.

There is a small workaround for this though, involving java.lang.reflect.Array.newInstance. This workaround does require that code that binds generic parameters also passes a Class object in.

E.g. instead of writing something like: MyStructure<Foo> ms = new MyStructure<Foo>();, you would have to write MyStructure<Foo> ms = new MyStructure<Foo>(Foo.class); Inside this structure you can then use Foo.class to create a new instance and cast it to a T[]. I know it’s not pretty

I agree that native arrays should as much as possible be treated as a ‘deprecated data type’, although they shouldn’t be banned from the language. Data structures (like ArrayList) of course still have to use it for their internal workings.