I am not sure that benefits of Generics will outweight all complexity issues and drawbacks related with working with "legacy code" (which uses raw collections).

While Generics will remove need of one extra cast, thus improving readibility, just imagine how complex and unreadable code now can be written by folks that are crazy about OOP.

Also I think that JCP is going into wrong direction with Generics. I would like to see more AOP related features in language rather that improving OOP related things. We all know that OOP cant deal with crosscuting aspects therefore it's very limited.

Are they going to deprecate all raw collections, i.e. simple List ?
I am happy about good old collections and has never felt I need something like generics.

I would like to ask - do you really feel you need Generics ? Are you going to use it ?

The CREATION of a generic type usually more verbose than the non-generic one, since you need to provide the type:

List<String> l = new ArrayList<String>()

versus

List l = new ArrayList();

It is however simpler to USE a generic type:

String s = l.get(o);

versus

String s = (String) l.get(o);

So, depending on your type creation / usage ratio, you may need to type either more or less than before. But the main advantage is that you can catch type-related errors at compile-type, instead of at run time. Plus, unless you want to write generic classes, I don't think the program complexity grows.

Generics collections communicate type in a clear way.
Saving the cast is because you communicated to the compiler.
Communicating to humans is more important than communicating to the compiler so saving the cast is a secondary benefit.

How many people declare all of their arrays as:

Object[] array = new Object[10];

I sometime specifically use arrays because they allow me to describe type.
With generics this is no longer necessary.

The way to make Java simpler is to remove the array special case,
not to remove generics.

This is a very interesting question. The java implementation of generics does not offer any improvement with respect to application performance. It is simply syntatic sugar. This is largley due to the route that sun took in implementing generics in java. On the other hand, c++,C# generics is quite different. It is justifiable to me because using generics in c++ and C# will really improve performance. Hence, the additional complexity is worth it.

I think it should be pointed out that C++ "generics" aren't generic...
Templates in C++ can lead to bad code bloat, and aren't in general
sharable at runtime (they are code generated differently). While this
does lead to highly specialized versions of the code for a template class,
it can lead to many copies, and in a large complex system the performance
can drop due to instruction cache overflow.

Basically if you're in to that level of optimization, because your
inner loops are using such classes, you have a point, but for most
code most of the time, parameterized types are intuitive and just the
job. Moore's law tends to undermine the economics of complex
optimization, as witnessed by the failure of P-code in the 80's but
the rapid success of Java in the 90's... Programmer time is the most
expensive resource, which favours powerful elegant re-usable features,
and dynamic, portable, late-bound languages (look at the painless
process of using a library jar file, compared to the hairier process
of utilizing a C++ template library)

Java's straightforward dynamic linking strategy would have to be thrown
away to accomodate templates, and I think Occam's razor clearly indicates
this would be the wrong thing for Java, which after all is mainly over
to the dynamic side of the static/dynamic language spectrum.

I swear it'd be nice if posters had an competence rating next to their names so you could filter some out.

> All those Generics features are not very simple and intuitive at all.
I agree somewhat, but mostly for API designers. It is pretty simple to use a Generic collection but more complex to properly write one.

> I am not sure that benefits of Generics will outweight all complexity issues and drawbacks related with working with "legacy code" (which uses raw collections).
I guess we'll see. If it takes a little more coding to help the compiler verify that my code is type safe I'm game.

> While Generics will remove need of one extra cast, thus improving readibility, just imagine how complex and unreadable code now can be written by folks that are crazy about OOP.

Ok, you are starting to show ignorance here. The point of Generics isn't to simply remove the extra casting it is to make sure your code is type safe. Very important, eh? BTW: Are Generics really a OOP only concept?

> Also I think that JCP is going into wrong direction with Generics. I would like to see more AOP related features in language rather that improving OOP related things. We all know that OOP cant deal with crosscuting aspects therefore it's very limited.

Should have quit while you were ahead. :-) This is where you show your comments are foolish and should be completely be ignored. You think AOP replaces OOP? Going to write an AOP-only project soon? What are you going to apply all those aspects against?

>
> Are they going to deprecate all raw collections, i.e. simple List ?
> I am happy about good old collections and has never felt I need something like generics.
>
> I would like to ask - do you really feel you need Generics ? Are you going to use it ?

If you'd read the article you'd understand what is going to happen to all the "good ole collections". yee ha.

Of course, I'll use Generics. So will you, when you understand their purpose.

Well, I beg to differ. The Java community process used to be relatively good at addressing the needs and wants of Java developers. This is why Java was able to move much faster than C++ and became a more pragamatic, day-to-day work oriented language than the largely academic C++.

