With the introduction of generics, as well as the other features of Tiger, the Java language will take a fundamental leap forward. However, the emphasis on backward compatibility is weighing it down.

For example, the introduction of enum types is a major revision in the java language and many constants that are now integral option constants should be revised to use enums. Yet we cant make these changes because of backward compatibility.

In a similar mode, and more on-topic, the various parts of the JDK that take varing kinds of collections as arguments should be revised to do so in order to make the JDK more solid and less error prone. Yet once again we are hessitating to do so because of backward compatibility.

If you combine this with other massive and apparent flaws in the JDK and add up other more minor flaws in the JDK design, I wonder if we are going in the right direction with backward compatibility. At some point we will need to snap the rubber band holding us to JDK 1.2 and revise the language and JDK completely to account for modernizations. If we fail to do so, we risk turning the JDK into a similar mess as the MFC classes for C++ windows programming; namely a mess of trying to advance the technology with tons of backward lint.

Is generics pushing us into JDK 2.0; a new version of the JDK renovated from the ground up? More importantly, is Sun willing to go this route and invest the resources needed to accomplish such a conversion? If not, how can we justify the risks that ignoring these problems place on the long term longevity of the language when faced by other challengers to the programming language kingdom?

C# is still no Java but they are developing the language on top of the lessons learned in Java. If we cant morph Java to learn these lessons, we will be caught and overtaken by C# and its power marketing by Microsoft. If it is so heavily used in its infancy, it makes me wonder what its power will be when it matures.

Generics is one of the best things that has happened to the java language but it also exposes the age of the JDK. There is a lot of decrpit and cancerous code in the core and I believe we should come up with a strategy to resolve these problems before it is too late.

 

 

I totaly agree with you. IMO the libraries get "uglier" with each release, just because there have to be backwards compatibility which prevent Sun from correcting old ugly design-flaws. One thing for instance which really anoyes me, that although the generics class are checked at runtime, there is still a runtime-cast added to the classfile. I don't know if this is because of backwards compatibility or just because of bad implementation of sun, but I suspect the former.

Why cant sun go they way you suggested and release a Java 2.0, with a totaly new or at least heavily optimized and corrected class-library? They can do this and still mainten the "old" 1.x-branch.

 

 

If we started hacking into the JDK, a vast amount of existing code will break. This is definitely not a good thing.

There is a mechanism for gradually moving the platform forward: deprecation. Old interfaces can be deprecated and new interfaces introduced. Versions of the API which omit deprecated methods can easily be generated, allowing a small and simple view of the system for new programmers without gratuitously breaking old code.

In the particular case of enumerations: it is very easy to use method overloading to add an additional enumeration-aware interface to existing code. Methods which formerly took an integer enumeration can now take an instance of a new enum class. The old method would then be deprecated, and the use of the new method encouraged. This allows 'cleaning up' old interfaces without breaking stuff.

Further, a lot of attention has been paid to allowing generics to 'retrofit' existing code so that new parameterized types can be added without breaking existing users. Varargs have a similar nice property. This is the way to continue to move the platform forward.

 

 

True, but then you don't have to use the new 2.0 version. I would see it like implementing new features also in older 1.x releases, but mainly in the 2.0 release, but there makine heavy use of new features and getting rid of old garbage. So you can smoothlin convert from 1.x to 2.x. The only downside I see is that 1.x JVMs cannot execute 2.x Classes anymore.

A good example for where exaggerative compatibility can lead is Windows 9x/ME. If Microsoft didn't develope NT/2000/XP alongside of developing 95/98, so I now can choose a from the ground up new system (NT-Kernel), which can still quite compatible to the old one (Dos-based). If I still had to use Windows 9x today, I would do this only for gaming and the rest of time I would work with Linux. But since Windows XP is really stable, there are much less reasons for switching to Linux that they were if Windows 9x running on plain old dos would still be state of the art.

 

 

The downside is that people who've written huge apps for Java 1.x won't be able to use new features of 2.0 without updating large chunks of their app.

