Summary of JDK1.5 Language Changes

An anonymous reader writes "Over at java.sun.com, there's an informative article about the new features in JDK1.5. Some of the changes like generics are nice and should make some things easier. Some of the enhancements to me are purely sugar, like enumerators. When it comes down to it, once the code is compiled, it's the same. The thing I hope is, some of this new syntactic sugar doesn't result in more obfuscated code. Unlike some people, I feel using programming shorthand leads to increased maintenance. This is especially true when you have to debug a complex application."

Comments

Re:Looking to Get Back into Java

[stevenknight]

check out eclipse -- a very sweet java IDE.
http://www.eclipse.org/

Programming shortcuts

[GGardner]

I feel using programming shorthand leads to increased maintenance

I agree. This is why I never create my own functions or methods. Evey program should be just one big function.

Re:Programming shortcuts

[NReitzel]

During my time at telco, development costs were always a fraction of maintenance costs. Producing write-only code may be cute, and may cut back on other people using it, but it also cuts back on your own people being able to maintain it.

Oh, do I agree, in boldface.

Agreed..

[MilesParker]

..Thought C# has some nice innovations, one of my big problems with it is that so many of its new 'features' are so much syntactic sugar. One of the big things I appreciate about Java is that there is typically onyl one right way to do something; a big change from C++ for example. Plus, modern IDEs like IntelliJ make it very easy to construct iterators and such [Ctrl-j itar..] That said, I don't think that the majority of the Java improvements are really sytactic sugar; things like generics will be very positve improvements. And its very important that Sun keeps up these improvements -- as long as they continue to be well thought out. Ideally we will continue to have a fairly state-of-the art language without any fluff.

Re:Generics

[gray peter]

Agreed that it's a great feature. I use collections all the time and not only is it time consuming to keep casting (especially when you write out long class names like I do...) I'd say a huge % of my runtime errors are from bad casting. I'm definitely looking forward to this. As far as the bytecode specs go, I don't see that this will cause much change at all. The compiler should do the same thing it's always done.

Much, much more than syntactic sugar

[jameson]

Hi,

FYI: Generics are _much_ more than mere syntactic sugar (as are enumerators, a weak form of algebraic datatypes, if handled type-correctly).
These are actually the kinds of things that make program maintenance considerably easier, since they allow more concise specifications of intended semantics to be done. No longer having to typecast (and thus expect run-time exceptions) when using a "vector of FooObjects" gives more power to the type checker, and thus allows a much richer class of programming errors to be detected at compile-time. This is the one major improvement in Java that's been missing since its very inception.

But note that "generics" or "parametric types" have been present in languages such as Eiffel or Sather for well over a decade, and for much longer in ML. In a way, it's embarrassing that such an essential feature was added this late during development.

Re:Write once, Rewrite forever?

[customiser]

AFAIK they will not be breaking existing code... If anything, they had to go out of their way (e.g. the ugly foreach statement) to ensure backward compatibility. In 1.4, the assert keyword might have caused problems, but now I don't think that's the case.

One line summary

[Anonymous Coward]

Java adds four new syntaxes, Python's for loop, Perl type checking at compile time, something called 'metadata', and C enumerations, all of which impove compile time type checking at the expense of making the source code look and feel like perl.

compilers never make mistakes?

[cheezfreek]

As a compiler writer, I found this sentence to be particularly hilarious:

Because the compiler, unlike the programmer, never makes mistakes, the resulting code is also more likely to be free of bugs.

That's right, none of us has ever seen bad code generation or an internal compiler error. But, he does have a point. The compiler is less likely to make a mistake than a programmer.

Shorthand programming

[Shamashmuddamiq]

Yes, I'd agree with that remark about shorthand programming. I thought it was funny when I was teaching classes at UIUC to see stuff like this from the students:

#define FOREVER for(;;)
#define BEGIN {
#define END }
#define ONE 1
#define PUSHORT unsigned short *
#define DONE goto end

The first thing an amateur programmer does when assigned a new project in C/C++ is to go redefine the language and all the types. I scolded them for these kinds of things, knowing that once they were forced to read other people's code often that they would realize how stupid these kinds of things are. Unfortunately, once I started my career in embedded development, I quickly learned how stupid I must have been to think that people left these behaviors behind in college... (all the above examples are taken from "professional" code that I've seen in the last few weeks)

Article didn't mention new concurrency stuff

[dood]

One of the coolest new features of JDK 1.5 is the completely reworked concurrency stuff (JSR 166). I just listened to Doug Lea (spec lead) give a talk on this very subject and I'm pretty convince this will rocket Java performance way up for a lot of the collections stuff, concurrent programming, etc.

Bascially, the goal of JSR 166 is to do for concurrency programming what JDK 1.2 did for data structurs (Collections stuff). The gist is, you'll never need to use "new Thread()" or "synchronized" anymore, but rather you'll execute Runnables, use Locks and Semaphores, etc. Also, queues are *completely* reworked to be ultra scalable.

JSR 166 is based on Doug's concurrency package:
http://gee.cs.oswego.edu/dl/classes/EDU/ oswego/cs/ dl/util/concurrent/intro.html

