Slashdot Mirror
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."
1. speed
2. speed
3. speed
4. speed
5. speed
6. speed
7. speed
8. speed
9. speed
10. profit
One big thing Java needs is a multi-process VM. Think about it, how many processes does your machine run? Probably lots. How many does a Java virtual machine run? One. Each process has its own VM. While this might have some advantages when it comes to controlling crashes and security, it also means each process has the initial overhead of starting the VM and the continuing overhead of the same duplicated code running in memory for each VM.
Startup time is not only an actual problem, but its gives a very bad impression when just launching a program takes a while. jEdit, a popular Java text editor had to overcome this by attaching to an existing server process. Kludges like this shouldn't be necessary.
If people start writing for new java, then people with old java shall get cut out -- the Windows users, more than likely. They are going to have to get new java on there own, and i'm not sure how many people want to. However, they will likely have .NET forced on them anyway. New Java will just encourage use of C# unless it remains backwards compatible.
it also means each process has the initial overhead of starting the VM and the continuing overhead of the same duplicated code running in memory for each VM.
Apple's JVM implementation for OS X already supports some of the features which you are requesting... For instance, Apple's JVM uses a shared memory space between JVM instances. This significantly reduces the memory footprint of each JVM instance and allows classes to be loaded only once. Example: I launch 2 Swing apps, they can share the same JFC classes, requiring class loading only once. I can stop and start the one of the appilcations without having to wait for Swing to be reloaded into memory.Startup time is not only an actual problem, but its gives a very bad impression when just launching a program takes a while.
Additionally, startup time is really not an issue on OS X. I am writing a fairly complex Java Swing application right now. On start up, it parses 3 (one of which is very large) configuration files, it creates a few Swing components, and finally displays a complex JFrame to the user. Total time for a cold start (no other JVM loaded) is approximately 2 seconds. That's certainly not slow. Not Sun needs to take a look at what Apple did and implement it back across their JVM implementations.
One big thing Java needs is a multi-process VM.
I don't really see what the advantage of this is. Again, the JVMs from Sun and Apple both use native threads. On most platforms, thread creation is less expensive than process creating. This is why Apache 2.0 is a hybird muli-threaded/multi-process application. Apache used to run a multi-process only model and it bogged down on Solaris b/c of process creation overhead. The new model overcomes this by using threads more heavily. As long as the threads take advantage of native thread features, like _____, thread use is most likely more efficient than process use.
BTW, on Linux, there is no real difference between a process and a thread, so Sun's JVM is already "multi-process" on Linux. And it's not any faster than their other implementations. As a matter of fact, Apple's JVM blows away Suns implementation on Linux and Windows (I haven't been able to test against Solaris).
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
> One word - ew!
Why ew? Because of your limited programming experience with languages where this was eschewed?
In general, in computers, closure is a good thing. Ask any functional programmer. Ask any language theorist. Closure is good. To simplify closure, I am referring to having rules that don't have exceptions. Having a uniform representation for as much as possible.
In LISP data and code are stored the same way, as lists. This is the ultimate closure. Other languages implement other closures like having all data types be of a common type.
> What you really need is generics (as in C++ templates).
Lord God NO! Don't you EVER use C++ templates as an example of generics again. C++ templates are an attrocity. What you want is generic methods with multiple-dispatch. Look at Lisp's CLOS, or Dylan.
> However, that wouldn't make all Java programs "object-oriented programs",
Explain? How can you write a Non-OO program in a Pure-OO language? Cause, you see, it's not possible. You can write a program that isn't in the OO style that you think of when you think of OO. But you can't write a program that has data that isn't an "object" in a Pure-OO language.
> I have a suspicion that it might impact things like the JNI too
JNI would be as fine as it is now (yuch). Even the "float" class has to have an internal variable that actually stores the float.
Justin Dubs
Multiple inheritance has major problems (if both superclasses have the same function, which one do you use?). A much better answer is often to use "Composition", where the class you are writing contains both of the superclasses that you want to extend, and have your class manually delegate to which ever one of the classes you want to perform the operation. See the "Inheritance versus Composition" section of "Design Pattern" for more details.
Operator overloading
I agree that it is a shame that this was not included. The usual arguement against them, that it's very easy to change the semantic meaning of an operator and this can confuse developers, is just as applicable to an "add" method, but I don't think it's a devastating loss to the language.
Pointers and direct memory access:
Ye gods. No. The moment you start doing this is the moment Java stops being cross platform, and this is a far more important feature than the extra performance that you could squeeze out of it with direct access. Since they sorted most of the performance issues out, I've rarely seen an app where there was any noticable issue in the speed of the actual java code at all (speed of DB link/RMI from overuse of EJBs are much more likely to be problems and unlikely to be sorted out with direct memory access. If you really need to do it, then write that bit in C or assembler on your native platform and call it using JNI. It's messy, but it makes sure that you really think about whether you need it or not.
You seem to have missed the biggest C++ related ommission from Java - templates. The ability to create typed arrays using a single line is something that Java would really benefit from.
> > One word - ew!
:)
:))
> Why ew? Because of your limited programming
> experience with languages where this was
> eschewed?
Nope, just flamebait
> Explain? How can you write a Non-OO program in
> a Pure-OO language?
I'm not sure what your question really is here, and you seem to have answered it yourself. You can take your problem, use structured design / functional decomposition to come up with a solution circa 1980, then implement it in Java much as you would do in C. A single class, with many methods and members (hell, make 'em static while you're at it)... no polymorphism, no inheritence, no data hiding, no application-level abstraction.
You can go one step back up the ladder and pretend to be using Pascal/Modula2/Ada, using classes as abstract data types and providing simple access functions. Still not what most people would call an "object-oriented" program.
Remember, design *is* programming. A program which deliberately avoids the object-oriented features of its implementation language cannot be called OO just because it "contains objects". A good language is one which allows the programmer to express him/herself in the most suitable way for the problem being solved. If a developer has to find "ways around" a particular feature of the language, then that language is flawed.
Me? If I was asked "what is the most harmful programming construct", I would choose type casts every time - yes, even over gotos and pointers.
As you've probably guessed, I like C++. I tried Java and didn't like it. Therefore, I am just ranting bitterly and should be ignored at all costs.
These sigs are more interesting tha
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:
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
Overflow errors are a well known problem - well-written software should not suffer from them.
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.
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.
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.
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.
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.
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).
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.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
As another noted, the JVM is already capable of running multiple processes on Mac OS X. Fix the JVMs for GNU/Linux, FreeBSD, Solaris, and those obscure, mutually incompatible operating systems from Redmond :-), and let others fix (or replace) the language.
Concentrate on the JVM.
Already Python can be compiled into java bytecode, and if the capability doesn't already exist for Ruby, it will soon. Similar compilers could be created for any number of other languages (scheme, smalltalk, whatever).
Java isn't what is important, it is the write (bytecode) once, run (bytecode) anywhere that is important. Whether that bytecode is generated from Java, Python, Scheme, Ruby, or Joes New Language For His CS210 course, doesn't really matter.
The Future of Human Evolution: Autonomy
10 ) Ok, but what about moving to a better system where you can compile against a specific version. Try to compile agains 1.3 with methods that were depreciated and it will fail.
9 ) Ok, within the java API the naming convention should be consistant. Outside of the API it's the programmers decesion. To dictate a style of writing would place an undue burden on programmers
8) No, not on your life. You can take my primitives from my cold dead body. If you want to suggest that primative should not be used in most production applications that's fine, but their is a time and a place for priatives that are very important. Suggesting that we get rid of primatives severly hurts your credability.
As for your comment about 2b + 2b != 4b... No shit you add two SIGNED 32bit values and expect it to work properly despite the buffer overflow! BigInteger is part of java.math and is a perfedt counterpart to Integer, but can be as big as you want.
7) Um, mabye. Chars are already expected to represent string and I doubt there would be much resistance to having a JVM decide how big those should be. It's not like he's trying to suggest that short should be changed ( oh... yea ).
6) I can see some cleanup here. Threadgroups could go away and 99.9% of people would not care. As for the non-atomic nature of 64bit+ primatives that has alwyas been clearly documented in the spec. It does not guarentee atomic operations on anything longer than 32bits. Although this could be changed it was always a trade off between the smaller systems and the larger systems that java would be running on.
5) No, please, no more bloat. XML is great, but to continue to add LARGER API's with memory hungry requirements to the system is a death sentance.
4) Smoking the BAD crack. AWT has it's warts and problems, but just look at mozilla on the MAC for all the reasons that native widgets should continue to be supported at all costs. I would not mind an alternate WM/WT as long as it had true native peers so that java can participate as a first class application on all platforms. AWT currently is poorly designed to handle the diffrences between OS's and take advantage of the niceties on some platforms, but that's no reason to abandon native widgets.
3) Java has two sets of collecations. Ove that was based on 1.1 ( Vector, Hashtable ) and one for Java2 ( List, HashMap ). Anybody that's bothered to read a performace tuning book would realize that the Java2 collection system ( although without generics ) is by far the better system. The Java2 system allows either synchronized or non-synchronized operation. This is because the vast majority of java collection use is internal to a class or method where syncronization just adds a burden to the system. Why use a beartrap for holding your desk pens when a cup would work just as well.
2) Yes, count me in. The I/O subsystem uner java it totally inoperative for many tasks. A RFE currently pending ( for several years ) is to adda simple way of finding out how much free space is availible on the filesystem. Metadata information is a casulatly of war. It just needs to be tossed out.
One thing that he doesn't hit on, but it a REQUIREMENT for interoperability is some standardized way of doing fixed block decoding/encoding ( think struct ). It's just amess trying to get complex binary structures into and out of java without going quite mad.
I don't agree that Streams should be buffered by default as that can CAUSE problems. Buffering should alwyas be under the control of the programer.
1) Yes, it's already known that the current class loader has some issues, but they are working on a better one. There is no reason to throw the baby out with the bathwater. Many advanced programs are running into problems expecially when they are using custom class loaders.
But.... he didn't even mention quite a few issues I have personally with my big pet peve being....
The GC. Many programs need some feedback and some wat to hint or force the GC of specific objects ( since they peer with NATIVE blocks of ( memeory/code) ). It's very important that the programmer be able to programmaticly control SOME operations of the GC subsystem. I'm not asking for malloc/free, but there are some objects that can be a pain to work with and some programming requirements that cannot be achived under the current GC system. It's a black box without any feedback. I would like to be able to tell the GC when I have 10ms where I know the system's time would be better spent cleaning up after itself to go ahead nad do it. I need to be able to force the cleanup of specific classes/instances when they are holding on to native resources.
Anyways..... I think I've rated enough. I can see where this guy is comming from, but most of his points are whining or ignorace of the system.
10. Java 2 isn't big enough.
9. Cool 3D-glasses marketing gimick potential
8. We can all complain more when MS doesn't support it.
7. Library need another complete overhaul of the GUI classes.
6. Add in all of the C/C++ features that we're left out.
5. O'Rielly can sell another series of books (how about a fungus?).
4. Since all of the people who know Java 2 are unemployed, this project will keep them off the streets and out of trouble.
3. Java doesn't have enough incompatibility issues as it is. We need to level the playing field.
2. 'Cause the alternative is caving in to C#.
1. Emacs is better than vi.
Someone you trust is one of us.
From the article:
This article imagines a "Java 3" that jettisons the baggage of the last decade, and proposes numerous changes to the core language, virtual machine, and class libraries. The focus here is on those changes that many people (including the Java developers at Sun) would really like to make, but can't -- primarily for reasons of backwards compatibility.
In other words, Elliotte fully understands *why* his proposed changes would be difficult to implement. His 10 changes are contingent upon the assumption that you can break backwards compatibility.
It doesn't seem totally unreasonable to me. Microsoft forces people to upgrade their OS in order to support newer versions of their Office product. While I'm definitely not a Microsoft advocate, I believe that forced upgrades aren't necessarily a "bad thing."
Assuming Java 3.0 were implemented and backward compatibility was broken, Sun wouldn't pull the downloads for Java 2.0 off their websites. Moreover, a magical wave of energy won't wash over the planet halt'ing all Java 2.0 and 1.0 applications and permanently erasing their JDK installations. The 2.0 and 1.0 Java applications would simply become "legacy" code until such time that they are either replaced or updated to the new Java 3.0. In fact, it would not surprise me if a significant number of the apps were not migrated (because they were not judged important enough to spend money to upgrade) and continued to execute under the old Java.
The authors of Java 1.0 and Java 2.0 applications didn't have the benefit of coding under the "3.0 conventions". If the applications they wrote could really benefit from the changes, the authors will go back and refactor. If not, the application will continue to run in it's current form for years to come.
Upgrades are like refactorings. While toothless ones are trivial, they rarely provide significant benefit. It's usually the difficult upgrades (EJB 1.1 to 2.0?) that provide real opportunity for advancement. The 10 proposals by Elliotte seem like an example of the latter.
Do it for da shorties
I love Java's simplicity, and wouldn't mind to keep it as it is (although I WOULD adopt the proposed changes for Java 3), but the following is what drives me nuts: Three COMPLETELLY different ways to get the length/size of things:
myArray.length
myVector.size()
myString.length()
It also drives me nuts having to convert all the time between the primitive data types and the Object data types (int/Integer, long/Long, etc).
Other than that, even with its current flaws I simply have to love Java (I guess is like being married to someone who is not perfect, but that you wouldn't change for anything in the world...)
10. Delete all deprecated methods, fields, classes, and interfaces.
While I would also like to see these die, to tell the truth, Java has done an above average job here. In most other (should I qualify that as "practical") languages, there isn't even a concept of deprecated. Deprecated is your client calling you up and telling you something is breaking in a weird way and you say "oh yeah, don't use that". In Java when you deprecate something it means something. The compiler compiles in a flag, and anything that is built against deprecated methods, the compiler will spit out a big fat "THIS IS DEPRECATED" warning. You can't do much better than that. So while I'd like to see these things gone, the reality is that there is a lot of code that is using them, and they really aren't doing much harm. The most "harmful" are the deprecated thread operations. Everything else has mostly been for name changes or additional functionality. Take the most out of your own eye first and all...
This is just a library issue, not a language issue.
9. Fix incorrect naming conventions.
Amen. Given that we adhere to whatever we resolve to do with deprecations, fine. But again, Sun has done a terrific job, and if you look through the libraries, I'd say 90% or greater (including deprecated stuff) adheres pretty well to the standard. Again, this is just a library issue, not a language issue.
8. Eliminate primitive data types.
What you want is "boxing" (like C#/.NET/CLR does), and they're already working on it: RFE 4609038 Request auto boxing of primitives in Java.
7. Extend chars to four bytes.
Meh. I don't use Unicode that much, so it's not as relevant to me, I'll trust you on this one. Just don't bloat up good ole US-ASCII character strings.
6. Fix threads.
I generally agree. The first 5 bullets are pretty trivial. I have never ever run into a problem when using threads, even with complicated synchronization implementations. The last bullet is already possible: write your own damn monitor! Nobody is stopping you as long as the sychronization primitives work. Here I'll give you a clue: custom monitor implementations. Easy as cake. I'm not sure what the author is really asking for here. Sun cannot possibly make every single implementation of a monitor somebody would like (ok, well, it *could* but why?). It gives you the primitives and you go from there. That is why you are a programmer.
5. Convert file formats to XML.
No no no no no no NO. XML is not a panacea. Please DON'T turn everything into XML. The formats that exist (properties format, manifest format) are simple and designed for their purpose. XML has its uses, and simple, flat, non-hierarchical, terse data, which has absolutely no expectation of being rendered visually or translated into another form, is not one of them. I don't see any REASON being proposed other than "everybody is using it". Well, if everybody jumped off a bridge...
4. Ditch the AWT.
Meh. I have a better one. Replace AWT with a natively back-ended Swing or Swing-like API, akin to IBM's SWT. Swing is a lovely API, but it is cumbersome to lug all the libraries around, and it is slow. SWT is a nice compromise (nice high-level abstract, generic, Java API - to the metal native implementation).
3. Rationalize the collections.
This is basically an argument against the deprecated classes, for which there are already replacements. I don't see much wrong with the Collections API (i.e. java.util 1.2+), and when generics arrive, it will be much more useful (no tedious subclassing or casting to contained type). The author is making some fuzzy argument that the Collections APIis not cuddly enough or something. It's a starting point - it has the most used structures (hashtable, linked list, growable array, etc.). If you don't like them, feel free to subclass or write your own. They are fine for me, and certainly don't rank up at 3 as far as complaints to Sun go.
2. Redesigned I/O
A bunch of non-arguments here. Again, for something like 90% of the time, this is going to do you just fine. Please DON'T sneak buffering into classes which do not announce this fact. This is the charm of composition, and I think it works nicely. Want a stream buffered? Wrap it with a buffering stream. Want a stream GZipped? Wrap it with a GZip*Stream. Anyway, there IS a new IO API, which promises much better performance (introduces asynchronous I/O), java.nio.
1. Redesign class loading from scratch, this time with human interface factors in mind.
Agreed. This is getting to be a headache. Especially when deploying in application servers/servlet engines that have their own custom classloaders. There probably isn't a good solution other than good documentation, and reduction of unnecessary conflicts when security is obviously not an issue (the whole reason of seperate classloaders to begin with).
Summing Up
Well, this article is largely gripes about the library not the language, and where it gripes about the language, those gripes are already being addressed. I would complain about things like, methods not being first-class objects (callback classes are really annoying), unspecified symbol resolution in the language spec, inner classes not being allowed to have static declarations, lack of enumeration type in the language itself, interfaces unable to declare overridable fields, array types being pseudo objects when they could instead be easily made to be real objects which could be subclassed, etc.
It's 10 PM. Do you know if you're un-American?