Last Update: 2007/12/10.
Awt is unusable, and Swing isn't dominant. An alternate gui package (SWT) exists, that it's not really that much different from Swing.
Awt and Swing should be deprecated and replaced by a new gui package that is alot like Swing but improved to meet modern technology. For instance, an alternative JList could be backed by a Collection that uses generics.
Alot of work has been done improving Swing. The new Swing could be alot better if it didn't require the use of the old garbage in the java.awt package. It could feature active input polling, and active rendering could be the norm. There could be a few simple classes to provide the ability to activate passive input polling and rendering.
Compile-time synchronization is generally much better than having classes that are completely synchronized. The synchronized versions should be deprecated. Having two versions of all the Collections classes is ridiculous.
It's hard to package the JRE with a program. First of all, it's too large when people would have to download it every time they download a program it's packaged with. Second, it looks really strange when a developer's installer program opens up the JRE installer at the end of the installation. Third, some people think that packaging the JRE installer within another installer is illegal. Or they think that it must be a virus because there's an installer within the installer. Or they think whatever ridiculous thing they've thought up that no reasonable person would ever imagine.
Telling people to download the JRE separately is impossible. It's inconvenient for people downloading your program, and some people just won't do it.
Java Web Start is, basically, useless because people who don't have the JRE don't have Java Web Start either. This limits Java programs to a subset of the population.
There needs to be some sort of special Sun installer that can be used to install Java programs. Such an installer must run without having the JRE installed. It could be written in Java, but it would have to be compiled into native code if this were the case. This installer would basically be Java Web Start with the following changes:
The idea is to make an installer that looks like a regular installer that installs a Java program. Install4J is currently the best option I know of, but it doesn't have Java Web Start's other capabilities (e.g. updating to new versions of the programs downloaded). It also costs more money than most people are likely to pay.
Another problem with JWS is that it can only update .jar files. Packaging all images, sounds, etc. in a .jar file is no big deal. But it would be preferable if all those files could be (at the developer's option) extracted upon being installed on the machine. It's a pain to deal with large .jar files containing all the resources for a large program, and it's even worse to break them up into a number of smaller .jar files.
There could be a free installer creator that has some limitations and displays Sun's logo while installing the program. Sun could sell a full version without those limitations and without the logo.
I think the time is coming to make a new version of Java that isn't backwards compatible with the old releases. There's been alot of changes in the Java language, most notably the changes in version 1.5. Sun should release one or two big releases to finish up any changes they want to make to Java 2. All these changes should be backward compatible (as much as possible) with the old versions of Java. After this, Sun should start work on "Java 3" (for lack of a better name).
This would allow Sun to make various improvements. In particular, the following are possible:
All deprecated classes should eventually be removed from the Java release. I believe that was part of the intention of deprecation. This isn't the sort of thing to be done on a whim, but I think it would be good to do this eventually. That release could be combined with whatever other structural sorts of changes are desirable by the time the deprecated class removal gets done.
The main benefit of removing deprecating classes is streamlining the Java release to remove excess garbage. The abundance of deprecated classes and methods in the JDK makes it difficult to find anything. Sometimes, it's easier to do an Internet search to find code than it is just to figure out which class in the Java JDK is applicable to your problem.
The package "java" is used for packages that are part of the main Java release, and the package "javax" is used for packages that are part of Java extension releases. Some of these extensions, such as Swing, were then added to the main Java release.
Those packages should be renamed from "javax" to "java" to make everything standard. This can't be done with the current Java release methodology because everything has to be backwards compatible.
Right now, there's the main JRE and alot of "javax" extensions. When embedding the JRE in an application, people have to include all the class files in the JRE. Including database classes when I'm writing a program that doesn't use databases is a complete waste. It's like sending someone a text adventure game with a bunch of image files that aren't used.
The main JRE should contain less. Packages such as java.lang, java.net, java.util, etc. would be in the main JRE. Other packages would contain the code needed for specific types of programs.
A program with a GUI would contain Swing. A program that accesses databases would contain all the database classes. This would be just like the extension system for javax packages. Essentially, almost everything would be a javax extension.
Conversely, the JDK should include alot more code. Then the extensions that should be included with a program can be selected automatically during compilation. Common extensions (e.g. jinput, java3d) should be added to the JDK. Other extensions from Sun and even 3rd party extensions (such as libraries for loading MP3 or Ogg Vorbis music) could be downloaded and added to the body of extensions.
The increased size of the JDK wouldn't be a problem because it's only used by developers anyways. The C# development kit is huge. The JDK shouldn't necessarily be that large, but it can be bigger than it is now.
Programs using the hacked JRE would contain only what they need.
There are 3rd party solutions that allow to leave parts of the JRE out of your distribution, but they are expensive and vary in usefulness. If Sun had its Java classes prepacked like this, the process would be taken care of by one central body of code that can be thoroughly tested by Sun.
| Note: Sun is actually doing something like this. |
In these days of high speed Internet access, download size no longer seems important to most people. I think that this is still an issue.
The JRE has become cluttered with a bunch of junk. If the junk is removed, including the JRE in every Java program will be a small enough overhead that it won't act as a deterrent to developers.
The best way to decrease the size of the JRE is to allow "Legally Hacked JREs".
| Note: This isn't as important with the smaller JRE kernels Sun is creating. |
There's a number of places in the JDK where 1.5 features would be useful but aren't used. For instance, the Math.max and Math.min methods should use variable-length arguments to allow finding the maximums and minimums of whole arrays of numbers. Any calls such as "max(a, b)" would still work, but the methods would also work with more arguments and with arrays as arguments.
Copyright (C) 2005-2007 Steven Fletcher. All rights reserved.
