|By Janice J. Heiss, November 2005|
As part of Sun Microsystems' effort to encourage the adoption of Java 2 Platform, Standard Edition (J2SE) 5.0, Tiger, we met with the father of Java technology, James Gosling, vice president and Sun Fellow, to get his take on how Tiger is doing.
J2SE 5.0 stands out for its new language features, which includes generics, enhanced
for loops, typesafe enums, variable arguments, static imports, and annotations. Is there an untold story here?
It's hard to imagine that there's an untold story. We've told the stories over and over, particularly about generics, a feature that's been on the to-do list for more than a decade. It's probably the single most argued-over feature in the whole technology. People from all over the world created prototypes -- it was almost like a competition among academic groups to come up with a good design. From the big debates about generics to the concurrency discussions to XML, it was also an intensely collaborative effort that turned out very nice. The Java community produced a wonderful piece of work.
"If there's a misunderstood story about Tiger, it's that some people seem to believe that Tiger is something that Sun did alone. But it's probably the most intensely collaborative effort we've ever done."
Vice President and Sun Fellow
If there's a misunderstood story about Tiger, it's that some people seem to believe that Tiger is something that Sun did alone. But it's probably the most intensely collaborative effort we've ever done. It fits together well, with all of the collection classes being generic, the conversion of the collection classes so that they work properly in the generic world, enums included where possible, and all of the concurrency stuff.
How is tool support going?
We've put an immense amount of effort into the NetBeans IDE to support Tiger, and it's been really successful. People like NetBeans. In addition, we've put in support for things like mobile and Java Platform, Enterprise Edition (Java EE) 5 development.
Are bug fixes still a significant issue?
Bug fixes are always an issue. The bug counts are reasonably low, but dealing with bugs is certainly job number one.
Some developers claim that it's too soon to move to J2SE 5.0. They don't yet see the competitive advantage in migrating, and they're concerned about IDE and library support issues along with the stability of the JVM* software. They're waiting for early adopters to move first. How do you respond to this?
People always fear new releases. But in the Tiger release, we performed rigorous testing in long alpha and beta cycles of a large variety of giant outside applications that we took in house, working directly with outsiders. So many people run large mission-critical systems on top of Java software that we wanted Tiger to work in these mission-critical situations.
It's traditional for some folks to wait for the .1 release. These are often people who never switched to the J2SE 1.4.0 release -- they waited for the J2SE 1.4.1. Given the feedback we've gotten, there will not be a 5.1 release. The 5.0 Update 3 release contains the critical fixes that would've gone into a 5.1 release but, as Graham Hamilton has noted, renaming that release "5.1" probably would've caused more trouble than it would have been worth.
Is there anyone whom you would advise not to migrate?
The language is now faster and more fully featured. Problems do arise, however, when workarounds for bugs in J2SE 1.4 have been built. The workaround itself can break because of the absence of the bug. That's the dominant migration problem that we see. But otherwise, everyone that I've talked to has had a smooth ride.
At the 2005 JavaOne conference, you said, "The number one challenge in the next 10 years, from an engineering point of view, is complexity. We've been doing a lot to deal with complexity in the APIs and the language and in the tools." How does Tiger address the issue of complexity?
The many API changes should make standard usage patterns easier. Certainly enums and generics should make developers' lives easier and less complicated by hiding a lot of ugly detail. Most of our work on complexity has been at the tool level inside NetBeans so that the tool can support transparent development in which developers are not exposed to a lot of the application but get a more standard boilerplate.
"The many API changes should make standard usage patterns easier. Certainly enums and generics should make developers' lives easier and less complicated by hiding a lot of ugly detail."
Vice President and Sun Fellow
What complaints, if any, have you heard about Java generics?
The usual complaint is that they didn't go far enough and aren't generic over primitive types. They only handle compound types, and it's actually a tremendously different problem to try to make primitive types generic. It's still a Ph.D. topic in computer science to make remove types generic and have the system be simple and fast. It's pretty easy to do if you're willing to give up on performance and give up on certain levels of backward compatibility. We decided that we couldn't see any of the ways to do what people suggested regarding generics over primitives.
One developer, torn between .NET and Java technology, expressed frustration by the fragmentation in the Java language and said, "Eclipse's SWT (Standard Widget Toolkit) is so much nicer than AWT or Swing; JBuilder's got a much nicer GUI, but it doesn't come with SWT. Hibernate? JDO? Beans?" He wanted to know how the next releases will make development easier, make applications prettier and easier to deploy, and offer through-the-roof database technology so he can develop the fastest, most stable, slickest applications in the least amount of time, leaving .NET conformists in the dust.
Well, I would certainly recommend that he use Java Foundation Classes/Swing (JFC/Swing), which, if used properly, gets much, much better performance than SWT. However, Swing has a lot more features than SWT, making it easier to use incorrectly. This has been a problem. As for database issues, each situation is a little different, and you have to know a lot more about the situation. In some situations, relational databases are fine. But for others, object persistence solutions are better. It's a very turbulent part of the technology.
One developer argues: "Sun has broken the easy-to-read rule with J2SE 5.0. Autoboxing and static imports add very little benefit and make Java programs harder to read and understand. Whereas generics, enums, and for-each are good additions, because they make it easier to understand the programmer's intentions."
Well, to a large extent, I would actually agree. I thought really hard about autoboxing 10 years ago and decided against it, because of this problem. But it became an issue due to the demand for it, and in one particular case, many people asked for something that was vaguely similar to
printf. And every proposal that was similar to the usage pattern of
printf required something like autoboxing. So we went down that road, even though I have to admit I wasn't particularly happy about it.
Developers have complained that reducing characters in the enhanced
for loop may save two hours of typing but incurs two weeks debugging, because it makes the code less verbose but harder to understand and more prone to error.
This was a hotly debated topic. The argument centered on certain loop clichés that are used over and over again, and in particular those that involve iterators. People commonly use iterators with fairly boilerplate code that you have to get right. And so while you might be required to know more about the
for loop, it simplifies all of your usage of the iterators. You have to balance the pain due to the iterator cliché's verboseness because it contains a lot of boilerplate code. On the other hand, to solve that, you have to add something in the language spec that adds complexity. It's a balancing act.
In response to some questions about Tiger, James Gosling sent us to Java Platform, Standard Edition (Java SE) chief engineer, Mark Reinhold, who graciously provided some answers.
We've heard complaints that application startup speed has not increased with Tiger, as claimed. Is startup speed a problem?
In most cases, startup time is better with Tiger than with earlier releases. For many small- to medium-sized applications, we've seen a modest improvement (5 to 15 percent) in startup time, though in some cases the improvement is much more significant (up to 30 percent). The improvement for large applications, such as IDEs, is relatively smaller since the startup time is dominated by the time required to load the application itself.
Much of the startup-time improvement is due to the new class-data sharing feature. When you install Tiger, it pre-bakes a couple thousand of the most commonly used platform classes into a heap image that's then saved into a special file. Subsequently, when the HotSpot VM starts up, it simply maps that file into memory rather than going to the trouble of individually loading, parsing, and linking those classes as they're used.
A developer wrote: "I am a senior software developer (Tech Lead) and have migrated to this release (5.0), but due to execution time issues, I am thinking of switching back to an older version." Are we getting complaints about execution time? Is this comment atypical?
We've received few reports of execution-time problems with Tiger. If you notice that your application is slower with Tiger than with 1.4, then please file a bug -- we'd like to fix it! More information on Tiger performance can be found in the J2SE 5.0 Performance White Paper.
Some developers have complained that Tiger is not ready for mission-critical systems. One says, "Java is not ready for mission-critical systems, specifically with regard to applets. Two big reasons that I can cite are that the NIO (new I/O) package doesn't support SSL, which is crucial in our production systems, and the JARs won't cache in an SSL platform. I'm working on an enterprise system that is supposed to support several thousand end users, and they have to download the JARs every time they load the application. These problems would not occur in a mission-critical software platform."
Actually, Tiger does include support for SSL over NIO in the form of
Java Plug-in caches JAR files regardless of whether they're downloaded via HTTP or HTTPS. It's possible that something's wrong with the way the server is configured, or perhaps they've found a bug -- in which case, we'd appreciate hearing about it so that we can fix it.
*The terms "Java Virtual Machine" and "JVM" mean a Virtual Machine for the Java platform.