Now, I've seen a huge number of Java projects that would benefit from AOP like interception in Java. I never really heard many Java developers (even ex-C++ guys like myself) clamour for putting generics in Java. Has Sun lost touch with the community? Generics is fine (although breaks legacy code) but AOP stuff would probably be much more populare amongst your typical Java developer, particularly if he is a Java tools/containers developer.

AOP is available now in many forms. Though itt would
be nice to have a standard. Generics
really can only be had by folding it into
the language and changing libraries to take
advantage of the new features.

Type safety is more useful in complex environements
where there are a lot of programmers, lots of change,
lots of ways for things go wrong. In your personal development
there probably is never a compelling issue. When someone
is feeling pressured to fix a bug and make a change
at 1AM is where the benifits usually kick in.

When using perl to write even complex scripts i don't
care about typing nor do i unit test. It works fine 99% of
that time. In my other areas of work that 1% is not ok.
And my 1% will be someone elses 20% and that is definitely
not ok.

I don't know you so I can only judge your competency by what you write. I'll apoligize for being somewhat snarky but I stand by my remarks.

If you feel you are being misunderstood then spend more time on your posts to make sure you are being clear and are sticking to the point.

> You have misunderstood me. I dont think that AOP is replacement for OOP or Generics. And, yes, I know that main benefit from Generics is type safety check at compile time.
Didn't get that from your post.

> I just have never felt that I need those things. I have never had problems because I dont have static type check.
I don't understand this remark.

> If your opinion is different, than it's OK for me. It doesnt mean you should write insulting posts and claim that I hate SUN. In fact, I dont.

I never claimed that you hate Sun. My claim was that you didn't seem to know what you were talking about.

If it was not required, then no body will add it in C++ and use it. It has proved successful in the past, and it will be in future too.

>

Have you ever saw ATL code ?

> It provides strong type checking.
>
> Eg. Vector<String> data = new Vector<String>();
>
> Now, i am very sure that only string is added in the variable data. Compiler will check this error and i dont have to wait till run time.
>
Do you have any problems with type checking at this time ? I can not remember any "ClassCastExeption" problems in code dependant on java collections.

> Also, may be less code in some cases. Performance increase, may be yes, in future due to not requiring casting, etc.
>

I hope it so too.

> Also, read the tutorial. How much you may hate SUN, the still provide free tutorial and a JVM :)

I think SUN must be happy, some people hate SUN, but the same people ignore MS :)

The claim that what generic do is "improve readability by removing one
extra cast" completely misses the point.

Strong typing is a good thing. It makes programs safer.
It means the compiler catches errors instead of letting
them fester until runtime. Generics means that strong typing exists for collections.

Consider an API as a contract: if my interface I can say is that
I'm returning a Set then the contract is weak. People implementing the interface and people using the interface's methods have to communicate
via javadoc to get their typing right. If I can say that I'm returning a Set of Serializables then the contract is much stronger.

I am not keen an what someone here said about wanting "AOP-related features"
instead. Either damn well do AOP or don't do AOP, but don't piss about in the
middle. Consider the language you know that aren't OOP but have some "OOP-related features" - disasterous hacks, aren't they? If you want to do AOP,
then use AspectJ, no problemo.

And I'm surprised to see claims that generics are not something that
developers have wanted: lack of generics is one of the most common
criticism that developers I know have of Java.

I agree with the poster who said that Generics will benefit those who create APIs. I'd further venture to say that it will benefit those of us who use APIs. How many times have we all looked at the Javadoc for something that returns a Collection of Objects? If you know the API well, or the API developer has been very diligent and mentioned the type inside the Collection in his Javadoc, you can be sure to know what you're getting.
However, when you're getting to know a new API, it can be frustrating to guess or hunt down what types are contained within a Collection. This is especially true for projects on which you're using each others' code, and not using a third party API. I know we use lots of Collections, and it can be difficult to quickly trace which type the Collection contains. With the explicit syntax of the Generic Collections, this becomes very easy.
So, I'd say I welcome Generics.

If there is no bad effect of performance or causing faults, what do you care?

You mean, you do not care if they add any garbage to language as soon as it has no bad effect on perfomance or causing faults ?

Too much fuss about such a small subject as generics.
Generics proponents say that it makes programs type safe, meaning it fixes something. But they do not notice that no one in this forum ever had any problems with type errors on collections. I mean i do not mind if sun fixes problems in java. But this problem is purely theoretical and do not exist in real life.
As far as simpler synthax. Not a big deal really.
And implementation of generics in java just leaves much to be desired. We do not even enjoy performance benefit for using generics as say c# developers do.

