10 Reasons We Need Java 3.0
Subject:   Commercial concerns must not be ignored!
Date:   2006-08-28 05:19:39
From:   Infernoz
Firstly, never, ever assume that you can have unlimited resources, that is childish and unreasonable! Engineering, financial, operational, social and cultural issues can and do delay resource upgrades, often for many years!

10, 9 & 4. This would be suicide for a programming language, from a commercial and OSS library viewpoint, thus is not a smart suggestion.

8. Primitives are needed for efficent use of the CPU and memory, especially on slow or heavily loaded commercial machines. Putting huge extra load on the Garbage Collection, memory resources and the method call layer is not a sane suggestion. It is also not smart for the compiler to pick the data-type given this could cause unpredictable value overflow/underflow or performance problems if the wrong data-type was picked. Enums are a great idea (for new APIs or methods), but not where you have combined flag field values (an API design flaw).

7. There should be an application visible JVM to enable 4 byte characters/strings, with a system property to signal this feature, so that the JVM and application can switch to 4 byte character optimised libraries and convert constant character/string values, when classes are loaded. It would be stupid to enforce the change in byte-code because it would not be commercially viable.

6. stop() is critical for killing hanging or badly coded threads e.g. threads which ignore interrupt(), so must be retained in some form so that limited resources can be freed. Doubles and longs are a JVM concern, if you don't like the atomic behaviour put them in a synchronized object. Anyhow I dislike floating point data-types like doubles because they are so vunerable to decimal rounding errors and lack rounding rules, unlike BigDecimal, not a good thing when money is involved!

5. XML is suited for some uses, however it is very slow to parse, can be huge and has to be read from the start! I work with data from an XML based system and have seen quite serious performance problems with it, because of huge XML data size (in databases (uncompressed) and across networks (compressed)) and high marshalling/unmarshallings costs! Use of other formats, like CSV, is much more efficient in databases and networks, and they tend to compress better too. IMHO use of XML for settings files is useful in some cases, however I can often do better using standard properties and a Properties sub-class supporting heirachical text propeties e.g. store.9999.tills=2,

3. ArrayList is broken, because like many other java.* classes it has too many private properties, this makes it useless for some applications which require ordered lists e.g. some Swing lists applications! I would like to see all Lists include a locally optimised sort method and an ordered add method, because the Collections.class methods are often far too costly!

2. IO should be improved and this is happinging already, however I don't want File changed, tieing access to physical files would cause all kinds of resource and locking issues, you really don't want to go there!

1. Shows that you are naive about ClassLoader security and the need to isolate dynamic class compilation and loading for application like web servers etc.

I like some of your books, however they are not perfect, some of the IO books are flawed e.g. copying files with streams and a byte, instead of java.nio FileChannels, yuck, I REALLY hate cruft like that, at the very least use a large byte array rather than a single byte!