You may think this updating is easy, but (if we're talking about more changes in Java 2.0 than converting a few ints into enums) it's not. My company recently updated a major C++ app from Mac OS 8/9 to OS X, which is a vaguely comparable situation, since this involves switching from the Mac OS 8/9 API to the Carbon API which is a quasi-subset of it. This update, plus all the bug-fixing it created, took a substantial proportion of the time taken to write the original app!


Yes, Win NT is much cleaner internally than 9x, but from the application developer's point of view Win NT's API is pretty much a superset of 9x. This means converting an app from 9x to NT is little or no work in most cases. You're talking about making Java 2.0's API a subset (or partially subset, partially superset) of Java 1.x's. This could mean a lot of work for a lot of people using Java, unless they leave their apps marooned in Java 1.x.

 

 

People seem to be missing the original point. Sure, those that dotn want to invest the effort in 1.x to 2.0 conversion will have marooned applications. On the other hand, if we continue to move slowly in this manner, C# and other technologies will rapidly get ahead of Java and eclipse it. So do we choose a dead language with spaghetti for a development kit and twisted source code base that makes even the strongest cringe? Or do we choose to move forward the language into the future. You cant have both.

Backward compatability is the bane of software engineering progress. As the JDK accumulates more backward compatibility, it will gain such bulk that moving it forward will only be possible with enormous expenditure of resources. In addition, the corporate programmers will abandon Java in droves to opt to implement in the more sleek and modern C#. No, its not as good as Java now, but what aobut in 5 years when Java is a huge ball of twisted gum and string and C# has learned the lessons of the JDK and moved forward.

So the question really comes down to "Do we modernize Java or should we all go get a C# book?"

 

 

There are certainly some RFEs out for changes to the API which are fully backwards compatible but are still waiting - things like changing all those Swing Vector parameters to be Lists. Even getting those done would be a good start.

 

 

That's exactly what is NOT needed if you do what I said, namly that implementing new features in BOTH trunks (at least in beginning), but doing this in the 2.x versions in a munch cleaner way. This would mean for instance, that generics wont need a cast in the 2.x versions anymore or that all libraries use now enums instead of int-constants. So you wont miss features in 1.x but youll miss good design and better performance.



No, I really don't think so :)



Hmm. That's a valid point. Maybe sun's first step should be cleaning up internally but still maintaining the same external interfaces.

 

 

Sure, Sun can clean up the API by adding improved methods (e.g. using enums not ints, Lists not Vectors) and deprecating the old ones. And they should.

But as soon as they remove any public methods from the API it will break some apps - unless those apps stay stuck with the old version of the API.

There might be something they can do which is cleverer than deprecating old methods - they could gradually make it more and more painful to use them. E.g. first a method could be deprecated normally, in a later version the compiler could emit stronger and stronger warnings about it, perhaps later still some kind of runtime warning could be generated (!!) so users know their app is getting old, until finally Sun could delete it from the API.


Point taken, but IMHO I don't think those casts are going to disappear. The VM knows almost nothing about generics. In Java code, List<String>.get() returns values of type String, but from the VM's point of view the get() method in List.class returns Object. So you need to cast the return value if you're going to call any String methods on it.

Don't worry - casts are apparently very fast now (1 processor cycle I think?), so even if you do a million casts every second, your app will only slow down by 0.1%.

 

 

THAT would be real fun :)



Hmm. I thaught I heard of a generic implementation with could generate a specialised class for each generic. So a <String>-List would not contain an Array of Objects but of Strings, and the get would always return String, so no cast would be needed. I hope Sun would implement something like this, becaust it would not only speed up cast, but also array-acces (which is faster for spezialised-arrays).



Ok, thats true (at least for recent VMs), but its ugly anyway.

 

 

Great idea, but I don't see any reason to call it "Java", except to build on the existing marketing hype.

 

 

Im not suggesting the invention of a new language. Im sugesting cleaning house with the current one. It is like a house of a pack-rat right now, filled with rubbish and dirt. Its time to spring clean or to give up the house as condemned. C# is gaining hype and momentum and "positive thinking" is not going to be able to counter that.

 

 

Yes, but if its not backward compatibile, why should one call it Java at all?

 

 

Because the language is the same? Because the API is mainly the same, expect for the optimizations? Because it would confuse people if sun released a new programming language? IMHO it would be VERY bad to give it another name than java. Best would be calling it Java Version 2.x. Or 3 (because Java2 is what we already have, althought its still numbered 1.x). Or call it Java++ ;)

 

 

No, if we fix the problems it wouldn't be the same language.