J2SE 1.5: Growing the Language - Finally

The i-Technology Media!	Register \| Log in

.NET · AJAX · CLOUD · ECLIPSE · FLEX · OPEN WEB · iPHONE · JAVA · LINUX · OPEN SOURCE · ORACLE · PBDJ · SEARCH · SILVERLIGHT · SOA · VIRTUALIZATION · WEB 2.0 · WIRELESS · XML

Comments

Drool, Britannia? Is the UK Failing the Cloud?

By Roger Strukhoff

Richard Davies wrote: The UK has a good crop of technology pioneers in cloud computing - for example ElasticHosts, FlexiScale, Flexiant, OnApp - and also some strong government initiatives such as G-Cloud. We will have to see whether this kind of technical leadership converts into swift mass-market adoption or not.

Jan. 8, 2012 11:38 AM EST

Top Three Links You Must Click On

Java SE 6

J2SE 1.5: Growing the Language - Finally

By: Karl Avedal

Jul. 2, 2004 12:00 AM

A major event is about to happen - the final release of version 1.5 of the core Java platform.

The changes in 1.5 are some of the most important to the Java language. This is a big step for Java and it's not an easy one. People with an existing investment in the platform tend to be very conservative about the language and core platform, usually for good reasons: nobody likes to have their investment rely on something that has been deprecated, made obsolete, and possibly becoming unsupported. Dramatic changes to the Java language upset a lot of people, not just anyone but some of the long-time Java users who have played a part in making Java successful. Language growth is both painful and necessary.

In Guy Steele's famous speech and article "Growing a Language" from 1998, he discusses the growth of programming languages. He explains how Lisp's ability to grow in a seamless way made it large and has kept it alive for an amazingly long time, while behemoths like PL/1, which was designed to solve everything out of the box, never succeeded.

Java is looking more and more like the language for solving everything. It was never a language that supported growth in the way Steele meant. It doesn't have constructs, like macros, that enable developers to extend the language syntax. This means that the growth has had to come through official channels, which is why the 1.5 release is so important to Java. In the early days of Java, every new and major upgrade was a revolution. The differences between the alpha API and 1.0 were huge, and the changes in 1.1 and 1.2 were substantial. With 1.2, Java became big, successful, and "real"; people started depending on it for large projects. The constant revolutions had to be replaced by slower evolution.

However, if Java does not evolve fast enough, something without a history to care about will soon turn Java into a legacy technology. This is a pretty normal cycle in the computing world. One technology gets wide acceptance, but eventually grows large and can't evolve as fast, then something new comes along and replaces it. The Java language has felt some of this. Competing languages, such as C#, Ruby, and Groovy, are not tied to previous decisions and existing architectures. They use this to try to leapfrog Java.

For a long time it seemed as if Sun had decided to accept a slower pace of development so it wouldn't upset existing Java stakeholders. Soon people who were not tied to Java for legacy reasons started looking at these competing languages. The only way to stop this is to have the courage to make the necessary changes, even if they hurt. With J2SE 1.5 I think Sun is finally showing that they have this courage. This is also true for the EJB 3.0 specification, which relies on features from 1.5 to drastically change how EJBs are developed.

It did take a long time for Sun to make these dramatic language changes and this has helped Java's competitors a lot. Considering that, for example, generics have been in the pipeline since at least 1998 and a JSR since 1999, it's amazing that they haven't become a reality until now. I'm not saying that generics should have been added to 1.4 - they weren't ready then - but it doesn't seem as if Sun has made this a high priority until now. You could speculate that the economic crisis at Sun has played a role in this. When everything was going great for Java and Sun, they might have been afraid to make big changes since that could risk what they had. Now that Sun is in a much tougher position, they might be willing to risk a little in order to gain much more.

Does 1.5 provide what Steele wanted? Steele's point was that the language must facilitate language growth; it must supply patterns for extending the language. Steele suggested a few examples, most notably generics and operator overloading. Java 1.5 does contain generics but not operator overloading. However, it does provide one feature that defines a pattern for language growth: annotations. I would love a complete macro facility for Java, but I know that many wouldn't and annotations do give me some of the power that macros would. This is a great thing that moves Java to a position that will allow it to get older and still evolve. Seeing how annotations will be used to revolutionize EJB development, this is truly about growing the language.