OH, and there will be classes like AtomicLong which guarantee atomic 'compare and set' options for primitives. :)

Cheers!

Re:Uglification?

[Anonymous Coward]

No, I'm not irked. Not even a little bit.

If your only experience of generics is C++, then all you've seen is the *worst* implementation of generics ever done in a language. Template code is almost unreadable. (Have you ever tried debugging one of the STL implementations?)

Besides, the lack of generic types cripples Java's ability to do static type checking, since your code ends up being full of things like this:

Foo f = (Foo) vector.elementAt(i);

where type errors can only be detected at runtime. That not only makes it impossible to detect errors at compile-time, it hurts performance at runtime.

Check out how generics are handled in Modula-3 for to see a much better way to handle them than C++ templates, or look at ML for something even more groovy (ML uses polymorphic type inference instead of generics, so you don't even have to mention types - the compiler just does the Right Thing).

Once you've worked with a good generic implementation, you'll never want to stop using them.

Harry

What Bjarne Stroustrup has to say about Java

[Q Who]

This is what he said about Java and the likes.

Also here.

Re:Uglification?

[jameson]

Hi,

Well, generics remind me of C++ templates

They're not quite the same; C++ templates are essentially glorified preprocessor macros with
some relatively small checking and a rather baroque
underlying functional language. Generics are more
concrete than that.

Not to mention that attached to variable name doesn't make code any more attractive to look at.

It would be really neat to have type inference there ;-)

It appears that Java's way to solve run time errors is to screw the bolts as tight a possible during compile time.

That's the idea, and that's also what I try to do when writing programs. Why should I have to write half a dozen test suites for some simple program property if the type checker can tell me whether it'll work right?

Remember: Compilers don't do type checking just to optimise, but also to catch programming errors. And Generics allow you to catch a much more interesting class of these.

-- Christoph

Re:enumerators

[ProfKyne]

I don't use ints for my enumerations anymore after reading Josh Bloch's Effective Java. The type-safe enum pattern he recommends is fantastic.

For those not sure exactly how it works, you simply create a class to represent an instance of the enum, and you make the constructor private so that no one can create their own instances. Then you just provide a public static instance of the class for each enum.

I used this pattern simply to achieve its intended effect of providing an enumeration, and then later found that by adding methods to the class, I could even give behaviors to the enumeration instances! Try doing that with an int. This was far more elegant than creating a giant "if" statement and performing conditional logic to test the value of the enumeration, because I simply used a polymorphic method call.

An example:

public class SenseEnumeration {
// the action associated with this enumeration
private java.lang.reflect.Method sense;

private SenseEnumeration(Method m) {
this.sense= m;
}

// assuming we've already created some
// Method instances to use here
public static SenseEnumeration TASTE
= new SenseEnumeration(myTasteMethod);
public static SenseEnumeration HEAR
= new SenseEnumeration(myHearMethod);
public static SenseEnumeration SMELL
= new SenseEnumeration(mySmellMethod);

...etc...

public Method getSenseMethod() { return this.sense; }
public void invokeSenseMethod(Object target) {
sense.invoke(target, null);
}
}

You get the main idea. No, not as fast as an int, but far more powerful.

Re:How this compares to C++

[TummyX]

Metadata
This is.. well.. strange. I didn't see the syntax for doing something like this. If it is just keyword/code replacing, then an #include directive would work just as well.


IMO, metadata is the coolest thing. It's a feature of C# which has had little recognition despite its coolness.

In both Java and C# you can use reflection to find out information about a class (class name, method names, etc). Attributes/metadata allow you to attach information to just about every element of a class/struct so that it can be queried dynamically using the reflection apis.

Imagine them as JavaDoc tags that aren't discarded at compile time but are instead compiled into a class's meta data. They'll do for source code what XML did for HTML -- give more meaning to the code.

Here's an example of using attributes/metadata to simplify XML serialization:

[XmlRoot("cat")]
public class Cat
{
[XmlAttribute("id")]
public string Name;

[XmlElement("color")]
public string Color;

public Cat()
{
}

public Cat(string name, string color)
{
this.Name = name;
this.Color = color;
}

public static void Main()
{
Cat cat = new Cat("felix", "yellow");

XmlSerializer serializer = new XmlSerialzer(typeof(Cat));

serializer.Serialize(cat, Console.Out);
}
}

The code yields the following output:

<cat id="felix">
<color>yellow</color>
</cat>

The C# XmlSerializer class dynamically generates the IL that will do the serialization so it is *very fast*. It knows how to map the field names to element/attribute names by inspecting the attributes.

Some other obvious uses include object/relational mapping (no need for external XML mapping files) and XMLRPC (just mark a method as Remotable!) etc. You can imagine infinite other uses for attributes/metadata.

I'm not sure how it works in Java but in C#, attributes are simply classes (usually with a name ending in 'Attribute'). You can define your own custom attributes and your own classes that work with them. It's very cool.

Just from pesonal experience..

[LogicHoleFlaw]

You know, I've just got to say this.

