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."

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 [intellij.com] product. It's a few hundred $$$. Lots of folks like Netbeans [netbeans.org] 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:Give billg his due...

[rpk]

Not knowing much about C#, is Java 1.5 "borrowing" features ?

I see two trends: being a better C++ (typesafe enums and parameterized types), and borrowing features from Lisp (code metadata, auto boxing/unboxing). I don't like to tie developments like this to particular people, but I wonder how much Guy Steele has do to with the Lisp-like features, if in fact he is still working at Sun.

Re:Looking to Get Back into Java

[Anonymous Coward]

How does free sound? http://www.eclipse.org/

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 [apache.org] to make it a bit easier.

Netbeans

[truthsearch]

While eclipse is great, Netbeans [netbeans.org] has more features. I prefer eclipse because it uses a native interface and has refactoring. The most feature-rich IDE I've used for Java, however, is netbeans. If you don't mind a slow user interface it's a great tool to look at.

Re:Give billg his due...

[Anonymous Coward]

But don't forget that features like Metadata have been a part of Java for at least a year via the widely used open source XDoclet project. It's only now being added to the Java standard because XDoclet is so popular and it makes writing EJBs *a lot* easier. XDoclet's ideas about metadata came from the Aspect-Oriented-programming movement, not C#.

The idea of autoboxing came from C++ where you can define your own conversions. Autoboxing becomes necessary to reduce syntax clutter when you add Generics to Java. This is because the Java implementation of Generics only works for Objects, not base types.

Foreach and enum is in more languages than you can shake a stick at, so you can't say they came from C#.

The "static import" idea is new. If C# has it, then it's likely Java took it from C#. Other than that, I can't see anything that Java took from C#.

A better solution than Generics

[MarkSwanson]

Generics is an auto-casting mechanism that is useful to catch programming errors at compile time instead of run time. Please note 2 things:

1. the 'cast' still happens at runtime as the compiled bytecode is still the same.
2. there is a much faster alternative that uses native data types instead of objects (below) and catches errors at compile time.

As a pro Java developer, I want to use the native 'int' type in order to save memory, have less garbage collection, and perform better. Catching errors at compile time is helpful too. I think it is unreasonable for Sun not to include specializations for native data types. If I want to have an ArrayList of 10,000 ints I should be able to use 'int'.

The link on this page states up to 10x performance but I've seen it work up to 30x performance - and you can run the code below to see this for yourself.
NOTE:
30 = 7272727/236966 where:
1. 7272727 = 2nd iteration of Int2IntHashMap!
2. 236966 = 15th iteration of HashMap (Hot spot had 12 more iterations to optimize)

http://fastutil.dsi.unimi.it/

package com.wss.utils.test;
import java.util.*;
import it.unimi.dsi.fastUtil.*;
public class TestFastUtil {
public static void main(String[] args) throws Exception {
int count = 400000;
int timerCount = 20;
long start, end;
Integer tmp; // Normal HashMap
HashMap hashMap = new HashMap(count);
for (int timer=0; timer timerCount; ++timer) {
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
hashMap.put(new Integer(i), new Integer(i));
}
end = System.currentTimeMillis();
System.out.println("HashMap put(Integer, Integer) count:" + count +
", put/s:" + (count / ((float)(end-start) / (float)1000)));

start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
Integer in = new Integer(i);
tmp = (Integer)hashMap.get(in);
if (!tmp.equals(in))
throw new Exception("failed equals()");
}
end = System.currentTimeMillis();
System.out.println("HashMap get(Integer) count:" + count +
", get/s:" + (count / ((float)(end-start) / (float)1000)));
} // FastUtil HashMap Int2Int
timerCount = 100;
Int2IntHashMap int2IntHM = new Int2IntHashMap(count);
int j;
for (int timer=0; timer timerCount; ++timer) {
start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
int2IntHM.put(i, i);
}
end = System.currentTimeMillis();
System.out.println("Int2Int put(Integer, Integer) count:" + count +
", put/s:" + (count / ((float)(end-start) / (float)1000)));

start = System.currentTimeMillis();
for (int i=0; i count; ++i) {
j = int2IntHM.get(i);
if (i != j)
throw new Exception("Int2Int failed equals()");
}
end = System.currentTimeMillis();
System.out.println("Int2Int get(Integer) count:" + count +
", get/s:" + (count / ((float)(end-start) / (float)1000)));
}
}
}

Re:Write once, Rewrite forever?

[Caoch93]