I do not think introduction of generics in java is such a big and important subject. Let's get over it. There's much more important features that we can ask for including in java. AOP for example.

I do not think introduction of generics in java is such a big and important subject. Let's get over it. There's much more important features that we can ask for including in java. AOP for example.

I agree with you, generistics are cool, but adds no value.
Nobody has problem with "unsafe types" and it adds no readability,
see examples in this tutorial, I am sure it will be even worse in the real code (It is cool to write, but try to read something STL or ATL code).
I want to see more usefull features than cool like lambda functions (aka evil procedure pointers)

BTW There is "typedef" in C++, it can help to make generistic code more readable: "<<String,<<Integer>List>>Map> list = new .... "

Guys, have you ever written code that had to create complex structures and graphs of data that had to be transferred in one go? When you have collections of maps, which, in turn, consist of keys and values as maps (again). And so on. Going for XML is a huge impact on performance here. So many man/hours have been spent on just finding and fixing all those runtime classcastexceptions.

So, the answer is YES, WE URGE FOR IT. But, of course, nobody will hurt you if you just ignore it and write the code w/o generics. Just do not claim _we_ don't need it, say _only I_. (And I'm talking for my team, so consider it a group voice).

I don't know why so many people votes are against Java generics. My opinions are: make everything as typesafe as possible, let the compiler check my code, let the development environment check my code. These all helps to produce more correct and safe programs. Even more - in the past I wrote caches, background tasks and many other things where I was really missing the generics because they would help me to solve my problems without code copy/paste programming (there where to less usages [approx. 5 - 10] that a code generator wouldn't be a suitable solution). Sure there may be some learning necessary to use Java generics in the rigth way. The more critical problem with generics is that tool and library vendors use the features perhaps in 6 months, even later or never. Some want to support even JDK 1.1 where I cannot profit from the extensions delivered with "Tiger".

Concerning AOP: I vote for a standardized implementation too. But AOP is another topic and has not the aim to replace generics - IMHO.

Guys, have you ever written code that had to create complex structures and graphs of data that had to be transferred in one go? When you have collections of maps, which, in turn, consist of keys and values as maps (again). And so on.

Yes I have. It use special API for complex structures and this kind of structures are "hidden" in implementation and looks like "objects" in public API. I am not very big OOP fan, but it is a good use case for OOP. I agree it can look very cool with generistics, but I see nothing practical in generistics if you know how to use OOP.

It does not fix something, does improve something.
Like ++ operation in language, this self added operation can be substitute by the evaluator operation directly, why has a ++ operation? Conveniency,more way to target. We can use generic in our program or not. AOP is a good, but it's not a part of J2SE now. :)

Generics proponents say that it makes programs type safe, meaning it fixes >something. But they do not notice that no one in this forum ever had any >problems with type errors on collections. I mean i do not mind if sun fixes >problems in java. But this problem is purely theoretical and do not exist in >real life.

Yes, I agree. Java/J2EE developers has a lot of real life problems. Just watch TSS panel discussion about that. But JCP are adding "syntactic sugar" to language.

> I do not think introduction of generics in java is such a big and
>important subject.

We depend on so many libraries where raw collections are used. If I use Generics I will get millions of warnings.

I think AOP is nothing more than a buzzword. Oh, no, it's worse. It's a true evil which can bring the software development into chaos much more quickly than OOP did. It's like RDBMS triggers. Cool feature, eh, but would you remember when you've used it last time? And wow, how much time it took to debug the code?

AOP is a two-dimensional chaos. You'll never know when and how the current aspect will work.

I think AOP is nothing more than a buzzword. Oh, no, it's worse. It's a true evil which can bring the software development into chaos much more quickly than OOP did. It's like RDBMS triggers. Cool feature, eh, but would you remember when you've used it last time? And wow, how much time it took to debug the code?

>

Yes, AOP is very easy to missuse too. May be it is not so bad as you think
(triggers are not so bad too, I use triggers for very complex data validation in RDBMS ). I use AOP ideas without problems and new programming languages too.
I think AOP is more cool than usefull at language level too, there are
a lot of good frameworks and tools to implement this idealogy and I do not think
it is possible to find the best one and to use it as JAVA language feature.
May be some core interception API can be more usefull for AOP implementations.

> AOP is a two-dimensional chaos. You'll never know when and how the current aspect will work.

Also I think that JCP is going into wrong direction with Generics. I would like to see more AOP related features in language rather that improving OOP related things.

Generics are not about OOP they are about static type checking.

> We all know that OOP cant deal with crosscuting aspects therefore it's very limited.

