10 Reasons We Need Java 3

An anonymous reader writes "This article on O'Reilly Network (written by one of the most active Java book writers ever, Elliotte Rusty Harold) has some interesting points about the need for a new 'cleaned up' Java version, made to incorporate the advances in the last 7 years of its life and without the requirement to keep compatibility with old versions."

Comments

Re:The "most controversial" proposal

[Westley]

What you really need is generics (as in C++ templates). Java collections are vile, since they suffer from type loss even when used with "real" objects. I'm surprised that didn't come into this top ten; it's a major language deficiency.

The article was about what can't be built on top of Java2. As Java2 (in 1.5) will be getting generics, I'm not surprised this was left out of the article. I believe there may well be some automatic boxing if you wish to use it, e.g.

List<Integer> x = new List<Integer>();
x.add (5);

but it's all up for debate at the moment of course...

Jon

Some observations

[Twylite]

This is a refreshing view on changes to Java, because it doesn't make the traditional calls for templates, a preprocessor, and operator overloading. Most of the article is well considered and logical, and should be implemented in a move to Java 3.

There are however some issues with which I must disagree:

• Under the discussion of primitive types, the author proposes that the current wrap-around handing of primitive types is incorrect. Mathematically, yes - but not in computing terms.
  While the overhead of promoting all primitive types to objects may be insignificant, the overhead of checking all arithmetic for overflow does have the possibility of causing significant overhead.
  Not only that, but you will still end up with a RuntimeException, because you cannot expect ALL arithmetic to be in a try ... catch block. So all this becomes is an aid in debugging or forcing a crash (rather than progress based on an invalid computation) on a live system. I have to question whether the performance trade-off is worth it.
  Overflow errors are a well known problem - well-written software should not suffer from them.
• Still on the primitive types discussion, I don't believe the author has considered the impact of using an arbitrary-size number computing which does not require such numbers. The performance overhead is potentially huge, and you lose the ability to performance a large number of optimisations based on the fact that you are dealing with a quantity of a determistic size (in memory). There are also threading and synchronisation considerations, which I will discuss later.
• The byte type is unfortunately defined in Java. It should be unsigned, to begin with. It is certainly necessary for many IO operations, and data encoding/decoding; moveover it would be preferable if bytes had the special property that aritmetic operators converted other types to bytes (even if data loss was involved) rather than vice verse.
  Many Java developers are caught by using code like b = (byte)i; rather than b = (byte)(i & 0xff);. It is generally true that when dealing with bytes, you want to keep data as bytes until you explicitly make it into another type.
  Finally, byte arithmetic should always overflow, as is expected in CPUs.
• Last note on primitives (and it applies to 4-byte chars as well): the assumption we are afforded by Moore's law does NOT apply as the author suggests. Rather, what was designed to run on a low-end Sun or 486 Intel PC is now expected to run on a 1Mhz 8-bit CPU with 32Kb memory.
  While J2ME is not fully Java-compliant (no floating point support, for example), it still largely conforms to the write-once test-everywhere rule, and this is part of Java's attractiveness.
• Onto the size of chars. This is a bit of a tough one -- which it would be nice to have a 4-byte character, I have dealt with several Java applications which were very String-intensive. They could gobble up 256Mb RAM in a matter of seconds. A 4-byte char only worsens this problem. It is even doubtful that a char object (as opposed to primative) would help, given the overhead that would be associated with the object (at minimum a type and representation lenght - you're back at 4 bytes again).
  More memory is not always a good solution. Java's garbage collection architecture is very wasteful of memory at the best of times; at the worst of times you are using immutable objects like Strings, so you can't pool or reuse the objects. As increasingly more applications handle text because of our new XML obsession, this situation becomes worse.
• Threading next. I have studied Java's threading model in some detail, including the issue of non-atomic longs. The problem comes down to one of efficiency - again.
  Java implementations typically do not emulate threads on their most common platforms - they make use of the native threading model of the operating system. This means that making a 64-bit operation atomic must involve the use of a lock; so instead of a 64-bit operation taking up 4 times the time of a 32-bit operation, it could take that plus two calls into kernel space.
  As mentioned before, the same is true of using arbitrary-size numbers. Only a number that the CPU can treat atomically will result in an atomic operation without additional synchronisation.
• With regard to monitors, I fail to see the need for multiple monitors per object. Every object is a monitor, and Java syntax provides for implicit synchronisation on the current object as well as explicit synchronisation on an arbitrary object.
  Thus, to have different types of operations (all implemenented in one object) synchronised on different locks, simply use each in an explicit synchronisation block and have private or protected lock objects specifically for that purpose.
  Decoupling monitors from objects would kill a lot of the ease-of-use that makes Java threading such a pleasure by comparison to many other models.
• On the other hand, there are many weaknesses in Java threading. It lacks a strongly-defined policy for thread scheduling, which can make the design of complex multithreaded applications very difficult.
  Furthermore it ONLY has monitors as locking primitives, which rules out the use of overlapping locks, which are one of the few effective synchronisation primitives which can overcome weakly-defined scheduling.
  Java would do well to add an additional synchronisation primitive - either mutexes (as error-prone as they are), or interlocked increment-and-compare (which can solve a number of synchronisation problems far more effectively than mutexes).
• Onto the XML question, and getting to my area of pet hate: The XML Silver Bullet.com. The author's bias towards XML is understandable, but he needs to realise, as do the millions of developers who let the marketting machine think for them, that XML is a poor implementation of a decent idea.
  For a better critique of XML take a look at http://www.eastcoast.co.za/twylite/pml/pml.html" >my anti-XML page (incomplete, but the anti-XML rationale is presented).
  In particular, XML is a very poor choice for the encoding of Java objects, because of its lack of terseness, and the relatively slower speed of parsing XML - both of which impose significant penalties in a distributed environment.
  Some hard facts to back up these claims: in an application I have worked on, we experimented with SOAP instead of our original binary protocol. The result was a 80% decrease in call rate.
  In a few years, the XML phenomenon will wear off, and world+dog will wonder why we are wasting our precious bandwidth on all the overhead. Already WS developers are starting to wonder how it will affect their resources, and we have proposals for a binary encoded XML for the mobile world.
  This "simple" specification is too complex and too overkill for most tasks, so every "lightweight" XML parser on the market conveniently leaves out certain parts of the specification - be it DTD, PI, CDATA, whatever. We already have XML documents that aren't compatible between two parsers, the situation will only worsen.
  And in the end we will realise that it isn't necessary to make computer data human-readable, because really, everything is just a bucket of bytes and a rule on how to view it, and XML is a very, very poor rule.

Java is not perfect. It is not a silver bullet, and it is certainly not everything to everyone. Instead, it offers an environment that, to a lot of people, is a damn sight better than C++ because it avoids the error-prone complexities and power of the latter. But you must accepts its weaknesses as a trade-off.