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/

Re:Looking to Get Back into Java

[gray peter]

The language I could pop right back into, but could use some advice on good/affordable IDE.

http://www.xemacs.org
what more do you need? ;-)

If you want a *real* IDE, I'd check out IntelliJ's Idea product. It's a few hundred $$$. Lots of folks like Netbeans and IBM's Eclipse as well (sorry, no url to eclipse, but I'm sure you can find it). The latter 2 are opensource.

Re:Looking to Get Back into Java

[Schezar]

Eclipse is "the awesome." It's feature-filled and relatively easy to use. Being free is a nice plus, too.

My roommate told me about it, and once I started using it I never looked back.

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.

Re:enumerators

[customiser]

It's good to see enumerators formally supported, but you were not really _forced_ to use plain ints up to now. It is just some sort of an anti-pattern, which everybody seems to be using happily.

The type-safe enum pattern shows the correct way of handling enumerations. And you can the Jakarta Commons Lang library to make it a bit easier.

Re:Generics

[blamanj]

No bytecode changes are required. There have been "test" implementations out since Java 1.2. You can get the current 1.3 release at
http://developer.java.sun.com/developer/earlyAcc es s/adding_generics/

How this compares to C++

[lkaos]

Generics
The new Java generics are really weak compared to C++ template support. This is probably partially due to difficult in compiler support and also complexity (templates are without a doubt the most complex feature of C++). I was disappointed though in Java generics mainly due to lack of any kind of specialization support and also about the strange paradigm used for Iterators (instead of an iterator being class defined with a consistant interface, it's an external class that just behaves that must wrap a behavior around the class).

Enhanced for loop
This is for_each() in C++. Now, with for_each, you have to use function objects which is arguable as to whether it's more readable. Fortunately, Boost has developed a boost::lambda class that allows for code to be used as the third parameter. This is _really_ neat.

Autoboxing/unboxing
I presume this means that primatives can't be used in generics.. That's kind of sad. This isn't a problem in C++.

Typesafe enums
This would be a nice linguistic pattern to have in C++. As it stands, the equivalent would be:

struct Coin { enum { penny, nickel, dime, quarter }; };

Static import
This can be achieved via using in C++. Of course, Java doesn't even really have a namespace paradigm so it's not really a fair comparision.

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.

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.

Re:not just sugar

[Jack Greenbaum]

That's 16 lines of code for one property! This is tedious to write, and more importantly, very hard to read when you have many properties.

You really need to try a generating/refactoring IDE like Eclipse. I once held to the orthodoxy that if I needed more than emacs then something was broken in the language. I grew up on object systems like CLOS where if you wanted a getter or setter you just asked for it in the definition of a field. So at first C++'s lack of public read-only/private read-write vars annoyed me, and Java's odd package visibility rules made me wince. But now I just declare private and generate my getters/setters, I navigate the file with the outline view, and I get more done per unit time then in any other language/ide pair, including VB.

-- Jack

What Bjarne Stroustrup has to say about Java

[Q Who]

This is what he said about Java and the likes.

Also here.

Re:Generics

[CognitivelyDistorted]

Pretty close. For "list.add(myFoo)", it won't add a cast, because the type checker verifies that myFoo is-a Foo. The compiler will also add "bridge methods" for classes that implement a parameterized interface:

class Byte implements Comparable<Byte> {
...
public int compareTo(Byte obj) {
return this.value - obj.value);
}
}

The method compareTo is supposed to override the method in Comparable, which takes an object. So they create a bridge method that overrides it normally:

class Byte implements Comparable<Byte> {
...
public int compareTo(Byte obj) {
return this.value - obj.value);
}
public int compareTo(Object obj) {
return this.compareTo((Byte) obj);
}
}

JCP strikes again

[Wesley Felter]

Thanks a lot Sun for posting absolutely no information about the progress of this JSR. At least Doug Lea has posted a little information.

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:Looking to Get Back into Java

[richieb]

If you are willing to spend some money check out IDEA from IntelliJ. It's great!

http://www.intellij.com/idea/

Re:I think these are all great...

[sohp]

Sun has been burned once when they introduced the assert keyword and broke thousands of programs that use the JUnit testing framework. The bustage occured because JUnit already used the keyword as an identifier, for the assert() methods. A token can't be an identifier, so everyone's tests broke with 1.4 I applaud Sun from learning from that fiasco and avoiding a repeat.

Re:Article didn't mention new concurrency stuff

[etedronai]

I am actually using the initial implementation of this on our current project and it is very nice. Actually have fine grained synchronization control makes it much easier to deal with a lot of thread synchronization problems. It has also helped us greatly reduce deadlock and detect deadlock because locks and waits can time out and report to you that they have timed out rather than just happily returning like Object.wait() does today. All in all this, along with generics, is probably the best new feature that is being added in jdk 1.5

Uh, read the article

[autopr0n]

This is exactly what the new Java enums do. You just get to type a lot less and you can use them in case statements.

Re:enumerators

[iabervon]

The instances are created when the class is loaded, and there's only one copy of each value. It's essentially like you're using int constants, except they're pointer constants instead, so you can dereference them to get more information than just equality. It's essentially the same as

public class Season {
static public final Season spring = new Season();
static public final Season summer = new Season();
static public final Season fall = new Season();
static public final Season winter = new Season();

private Season() { }
};

Except it's only one line, there are useful additional methods (like a toString), and you can use it in a switch statement.