...especially since the assert keywork is, on Sun's JDK, only compiled to a bytecode construct if you request it be at compile-time.

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 [sun.com]
http://developer.java.sun.com/developer/earlyAcc es s/adding_generics/

Enumeration classes

[coyote-san]

This isn't the forum for a detailed discussion, but I actually prefer enumeration classes now over simple enumerations. The basic idea is to write a class something like:

final class Color {
String c;

private Color (String color) { c = color; }
String toString() { return c; }

static final Color RED = new Color("red");
static final Color BLUE = new Color("blue");
static final Color GREEN = new Color("green");
}

You can then treat this class like a type-safe enumeration. It doesn't have all of the nifty features that you'll see in languages like Ada, but it has the nice property of allowing you to attach whatever information you want to the enumeration class.

You can also use this approach to create self-initializing classes, e.g., a list of states (including full name, postal abbreviations, shipping zone, etc.) from a database. You can access the enumerated values through a collection class, a "lookup" method, or even reflection.

Generic Java

[henni16]

Interested in Generics?
A Compiler for generic Java has been available for years:
You can check out Pizza/GJ here [unisa.edu.au] or here [luc.edu]

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: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 [eclipse.org]. 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 [att.com] and the [att.com] likes [att.com].

Also here [eptacom.net].

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);
}
}

Re:Where is operator overloading?

[Anonymous Coward]

I used to wonder why Java doesn't haver operator overloading. But it just occurred to me that overloading doesn't actually do anything except make misleading code. Think about it... what can an operator do that a normal method can't? Some would argue that operators make the code more readable, which they do. But they also obscure the difference between compiler reserved words and programmer defined words. Which is as dumb as being able to redefine "while". OTOH, in Lisp you can redefine +, even for integers.

JCP strikes again

[Wesley Felter]

Thanks a lot Sun for posting absolutely no information [jcp.org] about the progress of this JSR. At least Doug Lea has posted a little information [oswego.edu].

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:Give billg his due...

[Anonymous Coward]

It's called competition and it's a good thing. That's why, ironically, Linux will be a good thing for Windows users. It won't be good for MS's finances but that only impacts MS stock holders, employees and suppliers so I could care less.

Re:Where is operator overloading?

[Glock27]

I would *love* to see operator overloading. It would actually make Java much more useful for scientific tasks which involve things like vectors, matricies, or complex numbers. I'm also sure it would also be helpful in other areas.

There was a preprocessor named jpp floating around a few years ago that supported operator overloading for Java. It seems to have vanished off the net in the meantime, though I'm sure I have a copy somewhere. True operator overloading is supposed to be added to Java at some point, IIRC.

In the meantime, perhaps we should write a new preprocessor, the "Operator Overloading Preprocessor System" or OOPS. jpp seemed like a good idea (it offered several features beyond operator overloading). Java coupled with a good preprocessor is a fine idea. ;-)

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: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:So basically C# minus generics

[devinoni]

Generics
No such thing in C#.

Enhanced for loop

foreach (type identifier in expression) statement

expression needs to implement IEnumerable, or declare a GetEnumerator that returns an IEnumerator

Autoboxing/unboxing

int i = 1;
object o = i; //boxing
int j = (int) o; //unboxing

Typesafe enums

enum Rating {Poor, Average, Okay, Good, Excellent}

Rating IncrementRating(r)
{
if (r == Rating.Excellent) return r;
else return r + 1;
}

Metadata

// Metadata saying this is a webmethod

[ WebMethod ]
public int PerSessionServiceUsage()

Re:How this compares to C++

[slagdogg]

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 }; };

Not equivalent, the Java version also supports writing as a String ... so the below statement produces the string "coin: PENNY" which is very, very handy.

System.out.println("coin: " + Coin.PENNY);

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 [junit.org] 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

Re:So basically C# minus generics

[Anonymous Coward]

Next version of C# will have generics support. Unlike the Java implementation, it will support generics at level at which not only do you get syntactical sugar / compile-time type safety, you get collection and other classes with improve performance.

Furthermore, next version will include other nifty features such as lambda-style anonymous methods.

pizzacompiler

[cyco/mico]

I found java always underachieving, the rt environment ("virtual machine") and especially the language. the compiler was, well, ok.

my favorite language (extension) for the vm has always been pizza [sf.net]. It gives you said generics, but also

• first-class functions and
• algebraic types (think functional pattern matching)

all three compatible with the original jvm 1.0 specification.

But to be honest: this seems to be a real great step for java. programmer with a certain need for aesthetics (and self regard) can now really use this language...

XDoclet

[Julian Morrison]