Of course, I don't like all the changes in 1.5. For example, static imports are taking Java one step closer to write-only code. If you want to save keystrokes when using common statics, you should tell the IDE that when you type abs(), the IDE should expand it to Math.abs(). The language should not sacrifice readability for the sake of writability; the language needs to work well for both writing and reading, and enable the developer to be efficient by providing help to the IDEs. Static imports should be an IDE feature, not a language feature.

J2SE 1.5 will obviously be one of the main talking points at JavaOne and there are plenty of sessions available. If you want to learn about the new features, I recommend attending TS-1952, "Fast Track to the Java 2 Platform, Standard Edition (J2SE) v1.5," which will be presented by my co-editor, Calvin Austin, as well as Mark Reinhold.

Published Jul. 2, 2004— Reads 27,721 — Feedback 5
Copyright © 2004 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

About Karl Avedal

Reader Feedback: Page 1 of 1

#5	Robert Wilson commented on 16 Jul 2004 Coldfusion MX is a lot simpler and much easier to create complex web sites with compared to JAVA, after all this web site was written in CF, and it run great without all the complexity. What java needs is a good front end tool
#4	Hal Helms commented on 13 Jul 2004 Jason, simplicity is one of the design goals for the language, as stated by Sun. While it''s syntax was, as you point out, borrowed from C/C++, this was mere window dressing, designed not to put off the C/C++ programmers Java appealed to. Yes, the syntax is arguably messy, but by eliminating things like pointers, multiple inheritance, etc., the language became simpler. One wag called Java "Smalltalk in C clothing"; as an old Smalltalker, I think he got it about right. I agree with your points about autoboxing. There''s an example where NOT adhering to simplicity (by having primitives and object representations of those primitives) causes problems. So an autoboxing kludge is better than not having it. But if history is any guide, the language tinkering won''t stop here. That''s my concern -- are the Java architects losing their taste for simplicity? If a little is good, is more necessarily better? Einstein addressed this issue: "Any intelligent fool can make things bigger, more complex. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
#3	william george commented on 13 Jul 2004 Java doesn''t have macros because the Sun developers had an opinion about how they wanted software development projects to be organized. There are several examples of non-language dependent "standards" that are just plain silly (file names needing to be the same as module names).
#2	Jason Rogers commented on 13 Jul 2004 The idea of Java being simple is ludicrous. Look at the "simple" C-style for loop. What do you have to say about the simplicity of storing primitives in Collections. This new release alleviates some of those pains, but it can''t get over the behomoth-style syntax burdens of Java that came from its older siblings. If you really want simple, go to Smalltalk or even Ruby if you are more inclined to "newer" technologies. Growth and simplicity are not mutually exclusive. There is the idea and possibility of growing more simple. The new for-loop, auto-boxing/unboxing, etc. are prime examples of that. I don''t like everything that''s coming in this new release, but some of it does bode quite well for the readability of Java! You say, "The language was designed to be a simple one, relying on [objects] to provide all but the most basic functionality." Why not rely on objects to do everything? That would be much simpler! You say, "But with version 1.5, are we being swayed to embrace complexity within the language?" What are you being swayed to embrace? If you feel it''s more complex don''t use it, no one''s holding a gun to your head. I assume you are talking of things like generics and static imports. I have never been a fan of generics, it''s readability is akin to C++ templates (besides that I think its dynamic-typing envy, and envy usually doesn''t produce the best results ;). I don''t like the idea of static imports because it blurs the line of encapsulation. I don''t like these "improvements" and so I won''t use them. However, there are advances toward simplicity that I will use (the afore mentioned for-loop and autoboxing).
#1	Hal Helms commented on 11 Jul 2004 The idea that Java needs to "grow" is profoundly wrong-headed. Some of the most successful technologies catch on because they are simple. Their adoption is easy. They allow teams to collaborate on a standard without requiring weeks of training. And then comes the real trouble: success. As the technology is more widely adopted, people begin to clamor for new features. Developers who have long since learned the language clamor the something new to get excited about. And so the technology becomes bigger, harder to learn, more difficult for teams to implement until it falls of its own weight. One of Java''s chief benefits is its simplicity. The language was designed to be a simple one, relying on classes to provide all but the most basic functionality. But with version 1.5, are we being swayed to embrace complexity within the language? In the face of seemingly compelling arguments for this or that new feature, we might do well to remember this quote from Jim Gosling: Complexity makes things harder to understand, harder to build, harder to debug, harder to evolve, harder to just about everything. And yet complexity is often much easier than simplicity.