OOP can't deal with anything, software designers deal with things. And they do it either by ways of language features or through design patterns. There are lots of patterns that deal with crosscutting concerns and there will always be a debate about which design patterns should be promoted to language features and which ones are too special purpose to merit direct language support. I haven't made my mind up with regard to aspects.

> I would like to ask - do you really feel you need Generics ? Are you going to use it ?

The question should be (and is often) asked more generally: Do you really feel you need static typing? My answer is: I need it at the boundaries of components where I want communicate in a formal manner what the requirements of the component are. I don't need it within the boundaries of a component where a single person is able to understand all the code. So, for me, static typing is an encapsulation thing and should therefore be optional.

> Generics are not about OOP they are about static type checking.
>
Yes, Generics are more about anti OOP, it is workaround for
static type data containers vs object model (it can be not so bad too for simple model too).

----------
> Now, i am very sure that only string is added in the variable data. Compiler will check this error and i dont have to wait till run time.
>
Do you have any problems with type checking at this time ? I can not remember any "ClassCastExeption" problems in code dependant on java collections.
----------

Generics make the code more self documenting - you can tell the type of a containers elements directly from its declaration. Persoanlly the risk of occasional class cast errors doesnt bother me, but having to read implementation code to figure out what coantainers contain does.

> > Now, i am very sure that only string is added in the variable data. Compiler will check this error and i dont have to wait till run time.
> >
> Do you have any problems with type checking at this time ? I can not remember any "ClassCastExeption" problems in code dependant on java collections.
> ----------
>
> Generics make the code more self documenting - you can tell the type of a containers elements directly from its declaration. Persoanlly the risk of occasional class cast errors doesnt bother me, but having to read implementation code to figure out what coantainers contain does.
>
I do not think generistcs ar very usefull for self documenting :

Try to write something more complex like list of maps and some operations with generistics and without ( model vs data containers ).
I think you will start to hate this kind of self documenting in generistics,
I do not want to write this example, you will start to hate me :)

1. the discrepancy between compile time types and run time types will drive people nuts. java is f-ed when the source code doesn't look like the execution. I don't care whatever reasoning they had, this is a big mistake.

2. I really miss the previous version with variance concept/syntax. sigh...

overall I'll like to use it myself, and I'll hate to see bloody abuses by others:)

Here's one answer: Java doesn't have header files. Try to build a C++ DLL (without any header files) where you use templates and then try to use inline exapansion with that DLL. The DLL is just like a class file (i.e. a compiled binary), and inlining is too late when the stuff is compiled. This kind of thing would have changed Java quite a bit and at least I'm happy it didn't happen.

And finally, with 15 years of C++ experience I have to say I'm really excited to see Java generics and auto-boxing in real use. I'll use them whenever it's possible, but in the world of diverse set of application servers we have to support this will probably take quite long time!

I think a lot of people might be missing the point. Generics aren't just about strong type checking. The last time I had an error due to a miscast was about ... never. And if I ever did I'm sure it'd take about 30 seconds to fix. The real value of generics (and I think what swayed the jcp group) is that they make code easier to read and maintain. When you come back to a piece of code you wrote six months ago you no longer have to guess exactly what 'accessMap' is mapping or read the code to find out. Now it'll be clear, ie Map<String,User> so it's probably mapping logins to User objects. Contracts also become a lot more expressive. If you've ever dealt with old code that takes a List as a parameter but the javadoc don't say a list of what then you know what I mean. So yeah, generics are a good thing. They don't do too much that good javadoc didn't do before but since devs are often too lazy to write good javadoc, generics are a keen way to force em.

My gripe with generics is their tendency to increase coding complexity rather than reduce it. I have many disturbing memories of generics in C++. Some of it was so complex that I had to give up understanding it and in the end just hoped it worked. As an example, look at the sources for the STL and the many interdependencies between the templates. I frequently delve in to the sources of the standard Java APIs; but STL? I always stayed clear.

I must say I'm a bit surprised by the number of times C++ templates are referred to in an attempt to demonstrate that Java generics aren't a Good Thing[tm]. The two are totally different beasts. C++ templates are a Turing-complete language interpreted by the compiler; Java generics are definitely not.

Virtually anything that makes the Java language more expressive of the programmer's intent pushes my buttons. Generics are a Good Thing[tm].

Regarding AOP, it's already there and quite usable (Aspectwerkz, Nanning, Spring...). I don't think we're ready yet for AspectJ-style AOP that is part of the language itself.

