Discussions

Bruce Eckel has made his thoughts pretty clear when it comes to JDK 5 Generics. He doesn't like the fact that they are compiler sugar. Now he is getting past the politics and delving into the side effects that this choice leaves us with, which leads us into other parts of JDK 5.

Let's first consider a very basic impact of erasure. If I have a type parameter T, not only am I prevented from making an instance of that type (because, with erasure, the type is forgotten), I cannot make an array of that type. However, I can generate an array of Object and cast it to T[].

...

If you look through ArrayList.java, you'll find plenty more of these casts. And what happens when we compile it?

Sure enough, the standard libraries produce lots of warnings. So "cast-and- ignore-warnings" is the acceptable idiom for JDK 5.0. I'm told that in a future release (I'm guessing a point release of JDK 5), SuppressWarnings will be enabled, and at that point the warnings will become meaningful again.

I don't understand why people object to the new features..The only thing I don't like is autoboxing..Generics cuold be done better, but at least we get to use them..

people are afraid of change, in IT as well as elsewhere.They fear being left behind by younger people who learn faster, fear having their precious certifications suddenly branding them as obsolete instead of state of the art for mentioning they're 1.4 certified.

I have some doubts as to the usefulness of some of the new features myself, and feel that metadata is a dangerous direction to take, but I don't fear them.

Instead I'll decide when the time comes whether they're useful to me or not and use them as seems fit.

I am getting quite concerned about the new Java features. Chasing C# isnt really doing Java any major favours in my opinion. What seems to be happening is the migration of design pattern knowledge into syntax. Sure, we can use 'generic types' to ensure the consistancy of instance types in a collection, but I already know how to do that with simple wrapper encapsulation (A standard concept that once understood is useful for hundreds of other situations also). So I have to cast down when extracting from the list, a minor annoyance that has the benefit of keeping the code verbose (My IDE does this for me anyway).

C# has delegates, which, when you break it down is a syntax formalization of the observer pattern.

It seems to me, that all this added syntax is doing is raising the bar for new developers to get started in the language. I have been coding in Java for nearly 6 years and I am struggling to get my head around the new feature 'end-cases'. I dread to think how the junior guys are getting on.

IMHO Java got to where it is by being a simple language syntax-wise but with a rich set of 'best-practices' and design patterns to provide simple, elegant solutions.

I hope I am wrong, but I have a sneaking feeling that this release will do more harm that good... time will tell I guess.

Are you trying to say java is not as simple a a general purpose language should be? Java is not a complex language. It lacks many of the idosyncrasies of other languanges, and has space for more features before it becomes hard to learn.

I agree with your points - java as originally designed is an exemplary language in simplicity and taste.

What worries me is the decision process at Sun.

The basic proposal and implementation of GJ was ready back in 1998. Fortunately Goosling & Steele had the wisdom/desire/stamina to hold the line - not letting these kind of *features* into the language. People at Sun in general understood that language evolution should focus on primitives, not features.

Then .NET come along. Being late to the game, Microsoft tried very hard to rewrite the rules to its favor. There were concerted effort at conferences, standard processes, trade pubs, Internet message boards to promote the idea that features = innovation. C# is better than java because it has more features. Remember around 2001-2002 in any technical discussion board, how many time have you seen someone innocuously drop in a line, "autoboxing in C# is blah blah"?

Lo-and-behold, Sun fells right into the trap. Right after GJ was let into Tiger, C# came out with a bunch of gotta-have, new-and-improved features. And java vendors and developers are stuck with the unpleasant tasks of dealing with GJ. *sigh*.

It seems java's gatekeepers are no longer there. One has to worry what'll happen to java when the decision process seems to be dominated marketing considerations.

Developers who are entering the area are getting really bogged down by libraries. Its now has outgrown and offers way too many functionalies. They are getting confused what to use and how to use. I once talked to a junior developer who lamented that he was unable to grasp the concept of templates in C++ and is now forced to do so in Java through generics. I think sun needs to look at those 1-2 years experienced people who make up the bulk of the programming world.

The risk in not improving the libraries and language is obsolescense. C++ really extended the life of C by many years.

VB had to go because of its shortcomings.

The Java language needs to add features (I agree that some of the ones in Java 5.0 are lame); the ever-present demand for more productivity requires it. A more expressive language can make things more complex but can yield cheaper/better applications.

I'm all for a better Java language or a replacement of the Java language.

I'm all for a better Java language or a replacement of the Java language.

We all want a better Java language. I don't have bad feelings about the new features. In fact, I like the idea to have generics, metadata, autoboxing, ... (and this since I've read a book about C# a few years ago). But I have bad feelings about the way these features have been added to the Java language. As Microsoft did with C#, Sun could have thrown the compatibility by adding a keyword like "unmanaged" when calling old code and this would have allowed for a cleaner implementation of these new features in the JVM.

I think sun needs to look at those 1-2 years experienced people who make up the bulk of the programming world.

Are you serious? it is 2004 almost 2005. even Dotcomers after "Java in 24 hours" are in IT for 4-6 years...Nope. Language and APIs should target experts, because small team of experts with appropriate tools can do projects, which even huge gang of greenhorns simply cannot.

This is one of those issues that make you go Doh! If something is added to Java it should be well thought out and complete. This erasure stuff causes extra head aches and complexity to the language. To me it only looks like a big kludge, not a language-worthy feature.

If backwards compatibility is an issue, then do not include such silliness to Java at all. If the feature is really useful and should be part of Java, then God Damn, break the backwards compatibility and add a flag to the compiler/VM to handle the old stuff.

- Try to add Graph collections to the current collections library. Many real world problems would benefit from a concise graph theoretic solution; thats why people draw diagrams when trying to understand. Every algorithm you can think of returns nested collections of some sort:

- AspectOriented containers / Middleware. Try to grab any arbitrary object in memory and remote it out by merely specifying an endpoint to remote it to. (For instance, a SOAP service that if you do a .bind(url,object), then it will generate WSDL and respond to request for that object). If you actually designed this object to take advantage of collections, by using List,Set, Map in the interfaces.... (think of Hibernate classes) ... then the container will be at a loss when it encounters such collections.

- Visual Modelling. Throw a jar file into your IDE, and if you have first class generics (without erasure), then it can discern that: Employee has a one to many relationship to Employee because of the List<Employee> typed member. With type erasure, your APIs might be just a giant amorphous hub around Object, List, and Map with no obvious relationships between objects. And we all know that Visual Modelling tools that lose the intent of what you are doing and get out of sync just don't get used as much as management would like.

Now imagine Microsoft building these sorts of capabilities off of its first class generics; they will.

There seems to be a curious relationship between making design patterns part of the language, incorporating "generics" (type parameterization), and AOP... Hopefully when the Java spec or its successors get around to dealing with the type erasure issue, we will be further along in thinking about a single mechanism that can simplify all these inter-related problems.

It seems that where we are headed is to operating systems in which all code is VM based... where you can select an arbirary object from a process and apply remoting/logging aspects to it, or to graph its static/runtime structure. Type parameterization seems to play a big role in enabling this to be done properly.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.