Sounds to me like they just slurped in XDoclet [sourceforge.net], just like they slurped in Log4J [apache.org] in the 1.4 release.

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

[mobiGeek]

Don't forget about the JDEE [sunsite.dk]!

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.

Re:Programming shortcuts

[dasmegabyte]

Let's say you have a really complex, but SMALL, algorithm that you do all the time. Going into a new function takes resources even when compiled (basically, the CPU pops your current work onto the stack, flushes the current command queue and any fancy branch prediction going on, and moves to the memory location of the function EACH TIME it's called)...so C programmers invented this method called inlining.

(this next bit is a very simple and very halfassed explanation in pseudo C. flames from C programmers about the bad syntax will be ignored. i got a D in C so F it)

Inlining works like this. You write a function and assign it a variable name. Then, any place you want that function, you use the variable name. The "precompiler" converts any instance of the variable name into the original function. EX:

#DEFINE PISETUP
int pi;
pi = 22/7;
#ENDDEF

Later, if you use the term PISETUP it will be replaced with that code by the precompiler.

This was a good way to facilitate rewriting the same thing over and over, while maintaining speed, and a single location to change/fix the function. Unfortunately, it was also a good way for lazy programmers to obfuscate code by creating precompiler directives and variables for common language patterns. EX:

#DEFINE STARTIF
if (
#ENDDEF
#DEFINE CLOSEIF
)
{
#ENDDEF

Used to make:

if ( true )
{
beep;
}

into:

STARTIF true CLOSEIF beep; }

Shorter, yes. But harder to read, much harder to understand, and absolutely confusing for the poor newbies. Kind of like learning how to read from logs of an AOL chatroom.

One of the big "innovations" of Java was the elimination of the precompiler, which made sense. Java runs object code, not directly runnable byte code, so it is in essence already performing the tasks of the precompiler. The virtual machine "compiles" the code while it is running, to optimize for the individial physical machine, no matter what it may be.

The idea worked IMO because, now that you can cut, paste, and find and replace (with regular and replace expressions), you don't really need these replacements. Might as well just be verbose as you want to be. Might as well use tiny little functions since inlining doesn't work anyway.

Besides, since Java is interpretted and recompiled while it's running, you don't gain anything from inlining. Any "contextual" function (the function as written in the code) might become "inlined" when run by a good virtual machine program that performs "Just In Time" (JIT) compilation. Call void incrememtI(){ i++; ) a lot? The compiler will notice this, and replace calls in the stack to incrememtI() with the actual code this function contains. .NET does this with simple Properties...which results in a sincere benefit to using Properties for ALL inter-class data assignment and for some intra-class assignments as well.

This is why Metadata is a bad idea, or could be. No real benefit to the code, not much of a benefit for the "thorough" developer, and yet there's a real chance for lazy folks to create disgusting, hard to maintain code. This is never a good idea...a lot of coders think that obfuscated code makes them more valuable to employers. Not half...they'll axe you first if they think you're playing the obscurity game and will not give great references if you leave first.

Of course, if all Metadata does is replace:

// @Property:int ID

with:

private int id;
void setID(int value){ id = value; }
int getID(){ return id; }

Then it may be worthwhile. Time, and the Java Community, will tell.

(PS: Used to work for/with a Pat Doyle, but he's not you)

Re:So basically C# minus generics

[Anonymous Coward]

No, it reads like it was written by a programmer who understands what lambda expressions are and that the sort of 'generics' proposed for Java are cheap 'under erasure' model.

C# steals these ideas from Java

[SuperKendall]

All of these proposials have been around forever, I was attending talks on pretty much the same Generics syntax at JavaOne two or three years ago... and I've been using the same kind of enum classes since Java 1.1.

C# didn't add generics at the start as they were waiting for Java to solidify how to do them.

Also, Java has a bit more of a wait for new features since Java goes through a real standards body instead of just being defined by what Microsoft wants. And of course lots of real production code that can break if you get things wrong.

You can only use Generics in 1.5 VMs

[Anonymous Coward]

If you use Generics, your code will only run in 1.5 VMs. This was a marketing decision. Prototype versions of the Java compiler could previously use Generics and produce code for older virtual machines like the 1.1 VM.

Sun made this decision by itself without listening to its users and even censored its discussion. You can read about in the Generics message board:

http://forum.java.sun.com/thread.jsp?forum=316&thr ead=389987&tstart=0&trange=15 [sun.com]

http://forum.java.sun.com/thread.jsp?forum=316&thr ead=321534&tstart=30&trange=15 [sun.com]