>
> > I have many disturbing memories of generics in C++.
>
> I must say I'm a bit surprised by the number of times C++ templates are referred to in an attempt to demonstrate that Java generics aren't a Good Thing[tm]. The two are totally different beasts. C++ templates are a Turing-complete language interpreted by the compiler; Java generics are definitely not.
>

Yes, java generistics are even more limited than C++ templates.

> Virtually anything that makes the Java language more expressive of the programmer's intent pushes my buttons. Generics are a Good Thing[tm].
>
Yes, it is a Good Thing[tm] as ansver to .NET generistics or cool as something new in JAVA, but I see nothing practical in generistics (C++ templates are not very practical too, this kind of code generation in C++ sometimes helps to avoid OPP, but I think it is nothing bad to use OOP if you need it ).

I had a project recently with several similarly named EJBs (Sample, SampleList, SampleInList, etc) and had ongoing headaches with type-casting typos causing runtime errors. The new generics feature, if incorporated into EJB iterators, would have been a blessing. Of course if i'd been a more attentive programmer i wouldnt have made the mistakes in the first place, but whats a compiler for if its not help slack programmers?

Actually one place I feel generics will be used for a lot is in interviews. This will be where someone wants to show off how well they know the syntax of the language. :-)

It is kind of a shame that most people including my self had exposure to the pain that was C++ templates. I suppose not matter how good generics turned out to be they would always be compared to their less than perfect brother in the religous wars that developers often have.

The ability to compile time checking will be a big bonus especially for J2EE developers where compile and deployment times are high. Waiting 5 mins to find that you have accidently miss cast something in your code will be a big bonus. However I doubt there will be a 1.5 compliant app server for quite a while.

For me I still have my doubts about adding something so complex into the language. One of the reasons I always think Java took off is becuase it was simple. People have from the early days have complained certain stuff was missing. However at the end of the day this allowed you to navigate around some of the programming pitfalls less all inclusive elegant languages had.

Anyway in the end generics are here to stay now so I suppose we better get used to them.
David

"The ability to compile time checking will be a big bonus especially for J2EE developers where compile and deployment times are high. Waiting 5 mins to find that you have accidently miss cast something in your code will be a big bonus. However I doubt there will be a 1.5 compliant app server for quite a while. "

I have extended many a OSS project by extending a few select classes and pluging in little bits of code to do what I want, but should these generics become popular, that's shut down completely. Now I either have to affect "stock" classes directly or, even worse, reengineer how those classes migrate through the system.

If all you do it program to interfaces, then this isn't a problem, but inheritance is a perfectly valid technique to specialize classes.

Retrofitting legacy code looks like its going to be an all-or-nothing affair. These things seem pretty darn viral and will bubble out of interfaces until they hit the entire system. Updating our 100,000 lines won't be any fun and I doubt we'll bother, since once we start a section we have to finish it and can't really go "part way". "Don't mind me while I check out the entire tree to type all of our collections, folks!"

Finally, it's not clear to me how these are actually implemented.

In Java:

String s = (String)hashMap.get(key);

The Cast has a cost at runtime, since it must ensure that we are actually getting a String.

But, with generics:

String s = stringMap.get(key);

Does it still perform the cast internally? It has too, since at some point we could have "lied" to the system and cast an arbitrary Map into a Map<Key, String>. And this save us...what?

Nope. Uhuh..I'm underwhelmed and I dred this being proliferated into the community.

which will screw up your program. The generics variance mechanism gives you the proper workaround for this, which is really great.

> Retrofitting legacy code looks like its going to be an all-or-nothing affair. These things seem pretty darn viral and will bubble out of interfaces until they hit the entire system. Updating our 100,000 lines won't be any fun and I doubt we'll bother, since once we start a section we have to finish it and can't really go "part way". "Don't mind me while I check out the entire tree to type all of our collections, folks!"

And why is that? From what I have seen a hell of a lot of compromises have been made to allow precise this.

I will definitely use generics and am most appreciative of the JSR group that defined them. Most of the good points have been stated already. I'd like to point out one more:

In JDO it is necessary for the persistence descriptor to identify the "element-type" of each collection. Mapping to a database when the root type is "Employee" allows an efficient join to the EMPLOYEE table; if the root type is "Object" then such efficiency is not possible.

It is feasible that the burden of identifying such element types will be reduced by JDO Implementations whose enhancers correctly recognize these types. Should I ask the JDO Expert Group to specify in JDO 2.0 that the notation of element types be explicitly optional in a JDK 1.5 environment, so as to assure portability for such a short-cut?

It is unfortunate that their implementations do not also implement java.util.List<Node>. For example, we cannot reuse our code, e.g., to filter a NodeList to obtain a new NodeList whose items satisfying a given condition.

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.