Each and every point on this list of additions to the languages addresses problems that I have personally run into in my use of Java at work. These things will make the writing and maintenance of java projects small and large much, much easier.

Generics: Thank you God, yes! Having to explicitly cast objects out of Containers is tedious and error-prone.

Iterators/Enhanced 'for': Make iteration much easier to read and understand.

Autoboxing/Unboxing: This helps alleviate the enormous kludge that is the Object/primitive dichotomy. Casting to and from wrapper types just to pass ints, etc. around really sucks.

static import: Not having to fully specify tedious class names to access static members is a big boon for making stuff digestible and easy to read.

Metadata: Writing boilerplate sucks the big one. How many hours have I lost writing boilerplate? Way too many. Having language support for generating code from the metadata cuts my implementation times way down.

I could sit here and argue with folks about the 'new Java' versus C++ or C# or Smalltalk or whatever endlessly. But man, these things sure make Java a whole lot more pleasant to use.

Re:When will Java be 'frozen'?

[_fuzz_]

My vote would be to freeze the Java language (perhaps after 1.5) and concentrate on the following:

* memory footprint
* runtime efficiency ...

Leave it alone (the sooner the better) except for improvements in the implementation.

This is a good idea. However, my vote is to concentrate on Java3. Screw backwards compatibility going forward and fix the standard library. Throw out the crap that has come along from JDK 1.0-1.1 and make the platform consistent. Why do we have both Enumerations and Iterators? Why are constants mostly UPPERCASE but sometimes lowercase (see java.awt.Color)? What about Thread.stop()?

This cruft is never going to go away until Sun releases a version of Java that isn't backwards compatible. Perl and Python do it. Java should too. It makes for a much cleaner language for new projects. Old projects may get stuck on a Java2 platform until the owners invest the time to convert them, but that's the way things go. It's time to clean out the cobwebs in Java and make better use of the new features.

Once all the old crap is gone, then it will be time to freeze the language and standard library.

Yeah, but...

[Burpmaster]

I'd say that "++x" is actually the "best" way because it puts things in verb-noun order, which I'm used to as an English speaker.

In Soviet Russia, x++!

What about making the language useful

[samwhite_y]

In the old days when people talked about Linux, there was an expression "What about the big pink elephant in the middle of room" and it was referencing the fact that Linux did not support truetype fonts and font aliasing. Now some of that has been fixed, but Java still has its big pink elephant. Here are some of the things that people don't talk about.

The memory foot print for loading Java is 20meg + and growing. I am part of a team that has been developing a complex Java application for the last few years and we have created about a 3meg library (and it probably does at least as much as the more popularily used Java classes). I have looked at some of the source code for the core Java libraries and it is clear that a good rewrite could reduce this footprint by a factor of 2 to 4. Currently, C# loads with a footprint of 2 meg to 4 meg. Most other scripting languages usually have engines that are about the same size. To put it simply, the base core Java libaries are unjustifiably large. Maybe if Java were truly open source this could be addressed, but of course Sun doesn't even believe in submitting Java to a standards board.

You cannot load the Java VM once and run multiple processes (note "processes", not "threads") from the same Java VM memory footprint. I hear that such a thing is becoming possible for C# on Linux. You would have to build all the core Java classes into a "DLL" or ("so" on Linux), but that shouldn't be so difficult.

You still cannot do basic OS operations in Java without writing your own JNI library. The one that stands out is the inability to get the ID for the current running process. The "nio" package has corrected some of these issues, but the "nio" package should be the "io" package instead of having two separate packages (similar to AWT vs. Swing).

Window focus handling is still terrible. Ever have two frame windows up, have a modal dialog pop up on one frame while you were looking at the other? The frame window without the popop modal dialog becomes unresponsive and the other frame cannot be reached by tabbing through the windows. Only if you are lucky and that window is still visible on your desktop can you successfully reach it. Also, if a user clicks on a button that generates a modal dialog, the frame is only locked out from user input once the dialog manifests. This creates the infamous "double" clicking problem.

Java's package management is still primitive. If you want to do anything more subtle then using the classpath to load in custom libraries, you have to write your own class loader. Having an auxillary file specifying parameterizable rules for class loading would be nice. It would also be nice if you could ask a running Java process what packages it had loaded (and metadata about them such as location and version). Compare this to C# (or the way some of the web server oriented scripting languages work).

Some of the basic core library functions have some major weaknesses. For example, the Hashtable should be written as a native object when using String lookup keys and also allow you to dictate the algorithm for creating hashes (ex: use first 8 characters, last 8, or middle 8). There should also be a non thread safe version as well as a thread safe version. The lack of such a natively implemented primitive object is one of the big reasons why some less cleverly implemented scripting languages (such as python) can beat Java in performance on many web applications. In general, the core collection classes should be implemented in pure optimized (down to the actual chosen assembly code) native code.

Many of the utility libraries are broken in fundamental ways. Send back a badly formed response to the HTTP library and you go into an infinite loop when it falls into its keep-alive/retry logic. Date parsing is still behind what is available in the C standard library. Locale specifications do not allow you to independently specify date formats, language, floating point format, currency format, and time zone. You get o