Java Generics and Collections

andrew cooke writes "Java 6 was recently released, but many programmers are still exploring the features introduced in Java 5 — probably the most significant changes in the language's twelve year history. Amongst those changes (enumerations, auto-boxing, foreach, varargs) generics was the most far-reaching, introducing generic programming in a simpler, safer way than C++ templates and, unlike generics in C#, maintaining backwards (and forwards) compatibility with existing Java code." Read on for the rest of Andrew's review. Java Generics and Collections author Maurice Naftalin, Philip Wadler pages 273 publisher O'Reilly Media, Inc. rating 9/10 reviewer Andrew Cooke ISBN 978-0-596-52775-4 summary Guide to Java generics; also includes interesting discussion of collection classes.

Given the history of Generic Java, Naftalin and Wadler's Java Generics and Collections has a distinguished pedigree. In this review I'll argue that this is a new classic.

If you're a Java programmer you've probably heard of generics, an extension to the type system that was introduced in Java 5. They give you, as a programmer, a way to write code even when you don't know exactly what classes will be used.

The obvious example is collections — the author of a List class has no idea what type of objects will be stored when the code is used.

Before generics, if you wanted to write code that handled unknown classes you had to use make use of inheritance: write the code as if it would get Objects, and then let the caller cast the result as necessary. Since casts happen at runtime any mistakes may cause a runtime error (a ClassCastException).

Generics fix this. They let you write code in which the classes are named (parameters) and the compiler can then check that the use of these class parameters is consistent in your program. So if you have a List of Foo instances you write List<Foo> and the compiler knows that when you read that list you will receive a Foo, not an Object.

I'll get to the book in a moment, but first a little history. If you know any type theory — particularly as used in functional languages like ML and Haskell — then you'll recognize my quick description above as parametric polymorphism. You'll also know that it is incredibly useful, and wonder how Java programmers could ever have managed without it.

Which explains why Philip Wadler, one of the people responsible for Haskell, was part of a team that wrote GJ (Generic Java), one of the experimental Java mutations (others included PolyJ and Pizza) that, back in the day (late 90s) helped explore how parametric polymorphism could be added to Java, and which formed the basis for the generics introduced in Java 5.

So if you want to understand generics, Wadler is your man. Which, in turn, explains why I jumped at the chance to review O'Reilly's Java Generics and Collections, by Maurice Naftalin and Philip Wadler.

This is a moderately slim book (just under 300 pages). It looks like any other O'Reilly work — the animal is an Alligator this time. It's well organized, easy to read, and has a decent index.

There's an odd discrepancy, though: Wadler is the generics Guru; this is going to be `the generics reference'; generics are sexy (in relative terms — we're talking Java here) and collections are not; the title has "Java Generics" in great big letters with "and Collections" in little tiny ones down in a corner. Yet very nearly half this book is dedicated to collections.

Generics is a great, practical read. It starts simply, introducing a range of new features in Java 5, and then builds rapidly.

If you are completely new to generics, you'll want to read slowly. Everything is here, and it's very clear and friendly, but there are not the chapters of simple, repeated examples you might find in a fatter book. Within just 30 pages you meet pretty much all of generics, including wildcards and constraints.

If that makes your head spin, don't worry. Read on. The next hundred or so pages don't introduce any new syntax, but instead discuss a wide range of related issues. The chapters on Comparisons and Bounds and Declarations contain more examples that will help clarify what generics do. And the following chapters on Evolution, Reification, and Reflection will explain exactly why.

So the first seven chapters introduce generics and then justify the implementation — any programmer that takes the time to understand this will have a very solid base in generics.

There are even some interesting ideas on how Java could have evolved differently — section 6.9 Arrays as a Deprecated Type presents a strong case for removing arrays from the language. It's a tribute to the clarity and depth of this book that the reader is able to follow detailed arguments about language design. Fascinating stuff.

The next two chapters, however, were my favorites. Effective Generics and Design Patterns give sensible, practical advice on using generics in your work, including the best explanation of <X extends Foo<X>> I've seen yet (so if you don't know what I am talking about here, read the book).

(A practical word of advice — if at all possible, use Java 6 with generics. Java 5 has a sneaky bug).

The Collections part of the book was more along O'Reilly's `Nutshell' lines: the different chapters explore different collection types in detail. I must admit that at first I skipped this — it looked like API docs re-hashed to extend the size of the book.

Then I felt bad, because I was supposed to be reviewing this book (full disclosure: if you review a book for Slashdot you get to keep it). And you know what? It turned out to be pretty interesting. I've programmed in Java for (too many) years, and I guess I've not been quite as dedicated to tracking how the library has changed as I should have been — I learned a lot.

Again, a wide range of readers are welcome. This is more than a summary of the Javadocs, ranging from thumbnail sketches of trees and hashtables to a discussion of containers intended for multi-threaded programming.

The way I see it now, this part is a bonus: the first half, on generics, makes this book one of the standards; the second half is an extra treat I'm glad I stumbled across (I guess if you're some kind of weird collection-fetishist maybe it's even worth buying the book for).

I've used generics since the first beta release of Java 5 and had experience with parametric polymorphism in functional languages before that (in other words, I can tell my co- from my contra-variance). So I guess I'm heading towards the more expert end of the spectrum and I was worried I'd find the book boring. It wasn't. After claiming to be expert I don't want to spoil things with evidence that I'm actually stupid, but reading this book cleared up a few `misunderstandings' I'd had. I wish I had read it earlier.

If you're new to generics, and you don't mind thinking, I recommend this book. If you're a Java programmer who's a bit confused by <? super Foo> then this is the book for you.

The only people who shouldn't read this are people new to Java. You need to go elsewhere first. This is not a book for complete beginners. This is a great book in the classic — practical, concise and intelligent — O'Reilly mould.

You can purchase Java Generics and Collections from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

It's only Java 6?

[Anonymous Coward]

I was really hoping they'd make another leap up to Java 60.

Re:It's only Java 6?

[Anonymous Coward]

I'm waiting for Java 616.

Re:Propz To Dead Homies yo!

[$RANDOMLUSER]

It's hard to beleive you're posting at -1

Generics are basically good.

[Z00L00K]

But it can in some cases be tricky when you get a really complex structure of Vectors containing Vectors containing Comparables. Not that it's impossible, but it can be a challenge.

One thing that I found in Java5 was that it lacked generics for several cases, e.g. Awt/Swing objects that were able to contain Object themselves. Not that it was a big problem, but it wouldn't have been bad to have that support there too...

Anyway - Generics is one of the best features of added to Java lately. It really helps. How I miss it when I'm programming for J2ME...

Re:Generics are basically good.

[Kobayashi Maru]

I've had trouble with generics myself. I don't claim to be a programming superstar though, so I might be overlooking something simple. My problem is that I cannot get a (useful) array out of a vector. No matter what I do, Vector.toArray() will only return an array of Objects. But I don't want Object[], I want something specific. And I thought that is what generics were supposed to do: declare a vector, use generics to tell Java what kind of objects are in it, and get rid of all those nasty casts. Unfortunately, this doesn't seem to be the case. It seems that the information is lost at runtime, do to what Google tells me is "type erasure." There is an open bug on the subject, which I think is related. Regardless, I find it rather annoying and cumbersome to work around.

Re:Generics are basically good.

[bunratty]

It's been years since I've written Java, but
SpecificClass[] sca = scv.toArray(new SpecificClass[0]);
should do it, right?

Re:Generics are basically good.

[twbecker]

I wouldn't hold your breath if you're waiting for a deprecated class like Vector to get retrofitted with generic methods.

Re:Generics are basically good.

[MCTFB]

Generally, the way you do this (with or without generics), is to call the toArray(Object[] array) method, rather than the toArray() method.

Basically, just do this where foo is the type in the array and fooList is your Collection of Foo objects.

Foo[] foos = new Foo[fooList.size()];
fooList.toArray(foos);

The foos array now is populated with the contents of the fooList.

The toArray() will return an array of type Object, so you will need to use the argument supplied version of the method if you want the component type of the array to be a particular type.

Re:Generics are basically good.

[roscivs]

But it can in some cases be tricky when you get a really complex structure of Vectors containing Vectors containing Comparables. Not that it's impossible, but it can be a challenge.

The problems with Comparables usually come about because of a failure to implement Comparable instead of just implement Comparable. Java typically won't tell you that's the problem, it will steer you off into some other wild goose chase, but if you implement Comparable the challenges typically disappear.

Re:Generics are basically good.

[bunratty]

As I show above, it already has been. In fact, being an AbstractList, it must have generic methods.

Re:Generics are basically good.

[twbecker]

I stand corrected. My intent was more to prod the OP into moving away from using Vectors, but that information is valuable nonetheless.

Re:Generics are basically good.

[bigdavesmith]

I'm just a casual Java programmer, but is Vector really depreciated? Looking at the 6.0 Specifications it doesn't appear to be. Should this class not be used?

Re:Generics are basically good.

[twbecker]

Yes it is. ArrayList is a much better choice nowadays.

Re:Generics are basically good.

[radish]

To clarify, it's not technically deprecated (i.e., there are no plans to take it out of the class library) but it's use is generally frowned upon these days. As was already mentioned, ArrayList is almost always a better choice.

Re:Generics are basically good.

[gkhan1]

I'm sorry, but I don't know what you are smoking. Vector is entirely retrofitted to use generics, and it does it fine. And a comment like "ArrayList is a much better choice nowadays" is complete BS. They are virtually identical, with one important difference, spelled out in the documentation: "This class is roughly equivalent to Vector, except that it is unsynchronized". Meaning that if you ever plan to do anything with threads, stick with Vector. In fact, always stick with Vector. It's a better class, and there is no good reason not to do it. Vector is in no way deprecated, and it never will be.

Second, it's not hard at all to get a Foo[] array from a Vector. Just pass a Foo[] array to the toArray() function and it will fill it. It's dead easy. If you're really lazy you don't even have to size it correctly, the class will do that for you. Just tell it what type it should be in and it will do all the work. This is literally one line of code.

Re:Generics are basically good.

[Anonymous Coward]

That'll work, but it's somewhat better to do this:

SpecificClass[] sca = scv.toArray(new SpecificClass[scv.size()]);

Since you save the extra array initialization (the 0-length array you pass in) and the reflection call to instantiate the array of the proper type. Not that anyone concerned about speed would ever use a Vector in the first place...

Re:Generics are basically good.

[the_lesser_gatsby]

Meaning that if you ever plan to do anything with threads, stick with Vector.

Actually, no. Use ArrayList and synchronize access to it where needed in your code. The synchronization in Vector is a very blunt tool.

Re:Generics are basically good.

[curunir]

Meaning that if you ever plan to do anything with threads, stick with Vector. In fact, always stick with Vector.

The problem with this logic is that the synchronization provided by the Vector class is, at best, useless. At worst, it's a recipe for disaster.

The Problem is that the synchronization is applied at the method level. That means there's nothing to stop invocations of different methods from both attempting to update the same data inside the vector at the same time, which can cause bugs that are almost impossible to track down.

The GP was correct...if you need synchronization, use and array list and either declare it to be synchronized or access it within a synchronized block. The Vector and Hashtable classes really have no place in code that doesn't need to compile under ancient versions of Java.

Re:Generics are basically good.

[bckrispi]

Meaning that if you ever plan to do anything with threads, stick with Vector. In fact, always stick with Vector.

This is wrong on several levels. First, if you need a threadsafe List, the recommended way of getting one is with Collections.synchronizedList(). Secondly, having a class (such as Vector) that has all of its methods synchronized forces you to deal with the overhead of synchronization whether you need it or not - with *every* method call. Imagine a tight loop that inserts x objects into a Vector. That equates to x object locks required - which is a relatively expensive operation. A much more efficient way of doing this is to locate where your Thread contentions may occur, then use block-level (rather than method-level) synchronization.

Vector, and its cousin Hashtable have been legacy components since java 1.2 was released (in 1999). There is no compelling reason to still be using them for new development.

Re:Generics are basically good.

[Logic and Reason]

Do generics actually add any complexity in that case, though? Even without generics you still have to know the types of everything involved-- generics just make that explicit so the compiler can check it for you. If it's the syntax you're talking about, it seems to me no more and no less complex than necessary (though the angle-bracket notation was already familiar to me from C++ templates).

Re:Generics are basically good.

[bunratty]

It's true that you could save an extra array initialization. On the other hand, if another thread adds one more element in between the call to size() and the call to toArray(), that could cost an initialization of a large amount of memory. There's no overall "best" way to write the code; I showed the simplest and the one with the least risk of wasting time.

Re:Generics are basically good.

[bunratty]

The Problem is that the synchronization is applied at the method level. That means there's nothing to stop invocations of different methods from both attempting to update the same data inside the vector at the same time, which can cause bugs that are almost impossible to track down.

You need to read up on how synchronization is done in Java. Any synchronized method will obtain a lock on the object itself, and therefore it is impossible for two different synchronized methods to update the data inside the vector at the same time.

It's somehow strangely comforting that Java programmers still don't know Java well after all these years. A word of advice: just because Java is "simple" doesn't mean you shouldn't pay attention to the details and learn them well.

Re:Generics are basically good.

[pjt33]

Generics is one of the best features of added to Java lately. It really helps. How I miss it when I'm programming for J2ME...

Are you aware that javac 1.5 supports -target cldc1.0 ? If you're writing for CDC then you can strip the pre-verification attributes with any good class file optimiser. Strangely javac 1.6 doesn't have that option; I'm not sure whether something replaced it.

Re:Generics are basically good.

[cytg.net]

i havent looked at the code, and cant be arsed right now.. but i WOULD assume that vetor.toArray(customarraytype) saves the initialzing of a new array and uses the one you've supplied... i'd also expect it to spank you if it wasnt vector.size() sized.

Re:Generics are basically good.

[Nevyn]

I believe the GP was talking about this problem, with reading and writing the Vector at the same time (not writing from two threads). Which is not threadsafe.

Re:Generics are basically good.

[Anonymous Coward]

"It's somehow strangely comforting that Java programmers still don't know Java well after all these years."

Looking at the discussion going on, I'm glad I chose not to bother learning Java before.
Maybe Java >=6 might be worth spending time on.

Re:Generics are basically good.

[bunratty]

It does save the initializing of the new array if it is large enough, but will silently initialize a correctly-sized array if it is too small, and use a larger array if it is too large. The point is that the size could change in between when you requested it and when you added the new element. Read up on multithreaded programming. Statements in Java are not atomic.

Re:Generics are basically good.

[bunratty]

It isn't threadsafe for any collection. No matter what collection you use, you need to lock it before you enumerate it if there's a chance another thread might add or delete elements during the enumeration.

Re:Generics are basically good.

[Nevyn]

It isn't threadsafe for any collection.

Exactly ... so if you need to Enumerate the collection, you need locking outside the collection primitives (which need to be placed everywhere you use the collection) ... And those work for Collections that lock their primitives and those that don't, so you gain nothing by putting locks on your primitives and lose something ... so it's considered a bad idea to put locks on your primitives.

Re:Generics are basically good.

[Skjellifetti]

That equates to x object locks required - which is a relatively expensive operation.

Not really. Even by 1.3 for many cases synchronization costs were often quite small. There is no compeeling reason these days to afraid of the performance penalty of method/object synchronization.

Re:Generics are basically good.

[bunratty]

That's true, but that's not what the GGGP was saying. He said "there's nothing to stop invocations of different methods from both attempting to update the same data inside the vector at the same time" which is false. He's thinking that the lock is applied to the method, so one thread could be adding an element to a Vector at the same time another is trying to delete one. That's a complete misunderstanding of how Java handles synchronization.

Re:Generics are basically good.

[cytg.net]

i was actually pondering on putting a disclaimer in my post "threadsafety aside" .. we're talking, well i am, linear performance and while yes it may fuck up the intended performance gain, on occasion(if more i'd say you have a design flaw somewhere), its still a valid construct imo. take the hit if its needed otherwise get on with business..

Re:Generics are basically good.

[bckrispi]

^ I have benchmarks against the 1.5 JVM that show otherwise...

Re:Generics are basically good.

[jjoyce]

Actually, no. Use the blunt tool first and then profile to determine whether you need finer-grained exclusion. Concurrency is difficult to get right; it is therefore better to avoid the complexity if possible.

Re:Generics are basically good.

[ultranova]

It's true that you could save an extra array initialization. On the other hand, if another thread adds one more element in between the call to size() and the call to toArray(), that could cost an initialization of a large amount of memory. There's no overall "best" way to write the code; I showed the simplest and the one with the least risk of wasting time

So preallocate an array with size 1, and let the next minor garbage collection cycle deal with it. Problem solved :). Or just synchronize on the vector:

synchronized(vec) { SomeClass myarray[] = new SomeClass[vec.size()]; myarray = vec.toArray(myarray); }

Re:Generics are basically good.

[ultranova]

The problems with Comparables usually come about because of a failure to implement Comparable instead of just implement Comparable. Java typically won't tell you that's the problem, it will steer you off into some other wild goose chase, but if you implement Comparable the challenges typically disappear.

I love the irony of how a text about Java generics seems to have lost some information between the source and compiled states, therefore leading to much confusion :).

Will I get a ClassCastException if I guess you were talking about the difference between Comparable and Comparable<T> ?-)

Re:Generics are basically good.

[optevo]

More importantly, use a List interface (or even better, a Collection if you don't need all the methods in List) to reference whatever type you decide to instantiate. That way, you can change between ArrayList, Vector, LinkedList - and a whole lot of other types by just keeping the change in one place - where the variable was initialized. If you use Collection, you can use ever more types. Remember, your program is a "living" thing - it _will_ change so make it easy for it to change by using interfaces appropriately...

All I really wanted...

[Lockejaw]

... was a quick and dirty intro to Java generics. I've had trouble finding that on Sun's site (especially ones with good code examples), but Google returns some good results. Given the availability of free tutorials, I probably wouldn't buy the book just for that.
That said, this sounds like a good resource on Java Collections in general (though Sun's javadocs are pretty nice themselves), as well as the other features introduced in Java 5. There also seems to be some discussion of more complex generic structures.
I'm still a bit lukewarm about buying it, but if I were getting back into a lot of Java stuff, I probably would.

Re:All I really wanted...

[metamatic]

http://java.sun.com/j2se/1.5/pdf/generics-tutorial .pdf

http://java.sun.com/docs/books/tutorial/extra/gene rics/index.html

Also highly worthwhile is http://java.sun.com/docs/books/tutorial/collection s/index.html which describes the generics-enabled standard collection classes, which is 90% of what you'll want generics for anyway.

Share and enjoy.

Re:All I really wanted...

[Lockejaw]

Those are what I'd found before. They have the information, just not packaged the way I'd wanted it. I like the short descriptions from the javadocs -- their tutorials are generally less concise.

Re:All I really wanted...

[metamatic]

Oh, I thought the problem was that the JavaDocs weren't detailed enough.

I do wish Sun's JavaDocs generally had more examples. Like, at least a couple of examples per class.

Re:All I really wanted...

[Anonymous Coward]

http://java.sun.com/j2se/1.5/pdf/generics-tutorial .pdf one of the best tutorials out there.

Java 'generics' are not real generics

[Cyberax]

Java generics are not real generics, then you parametrize a generic class in Java you don't really create a new type. You just attach some information for Java compiler so it can perform automatic casting and save you some typing.

Java generics don't provide real type safety, for example, you can easily put Strings in List (that's why Collections.checkedCollection kludge was added).

In C# (or C++), on the other hand, parameterizing a generic type creates a _new_ _type_ which guarantees type safety and allows some quite interesting tricks. For example, in C# generics can be parametrized by primitive types and structs (which don't exist in Java, anyway) so you can have List without overhead of boxing. That's impossible in Java.

Re:Java 'generics' are not real generics

[Cyberax]

Sorry, Slashdot ate "<" and ">".

"you can easily put Strings in List" should be "you can easily put Strings in List<Integer>".

"so you can have List without overhead of boxing" should be "so you can have List<Integer> without overhead of boxing"

Re:Java 'generics' are not real generics

[CastrTroy]

Am I the only one who tries to do away with arrays whenever possible? Sure I use them in some cases, but their limited ability to resize is something I find to be a real issue. With Lists and Generics, I find I'm using Arrays less and less, even in cases where an Array would probably work, just because lists offer so much more functionality.

Re:Java 'generics' are not real generics

[KillerCow]

you can easily put Strings in List<Integer>

Really? I would like to see the code which does this without generating a warning.

Re:Java 'generics' are not real generics

[Jeffrey Baker]

Sure, Java generics work at compile time instead of runtime. At runtime, you can do whatever you want. But it's still true that Java generics provide a much safer interface which prevents a wide field of bugs, and which makes code much more readable. I think it's obvious that

l = new List();
l.add(foo);
Foo foo = l.get(0);

is much safer and easier to read than

v = new Vector();
v.add(foo);
Foo foo = (Foo) v.get(0);

especially when you consider that the obvious mistake

v = new Vector();
v.add(bar);
Foo foo = (Foo) v.get(0);

throws a cast exception at runtime.

I've read a lot of complaints that type erasure (the means by which Java generics are implemented) doesn't solve the whole problem. But there was a certain class of program that generics solved, and it has made development in Java much more productive and safe.

Re:Java 'generics' are not real generics

[Cyberax]

Yes, I absolutely hate to maintain old pre-1.5 code because generics make it so much easier to use.

But the problem is that generics could be implemented in a much better way, C# proves that.

Re:Java 'generics' are not real generics

[twbecker]

Sure, you can put Strings in an Integer collection, but you'll get a warning at compile time about using a raw type. The alternative, is to create a new type, lose all your backwards compatibility, and force folks to upgrade their entire codebase when moving to Java 5. Personally, I think what was done was a reasonable compromise.

Re:Java 'generics' are not real generics

[jfengel]

This code generates no warning for me (I'm using Eclipse rather than the JDK, so YMMV):

List s = new ArrayList();
List l = s;
l.add("foo");

Further, if you do:

Integer i = s.get(0);

you get a runtime class cast exception.

Re:Java 'generics' are not real generics

[roscivs]

Java generics don't provide real type safety, for example, you can easily put Strings in List (that's why Collections.checkedCollection kludge was added).

I've never understood this objection. This will always generate a compiler warning, and depending on your compiler settings may not even compile successfully. The only time you might turn those warnings off is when you're having to deal with non-genericized legacy code.

Re:Java 'generics' are not real generics

[rtssmkn]

The part about auto-boxing is generally not true, especially when it comes to low-level generic interface method invocation.

See http://msdn.microsoft.com/msdnmag/issues/1200/dotn et/ for a short instruction on how primitive types directly map to
objects in the language, the very same concepts of auto-boxing and unboxing take place as they are implemented in the Java
language.

Re:Java 'generics' are not real generics

[Cyberax]

void doSomething(List lst)
{
      lst.add("Hello, world!");
}

List<Integer> intList=new ArrayList<Integer>();
doSomething(intList);

assert(intList.get(0) instanceof Integer); //Oops!

Re:Java 'generics' are not real generics

[Sneftel]

What jfengel meant to say was:

List s = new ArrayList<Integer>();
List l = s;
l.add("foo");

Re:Java 'generics' are not real generics

[Cyberax]

Please, read about generics in C# and value type usage in generic code. You can create generic collections of value types without overhead of boxing.

For example, here: http://www.artima.com/intv/generics2.html

Re:Java 'generics' are not real generics

[jfengel]

Argh. Thank you. It's not very interesting without the generics.

I'd also meant to add the generic to the definition of s, so that it should be:

List<Integer> s = new ArrayList<Integer>();

So when you pull the element out:

Integer i = s.get(0);

it can be done without an explicit cast. But the cast occurs anyway and generates a ClassCastException if you've put a non-Integer into the array. That's far later than it ought to be; the error occurred long ago and far away, so debugging it can be a real pain.

Re:Java 'generics' are not real generics

[edishere]

Ummm.... you are just using autoboxing here, not generics.
You should try:
List s = new ArrayList();

then you CAN do:
List l = s; .... but I don't know why you ever would, and if you decided to do that you could THEN do:

l.add("wow");

and you get errors. Sure, if you use goto's wrong you can get errors, if you use unsafe regions in C# incorrectly you can get errors, but then again, you are not using the language as intended.

if you did:
List s = new ArrayList(); ... and then:
s.add("wow");

you get what you would expect, a compilation error.

Re:Java 'generics' are not real generics

[harves]

What compiler are you using??

harvey@clownfish:~$ cat test.java
import java.util.*;

public class test
{
      public test()
          {
                List s = new ArrayList<Integer>();
                List l = s;
                l.add("foo");
          }
}
harvey@clownfish:~$ javac test.java
Note: test.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
harvey@clownfish:~$ javac -Xlint:unchecked test.java
test.java:9: warning: [unchecked] unchecked call to add(E) as a member of the raw type java.util.List
                l.add("foo");
                          ^
1 warning

Re:Java 'generics' are not real generics

[Anonymous Coward]

Bah. Next you're going to be telling me Lisp had this 20 years ago, except with a native compiler, and that even C#/C++ generics are somehow worse because they don't have multiple-dispatch.

Re:Java 'generics' are not real generics

[jfengel]

If you reread your post as posted, you'll see you made the same mistake I did: Slashdot took the angle-brackets and treats them as HTML tags rather than as Java code. I was in fact using generics, but they disappeared in the Slashdot posting process. The same thing happened to your post.

If you put back the generics in both your post and mine, as somebody corrected for me in a sub-post, I think you and I are talking about the same thing.

I don't know why somebody would cast a List<Integer> to a plain List, but it's legal, and that's a problem that other parameterized languages don't have. But doing it that way preserved a lot of other nice features of the Java Virtual Machine, and with the right warnings turned on the compiler can spot it as a probable error, so I'm not really complaining. I'm just concurring with an ancestor-post that Java's generics don't truly introduce new types but are instead merely a compile-time hack.

Re:Java 'generics' are not real generics

[Anonymous Coward]

I don't know why somebody would cast a List to a plain List, but it's legal,

You get a warning if you do it, which is about as much as you need.

Re:Java 'generics' are not real generics

[Radres]

If you care about memory usage and/or performance, you will try to replace dynamic memory structures like Lists and generics with the much more efficient array where possible. Make sure you understand your app's design and requirements before you go around creating dynamic memory structures everywhere. Memory and performance may not seem like a big concern now, but there will come a time when it becomes important and you will kick yourself for not having learned how to manage it properly.

Re:Java 'generics' are not real generics

[Anonymous Coward]

I agree with you on the autocasting remark. IMHO Java generics are a very crippled form of parametric polymorphism. The design prevents any kind of interesting development. For example, let's create a simple fold function that folds over a collection.

(1) We define an interface for "functions" of two arguments:

public interface Functor2<R, T1, T2> {
        R apply(T1 value1, T2 value2);
}

(2) The actual fold function:

public static <R, T> R fold(Collection<T> coll, R init, Functor2<R, R, T> func) {
        R result = init;
        for (T value : coll) {
                result = func.apply(result, value);
        }
        return result;
}

So far so good. Now suppose we want to define a function sum in terms of fold that sums all elements of a collection. Problem is that our type parameter needs to support the addition operation and there is no interface to enforce this. Java does not use structural typing like C++ templates. What we would want to write is:

public static <T extends Num<T>> T sum(Collection<T> coll, T init) {
        return fold(coll, init, new Functor2<T, T, T>() {
                public T apply(T value1, T value2) {
                        return value1.plus(value2);
                }
        });
}

But a Num<T> interface doesn't exist and if we define it like this

public interface Num<T> {
        T plus(T that); ...
}

existing classes can not be declared implementations of this interfaces (a language like Haskell allows such "retroactive modelling"). So all our Integer, Double, etc. types can not be used. Another bad thing is that sum needs to have a parameter init because it can not create a variable of type T itself thanks to type erasure.
Without support for retroactive modelling or structural typing and with type erasure I think Java generics can hardly be considered as real parametric polymorphism because the writing of generic algorithms is impossible.

Re:Java 'generics' are not real generics

[0xABADC0DA]

What you are missing is that it's a *good* thing that Java generics are not "real" generics.

With "real" generics the system has two choices: either generate lots of bloated specific instances of the code, or add type-checking at runtime. CLR designers thought they were going to do the former and it was going to be 'uber leet' and fast, but found out it's not practical (most of the optimizations that C++ uses to limit bloat do not apply well in a dynamic language) so they got stuck with the latter, for objects.

In Java, the code goes to add something to a generic list for example and it does one cast to the generic parameter type. Many times it can completely remove this check since it already knows from flow that the type is compatible. CLR can do this too, but only if it *also* knows the specific instance of the list (what the generic parameter types are), so it can remove fewer checks. This makes optimization harder as well since each use of a generic parameter can potentially block inlining and/or hoisting.

On top of that, the tests CLR has to do are *much* slower since they have to check many parallel type hierarchies (one per generic type references). For example, when passing a LinkedList of Integers to a parameter of type List of Numbers CLR has to in effect check both List assignable from LinkedList and Number assignable from Integer.

So in the vast majority of code not only do you end up with more checks but slower ones, and CLR has to maintain a complicated hierarchy of instantiated types to optimize this. All so primitives can be used faster in some cases, which is pretty ironic since in my experience these cases are usually easy to optimize by hand to use an array or patch out to inline C++ or JNI'd code.

In other words they messed up their runtime for bullet points without considering the implications. Not even to mention that in Java if you don't like generics, you just don't use them.

Re:Java 'generics' are not real generics

[Anonymous Coward]

Here you go dork boy, compile this:

import java.util.*;

public class Test {

        static void doSomething(List<Integer> lst)
        {
            lst.add("Hello, world!");
        }

        public static void main( String[] args ) {
                List<Integer> intList=new ArrayList<Integer>();
                doSomething(intList);
                assert(intList.get(0) instanceof Integer); //Oops!
        }
}

Re:Java 'generics' are not real generics

[Anonymous Coward]

If you don't want to update your codebase to take advantage of new features in Java 5, why bother moving to it? It's not as if your legacy code magically becomes generic just because you recompiled.

Re:Java 'generics' are not real generics

[nuzak]

> Note: test.java uses unchecked or unsafe operations.

Anyone who uses JPA/Hibernate queries, or works with generics much at all sees this warning come up everywhere, and thus tends to disable the warning in those places. This is fine as long as you pay attention to the warning elsewhere, but since it won't prevent the code from compiling, you can and probably still accidentally deploy something broken anyway.

Generics in C# don't let you use the backward API at all. C++ doesn't even understand the idea of not instantiating the template. Java forces you to use the old API, because even if you do use the generics syntax, it's merely syntax sugar for runtime casting from Object. It's better than nothing, but not by much.

The code runs, and it crashes. A warning is not an acceptable solution.

Re:Java 'generics' are not real generics

[thammoud]

The .NET library contain two collection classes. One generic and the other non-generic.

System.Collections.Generic.List l = new System.Collections.Generic.List();
System.Collections.ArrayList l = new System.Collections.ArrayList();

Doesn't sound very elegant. At least in Java you have only one set.

Re:Java 'generics' are not real generics

[Ana10g]

And furthermore, one thing that I find that makes C#'s generics completely useless is that the language prevents you from using the "genericized" collection without its generic type tags. For instance:

public class Foo<T>
{

}

public class Bar : Foo<int>
{

}

public class Bas
{
public void add(Foo pArg)
{

}
}

Note that the above code will not compile, as you are not allowed to make a reference to Foo without its generic type. In other words, To use Foo, I then have to make Bas typed, and anything that internally uses Bas must then be typed, etc. In my opinion, outside of the collections, C#'s generics are completely useless (this reason is why they split IList and IList<T> into two separate namespaces, and why you cannot use the two interchangably).

Java's generics allows the above operation, but still preserves the underlying type safety.

Re: Java 'generics' are not real generics

[gidds]

Agreed. While generics are very powerful and make for nice, clear, safe code, they only do so for simple examples. When you get to more complicated uses, it all starts to get very painful.

And that's because, as you say, it's a kludge.

Why oh why oh why oh why oh why didn't they put it into the runtime? That would have given a huge amount more safety, and probably efficiency. The main excuse I heard was that they didn't want to change the JVM or the bytecode -- but then they went and changed both in the same release (to add annotations) anyway!

So now we have something that can look neat in the code but isn't any more than syntactic sugar -- it's dead easy to subvert and end up with something completely unexpected in a collection, or passed as a parameter to a generic method. In practice, it's still executing all the same casts, so it's unlikely to be any more efficient than the old way -- which is what it pretty much boils down to once it gets to the runtime anyway.

And it has stupid limitations. For example, although a you can write a class that's comparable to Integers (by implementing Comparable) or one that's comparable to Strings (by implementing Comparable), you can't write one that's comparable to both! (The reason is that the compiler translates both to Comparable, and you can't provide two different implementations for the same interface.) Stupid stupid stupid. In your generic class, although you can define members and accept method arguments that appear to be of the parameterised type, you can't create an array of that type, nor create a new instance; you can't even use reflection to find out what that parameterised type is. In fact anything mixing arrays and generics is a world of pain, and there are many other hidden gotchas. Not to mention that you have to make it all defeatable to support existing non-generic code...

So while type erasure initially sounds like a nice way to implement generics (it has almost no overhead at runtime, is backward-compatible, and simple examples work well), I think it was the wrong decision. Java used to be a relatively simple language, with all the complexity hidden away in the runtime. Now it's the other way around; there's a huge amount of complexity foisted onto the compiler, and hence the programmer, simply to maintain this pretence to the runtime. And we all suffer for it.

Re:Java 'generics' are not real generics

[novitk]

+5?

CLR can do this too, but only if it *also* knows the specific instance of the list (what the generic parameter types are), so it can remove fewer checks. This makes optimization harder as well since each use of a generic parameter can potentially block inlining and/or hoisting.

There is no "only if" here, as you seem to imply. If a generic is compatible with passed parameters the CLR would remove the check in JIT in all cases just like JVM. CLR is also capable of removing the check on upcast calls (i.e. list.get()) as .NET generics are truly type-safe. Java has no ability to do this.

On top of that, the tests CLR has to do are *much* slower since they have to check many parallel type hierarchies (one per generic type references). For example, when passing a LinkedList of Integers to a parameter of type List of Numbers CLR has to in effect check both List assignable from LinkedList and Number assignable from Integer.

I'm not sure I understand. Implementing IEnumerable in generics doesn't imply any "parallel type hierarchies". Are you sure you are not confusing C++ templates and CLR generics?

So in the vast majority of code not only do you end up with more checks but slower ones, and CLR has to maintain a complicated hierarchy of instantiated types to optimize this.

Are you talking about the speed of JIT phase? This is O(1) step, who the hell cares. In run-time performance the CLR generics are a lot better than JVM ones even on reference-based collections (due to beforementioned upcast elimination). On value-based ones it's an order of magnitude difference.

All so primitives can be used faster in some cases, which is pretty ironic since in my experience these cases are usually easy to optimize by hand to use an array or patch out to inline C++ or JNI'd code.

This is only because Java is limited in a number of available primitives. CLR has a built-in support for extensible value-based types, so supporting them in generics without boxing is quite useful.

Re:Java 'generics' are not real generics

[Pseudonym]

With "real" generics the system has two choices: either generate lots of bloated specific instances of the code, or add type-checking at runtime.

There's a third choice: Design the language from the ground-up with generics in mind, and don't try hacking it on later to a model where it doesn't work properly.

Re:Java 'generics' are not real generics

[Anonymous Coward]

Doesn't seem to jive with what was said here: http://www.artima.com/intv/generics2.html

I think I'll take the CLR creator's word over the word of one of Java's self-proclaimed Bad Coder's. Probably the biggest point from the article is this one:

"Now, what we then do is for all type instantiations that are value types--such as List<int>, List<long>, List<double>, List<float>--we create a unique copy of the executable native code. So List gets its own code. List<long> gets its own code. List<float> gets its own code. For all reference types we share the code, because they are representationally identical. It's just pointers."

Seems to me that Java is using a glorified macro system that, instead of making casts unnecessary, just hides them from you.

Re:Java 'generics' are not real generics

[STFS]

Yeah... but this is exactly what allows the Java generics to be backwards compatible. You win some, you loose some.

IMO the worst thing about the Java generics though is that you can't create a generic exception class. That really blows!

Re:Java 'generics' are not real generics

[Taagehornet]

What you are missing is that it's a *good* thing that Java generics are not "real" generics.

It appears that you're confusing CLI generics and C++ templates. I must admit that I have little knowledge of C++ templates, but a comparison of Java's Generics by Type Erasure and C#/CLI's true generics definitely favours the latter.

The following set of slides by Peter Sestoft sums up the differences pretty well: http://www.itu.dk/courses/PFOO/F2006/diku-javacsha rpgenerics.pdf

Slide no. 23 sums up the major advantages of the C#/CLI implementation:

In C#, a type parameter can be used almost as an ordinary type:

class C<T> {
void M(Object o) {
T[] arr = new T[10]; // Array creation
if (o is T) { // Instance-of test
T t = (T)o; // Type cast
...
}
T d = default(T): // Get default value for T
Type ty = typeof(T); // Get type object (reflection)
}
void MO(T x) { ... } // Overloading on type parameters
void MO(IMyList<T> x) { ... } // and type instances
}

Java simply does not allow this (slide no. 32):

[...] in Java, a generic type parameter in many respect cannot be used as an ordinary type:

class C<T> {
void m(object o) {
T[] arr = new T[10]; // Declaration OK, array creation not
if (o instanceof T) { // No instance-of test
T t = (T)o; // Type casts are "unchecked"
...
}
Class ty = T.class; // No getting the type object
}
void mo(T x) { ... } // No overloading on type parameters
void mo(MyList<T> x) { ... } // and type instances
}

Then of course there's the fact that C# type arguments can be value types, not only reference types. No boxing or unboxing is needed for value type arguments; hence better performance and less memory usage.

Re:Java 'generics' are not real generics

[wasabii]

Which honestly, in a way, is what MS did. They broke backwards compatibility to accomplish it. New code compiled with generic C# will not run on old VMs.

Re:Java 'generics' are not real generics

[Anonymous Coward]

> With "real" generics the system has two choices: either generate lots of bloated specific instances of the
> code, or add type-checking at runtime.

Apparently, you do not know enough C++ to notice a 3rd choice: predeclare specific template instances to avoid bloat. RTTI or custom type checking is never required.

Re:Java 'generics' are not real generics

[jhol13]

You can do the same in C++, trivially.

Besides, it does give warnings:
Note: kkk.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

Re:Java 'generics' are not real generics

[ArwynH]

arwyn@painaich:~$ javac tmp/t1.java
Note: tmp/t1.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
arwyn@painaich:~$ javac tmp/t1.java -Xlint:unchecked
tmp/t1.java:6: warning: [unchecked] unchecked call to add(E) as a member of the raw type java.util.List
lst.add("Hello, world!");
^
1 warning

You were saying?

Re:Java 'generics' are not real generics

[jhol13]

it has made development in Java much more productive and safe. Has it really?

To be honest, I do not know. It certainly makes programming harder and slower.
And some people (who advocate dynamic languages like Python) claim that unit tests are "better" at catching errors than static analysis.

"Better" to be understood in business sense, i.e. minimize "errors left * price used to find them", etc.

Re:Java 'generics' are not real generics

[Anonymous Coward]

If I pass a List to a method taking a List when it puts a Float in it there has to be a check of some kind to stop this, because each stage is correct. Java can remove this check in more cases than CLR. C++ does not check because it is actually different code that executes (ie bloat).

CLR is also capable of removing the check on upcast calls (i.e. list.get()) as .NET generics are truly type-safe. Java has no ability to do this. If you pay attention to what Anders says for instance in interviews you find that .NET objects don't have a cast on get because each type has its own vtable. Practically speaking what this boils down to is that there is no inlining across method calls from objects you get from a collection (for instance). With Java you get a cast, in general taking about 2-3 instructions, and an inlined method call. In CLR you avoid the cast but essentially guarantee no inlined call. I think even you can correctly guess which of those is better. In fact I refer you to this interview:

http://www.artima.com/intv/choices.html

For shame, Anders. If you don't believe me about these performance problems how do you explain Anders' backpedaling in that interview? It's clear that at that point he didn't even understand the fact that JVMs are actually inlining the code not 'jumping straight there'.

I'm not sure I understand. Implementing IEnumerable in generics doesn't imply any "parallel type hierarchies". Are you sure you are not confusing C++ templates and CLR generics? Obviously you do not understand. ArrayList is a type, instantiated at runtime in C# (and incidentally never collected until the entire classloader is collected). It is a subtype of both List and ArrayList. Parallel hierarchies... get it?

Are you talking about the speed of JIT phase? This is O(1) step, who the hell cares. In run-time performance the CLR generics are a lot better than JVM ones even on reference-based collections O(1) step for .NET means the code has to be JIT'd, poorly, just to run. This is a direct consequence of their support in the bytecode for generics and more to the point the support for value types. In Java your O(1) means 0 because the bytecode can be effectively interpreted. Design choices have impacts that are not always clear up front, but Sun having decades of experience made far fewer.

There's a reason why Microsoft threatens to sue people over unauthorized CLR benchmarks; that reason is that it is slow. Do you wonder why instantiated generic types are never collected and float around until the application exits? It's because to rebuild their optimized type comparison trees (so instanceof is not ridiculously slow ie anywhere from dozens to hundreds of cycles) they would have to remark all objects in the system, but worse would have to recompile a lot of code.

CLR has a built-in support for extensible value-based types, so supporting them in generics without boxing is quite useful. yes it is quite useful in CLR... it helps even out the negative performance impact throughout the entire system that are direct consequences of those same choices.

Re:Java 'generics' are not real generics

[TummyX]

With "real" generics the system has two choices: either generate lots of bloated specific instances of the code, or add type-checking at runtime. CLR designers thought they were going to do the former and it was going to be 'uber leet' and fast, but found out it's not practical (most of the optimizations that C++ uses to limit bloat do not apply well in a dynamic language) so they got stuck with the latter, for objects.


You don't know what you're talking about. Code takes only a fraction of the memory an application uses. The CLR does NOT generate different specific instances of code for reference types. It only generates different sets of code for each specialization that is based on a valuetype (because the layout of valuetypes are different between different types as opposed to a 4 byte reference for reference types).


On top of that, the tests CLR has to do are *much* slower since they have to check many parallel type hierarchies (one per generic type references). For example, when passing a LinkedList of Integers to a parameter of type List of Numbers CLR has to in effect check both List assignable from LinkedList and Number assignable from Integer.


Admit it. You just completely made that up.

Firstly, C# currently does not support covariance. You cannot treat a LinkedList of Integers as a LinkedList of Numbers (they are two incompatable types) -- if you could, then the method could add a Number to a list of Integers which would be wrong. Java uses wildcards to let the compiler allow you to do this when you need to. Microsoft have a much more advanced mechanism planned for a future release of C#.

Secondly, the check to make sure an argument is compatible with the method call is performed statically *ONCE* when the code prepared for JIT by a code verifier. Both Java bytecode and IL are designed to be statically verified. You can't seriously think that the argument types are validated with each method call do you?


So in the vast majority of code not only do you end up with more checks but slower ones, and CLR has to maintain a complicated hierarchy of instantiated types to optimize this. All so primitives can be used faster in some cases, which is pretty ironic since in my experience these cases are usually easy to optimize by hand to use an array or patch out to inline C++ or JNI'd code.


Total hogwash. That's like saying Java's anonymous inner classes slow down java because of all the extra classes they generate. Despite what lef others to believe, The JVM is not capable of removing all the necessary cast checks and you totally ignore the issue of GC and heap overloading when needing to unecessarily box collections of primitive types.

Microsoft and Sun went totally different directions when implementing generics. Sun chose backwards compatibility (understandable considering the age and wide adoptance of the langauge at the time) whilst Microsoft had more oppurtunity make adopt a slightly better design. Both are good and have their advantages and disadvantages. I personally like Microsoft's implementation mostly because specialized generic types in C# are individual types in their on right and you can see this when you perform reflection or dynamic runtime operations upon them (typeof(List{string}) != typeof(List{object}) shows that they are seperate unique classes rather than all based on the same type/class.

I'm dismayed that you got modded to 5 considering how totally uninformed and made up your post was. None of your points are even close to the truth.

Re:Java 'generics' are not real generics

[Anonymous Coward]

/. ate the punctuation:

If I pass a List<Integer> to a method taking a List<Number> when it puts a Float in it there has to be a check of some kind to stop this, because each stage is correct. Java can remove this check in more cases than CLR. C++ does not check because it is actually different code that executes (ie bloat).

and:

Obviously you do not understand. ArrayList<Integer> is a type, instantiated at runtime in C# (and incidentally never collected until the entire classloader is collected). It is a subtype of both List<Integer> and ArrayList<Number>. Parallel hierarchies... get it?

Re:Java 'generics' are not real generics

[Vintermann]

Wrong, wrong, wrong. As long as you use the appropriate dynamic data structures (i.e, don't iterate over a hashmap or implement sets with linked lists), it's very unlikely that you should come to regret not using static ones.

Re:Java 'generics' are not real generics

[LizardKing]

Riiigght. So broken code generates warnings, the programmer elects to ignore those warnings and then wonders why things break. This is just the same as people compiling their C or C++ code using gcc, and electing to ignore warnings from -Wall.

Re:Java 'generics' are not real generics

[0xABADC0DA]

Firstly, C# currently does not support covariance. You cannot treat a LinkedList of Integers as a LinkedList of Numbers (they are two incompatable types) -- if you could, then the method could add a Number to a list of Integers which would be wrong So in other words C# doesn't have real generic types *and* it has broken inheritance? For instance you can't refine a method taking Map<Number> in a subclass to be one taking Map<Integer>, where Integer inherits from Number? That sounds pretty broken to me, and judging by the message boards I'm not alone.

And no, you couldn't add something besides an integer to a list of integers after casting to a list of numbers because that's why type enforcement is for. Duh.

typeof(List{string}) != typeof(List{object} You call this generics when that holds but "List{string} instanceof List{object}" is false? C# generics are bullet points.

You don't know what you're talking about. ... Admit it. You just completely made that up. ... Total hogwash. ...considering how totally uninformed and made up your post was. Note that I was talking about CLR not C#, so it it you who are confused. CLR supports covariant and contravariant generic types, see Eiffel CLR for instance. Are you trying to say that it uses different optimizations when the code doesn't use these? That's fair, if true. CLR must be a seriously complicated machine to be able to support all of these uses in the same program. It's no wonder then that it isn't doing the advanced optimizations (CLR often can't even inline one method let alone several deep like a JVM does... see Eric's blog posts on this subject).

Re:Java 'generics' are not real generics

[Anonymous Coward]

Doesn't seem to jive with what was said here Learn to read. That's exactly what I said, it shares the code ", for objects". As opposed to value types. FYI it's "jibe" not "jive".

I think I'll take the CLR creator's word over the word of one of Java's self-proclaimed Bad Coder's. Illiterate and a potty mouth. No wonder you post AC.

Seems to me that Java is using a glorified macro system that, instead of making casts unnecessary, just hides them from you. Yes that's essentially correct, although the system also does all the same checks at compile time that is done for C#. It's also faster, simpler, and more flexible, which is what programmers want.

Re:Java 'generics' are not real generics

[godefroi]

How exactly do you plan on passing a List to a method taking a List?

Re:Java 'generics' are not real generics

[nuzak]

> So broken code generates warnings, the programmer elects to ignore those warnings and then wonders why things break.

Standard usage is flagged as "broken code", and it's unavoidable. This is a situation that does not occur with C++. Blaming the user for the type system's failings is completely unacceptable.

Re:Java 'generics' are not real generics

[TummyX]

So in other words C# doesn't have real generic types *and* it has broken inheritance? For instance you can't refine a method taking Map in a subclass to be one taking Map, where Integer inherits from Number? That sounds pretty broken to me, and judging by the message boards I'm not alone.


No, in other words you know nothing about generics. If that was supported, unless you had language features defining which methods are read only, you would end up adding Integers into a map of Numbers. The next version of C# will improve upon the current generics by supporting co and contravariance.


You call this generics when that holds but "List{string} instanceof List{object}" is false? C# generics are bullet points.


Well duh. Again, if List{string] was a List{object} then I could cast List{string} into List{object} and insert any object into a list of strings. Not the point of generic collections is it?


Note that I was talking about CLR not C#, so it it you who are confused. CLR supports covariant and contravariant generic types, see Eiffel CLR for instance. Are you trying to say that it uses different optimizations when the code doesn't use these? That's fair, if true. CLR must be a seriously complicated machine to be able to support all of these uses in the same program. It's no wonder then that it isn't doing the advanced optimizations (CLR often can't even inline one method let alone several deep like a JVM does... see Eric's blog posts on this subject).


You are full of it. Regardless of whether you were talking about the CLR or not, The CLR does not support covariant and constravariant generic types, the other languages perform hacks in the same way that Eiffel for .NET hacks on multiple inheritance support.

You still haven't explained your paragraph where you stated that calls with CLR generics are slower because the CLR has to "check" that the type is compatible despite the fact that these checks are performed when a method is call and despite the fact that the checks are unnecessary because the CLR has NO support for covariance or contravariance.

You seem to only have a passing understanding of generics and the CLR.

Re:Java 'generics' are not real generics

[TummyX]

You still haven't explained your paragraph where you stated that calls with CLR generics are slower because the CLR has to "check" that the type is compatible despite the fact that these checks are performed when a method is call and despite the fact that the checks are unnecessary because the CLR has NO support for covariance or contravariance.

Should have read:

You still haven't explained your paragraph where you stated that calls with CLR generics are slower because the CLR has to "check" that the type is compatible despite the fact that these checks are NOT performed when a method is called and despite the fact that the checks (if they were even required which they never are) are unnecessary because the CLR has NO support for covariance or contravariance.

Re:Java 'generics' are not real generics

[Anonymous Coward]

If that was supported, unless you had language features defining which methods are read only, you would end up adding Integers into a map of Numbers. No, it would be a runtime error like casting a String to Object then to Integer. Wow, you are really obtuse.

The next version of C# will improve upon the current generics by supporting co and contravariance. I was talking about CLR not C#. I realize that you went off all half-cocked because what I wrote angered you somehow. Maybe you work for Microsoft and take pride in your 'work'. But come on, at least read the post you are replying to.

It really amazes me that Microsoft can copy something already largely done, Java, and hopelessly screw up the their own implementation so it is very difficult to make fast and at the same time screw over their customers with a very narrow, rigid, confining generics system. Come back when C# gets wildcard types for instance; the guy who got them into Java, now stolen away and working for MS, has pretty much admitted it's impossible with the CLR's messed up type system. It's sad really, it's like Microsoft has some kind of corporate policy to saddle us with 3rd-rate crap.

You've got a lot to learn, son.

Re:Java 'generics' are not real generics

[TummyX]

No, it would be a runtime error like casting a String to Object then to Integer. Wow, you are really obtuse.


A runtime error? What's the point of java generics except to save on typing casts?


It really amazes me that Microsoft can copy something already largely done, Java, and hopelessly screw up the their own implementation so it is very difficult to make fast and at the same time screw over their customers with a very narrow, rigid, confining generics system. Come back when C# gets wildcard types for instance; the guy who got them into Java, now stolen away and working for MS, has pretty much admitted it's impossible with the CLR's messed up type system. It's sad really, it's like Microsoft has some kind of corporate policy to saddle us with 3rd-rate crap.


You have to be kidding. Java's generics implementation has limited them totally. Tell me why List{String}.class == List{Dog}.class. Do you consider that a good type system?

You do NOT want wildcards for generics because wildcards are a big ugly hack and hacking them onto the C# would be a piece of piss (there would be no need to hack the CLR cause it's just compiler magic).

Please reply with a link to the guy who said that wildcards couldn't be hacked onto C#.

For a property unhacked solution to wildcards, please read this and learn something: http://research.microsoft.com/research/pubs/view.a spx?type=inproceedings&id=1215

Re:Java 'generics' are not real generics

[Anonymous Coward]

A runtime error? What's the point of java generics except to save on typing casts? Yes a runtime error. The point of generics is to save typing casts and to detect type errors at compile time, and Java and C# do this.

You have to be kidding. Java's generics implementation has limited them totally. Tell me why List{String}.class == List{Dog}.class. Do you consider that a good type system? Yes this is a good type system, because there is only one List class and it is generic, so of course a list will compare as itself. When you create a new List<String> you aren't creating a new class you are constraining the type (a class is not a type).

For a property unhacked solution to wildcards, please read this iow, changing C# to let programmers use the covariance and contravariance in generic types already supported by CLR, because the current state of C# where List<String> !instanceof List<Object> is too restrictive? Congratulations you just proved my point that C# generics are a 'very narrow, rigid, confining'. Generics should help the programmer, not create more obstructions and busy-work as they do in C#.

CLR can't even inline methods over 32 instructions even in the tightest loop because of their mistakes (ie incapable of interpretation) whereas if it will be faster Java can inline methods 5+ calls deep into blocks of 10k or more code because it can. And the 'fix' is to make CLR even more complicated to optimize? Good luck with that one, Microsoft.

Re:Java 'generics' are not real generics

[TummyX]

Yes a runtime error. The point of generics is to save typing casts and to detect type errors at compile time, and Java and C# do this.


You seriously need to study what generics are. It is NOT for saving typing of casts.


Yes this is a good type system, because there is only one List class and it is generic, so of course a list will compare as itself. When you create a new List you aren't creating a new class you are constraining the type (a class is not a type).


Oh really? That's like saying there is only one class (Object) and java.lang.String is just an extension of that class. Almost every other language defines them as different types because they are. Java's type erasure hack for generics seems to have generated a lot of programmers who think that generics is to "save on writing casts". Ick.


Generics should help the programmer, not create more obstructions and busy-work as they do in C#.


It does, whilst still maintaining langauge correctness.


iow, changing C# to let programmers use the covariance and contravariance in generic types already supported by CLR, because the current state of C# where List !instanceof List is too restrictive? Congratulations you just proved my point that C# generics are a 'very narrow, rigid, confining'. Generics should help the programmer, not create more obstructions and busy-work as they do in C#.


It's restrictive in the sense that you can't cast Object into a String and expect it to work. Seriously. What is your background on programming languages?


CLR can't even inline methods over 32 instructions even in the tightest loop because of their mistakes (ie incapable of interpretation) whereas if it will be faster Java can inline methods 5+ calls deep into blocks of 10k or more code because it can. And the 'fix' is to make CLR even more complicated to optimize? Good luck with that one, Microsoft.


Wrong again. IL has been designed for JIT compilation from the start but that doesn't mean that you can't interpret IL efficiently by using an intermediate byte-code like representation. That's what Portable.NET/DotGNU (the project I work on) does.

Anyway, what and when to inline is up to the JIT compiler. The JVM has NO advantage and infact has to work harder to inline and there are huge hacks because of the lack of user-defined-structs for things like Point(X,Y). The Java JIT is a marvel of engineering, the optimisations are amazing compared to the current generation of .NET JITs but .NET is catching up. I have no idead where you got the idea that the CLR can't inline methods over 32 instructions because it is incapable of interpretation. Interpretation has absolutely NOTHING to do with it. Do you actually understand what you're spouting or are you just pulling quotes out of your memory that you read on some guys blog?

Too bad Java generics are completely useless

[Anonymous Coward]

Amongst those changes (enumerations, auto-boxing, foreach, varargs) generics was the most far-reaching, introducing generic programming in a simpler, safer way than C++ templates and, unlike generics in C#, maintaining backwards (and forwards) compatibility with existing Java code.

Yeah, and by maintaining that backwards compatibility, they became totally worthless.

The only thing it offers is some compile-time sanity checking, but even that can be disabled through use of a new compiler pragma directive to suppress warnings. In fact, in several cases, you HAVE to disable warnings because certain operations (like creating an array of a generic type) are impossible without a warning.

Ever wondered why the collection classes require you to pass in an array to the toArray(T[]) method? Because Java generics throw away the class information after compile time (although there's no reason they need to do this, they could have kept it and maintained backwards compatibility), so you have to pass in an array to give the type information Java removed.

Java generics could have been useful, but since casting them into a non-generic type generates an ignorable warning, they become worthless. It's only a few lines of code to place a Double into an Integer collection, thereby removing then entire point completely.

Re:Too bad Java generics are completely useless

[LarsWestergren]

The only thing it offers is some compile-time sanity checking, but even that can be disabled through use of a new compiler pragma directive to suppress warnings.

Many operations are ERRORS, not warnings. This is caught by IDEs, and by the compiler.

In order to make it possible to interact with legacy code, you can pass a generified collection to a method that expects a "raw" collection. This gives you a very clear warning. So for 95% of all use cases, generics give you a lot of assistance. You manage to come up with a remaining 5% example, where a programmer casts, suppresses compiler warnings, and then passes in a object of the wrong type, and this makes generics worthless?

Wadler was involved with the design of Haskell, and he and people like Gilad Bracha designed Java generics. I trust their skills more than a Slashdot Anonymous Coward.

Re:Too bad Java generics are completely useless

[Anonymous Coward]

In order to make it possible to interact with legacy code, you can pass a generified collection to a method that expects a "raw" collection. This gives you a very clear warning.

No, it doesn't. You'd think it would, but it doesn't. The warning occurs on the method that ACCEPTS the "raw" collection, but NOT on the method call.

Try it:

import java.util.*;
 
public class FunWithGenerics {
 
  public static void main(String[] args) {
    ArrayList<String> l = new ArrayList<String>();
    someMethod(l);
  }
 
  public static void someMethod(List l) {
    l.add(new Integer(42));
  }
}

Now, try compiling it, and you get:

Note: FunWithGenerics.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

Note that by default, you get no line numbers, just a very generic warning. (Pun not intended.) So let's turn on lint checking, and then we get:

FunWithGenerics.java:14: warning: [unchecked] unchecked call to add(E) as a member of the raw type java.util.List
    l.add(new Integer(42));
        ^
1 warning

No warning when I call the method, the only warning is inside the method. So all it takes is that method being in a 3rd party library that I have no control over, and the warning just vanishes entirely.

Generics are great if you control every line of code, but as soon as you start using third-party libraries, they become worthless, since it's very easy to hide code that misuses generics in classes.

Especially because all it takes is @SuppressWarnings("unchecked") to completely remove the warning message - so unless you're looking in the code, you'd never notice it.

Re:Too bad Java generics are completely useless

[DavidYaw]

Ever wondered why the collection classes require you to pass in an array to the toArray(T[]) method? Because Java generics throw away the class information after compile time (although there's no reason they need to do this, they could have kept it and maintained backwards compatibility), so you have to pass in an array to give the type information Java removed.

A) Before generics were added, the toArray(T[]) function already existed as toArray(Object[]). Since this function pre-dates generics, the fact that it takes an array parameter, by definition, cannot have anything to do with generics.

B) For the interface Collection<E>, the function is defined as toArray(T[]), not toArray(E[]). The generic type T is defined locally for this function, and it does not have to be the same as type E.

I believe that in the quote, you are suggesting that this function should be implemented as taking no parameters and returning an array of the same type as the enumerated type. While I agree that this would be useful, it does not give as much functionality as toArray(T[]), and is not a suitable replacement.

Re:Too bad Java generics are completely useless

[VGPowerlord]

Well, we could be stuck with how it is with .NET... needing a separate runtime for each and every major version.

I personally would hate to have 7 different JREs, trying to figure out which one I need for which programs.

Re:Too bad Java generics are completely useless

[natet]

Ever wondered why the collection classes require you to pass in an array to the toArray(T[]) method? Because Java generics throw away the class information after compile time (although there's no reason they need to do this, they could have kept it and maintained backwards compatibility), so you have to pass in an array to give the type information Java removed.

I think you may be getting your facts wrong on this one. The toArray() methods precede Java Generics by at least a version. Those methods existed in Java 1.4.

As for the argument that compile time directives make it possible to ignore Generics, they're useless, I disagree with that sentiment. It would take probably exactly the same number of lines of code to not use Generics at all. Does that make them useless? No. Why would you use generics if you're going to then use directives to ignore them? This is a specious argument, because you make the assumption that because people can opt out generics, they will.

Re:Too bad Java generics are completely useless

[swillden]

In fact, in several cases, you HAVE to disable warnings because certain operations (like creating an array of a generic type) are impossible without a warning.

Which is just another reason to avoid using arrays.

Re:Too bad Java generics are completely useless

[pstemari]

Generics are OK for the user, but when it comes to authoring code, they're much more error-prone that the C++ implementations. You essentially lose all type checking as soon as you use an array for the internal implementation, and wind up back to C++ anti-bloat hackery of using generics as a typecast wrapper around a non-generic implementation based on void* aka Object. At least in C++ you have the choice of marching down the cast wrapper path vs. writing a truly type-safe implementation that the compiler can fully optimize. Face it--this is basically syntax-sugar for the novice user, and suffers from all the usual issues with runtime dynamic type-checking.

Re:Too bad Java generics are completely useless

[crazzeto]

Just out of curiosity, what is the overall performance impact of generics in Java? I'm a .Net developer, when Microsoft introduced Generics for .Net 2.0 there was a big too do about generics solving performance issues where programmers were relying on data structures such as the System.Collections.Hashtable (which stored data in a collection of objects, indexed by objects). Apparently with Microsofts implementation there is never any boxing, there for no performace loss. I've never seen any figures that show how this all adds up though.

Re:Too bad Java generics are completely useless

[Anonymous Coward]

A) Before generics were added, the toArray(T[]) function already existed as toArray(Object[]). Since this function pre-dates generics, the fact that it takes an array parameter, by definition, cannot have anything to do with generics.

Right - because in pretty much by definition, before generics were introduced, NO classes could have element type information stored with them. The method exists pre-generics because there was no way to specify member types. It should not exist post-generics as there now is, but that type information gets erased in the final binary. The toArray(T[]) method exists solely because there is no other way to create a typed array via a collection.

I believe that in the quote, you are suggesting that this function should be implemented as taking no parameters and returning an array of the same type as the enumerated type. While I agree that this would be useful, it does not give as much functionality as toArray(T[]), and is not a suitable replacement.

Given that toArray() exists and is almost completely worthless, yes, toArray() should behave exactly like that. toArray(T[]), on the other hand, should never have existed at all. It should have been toArray(Class) - toArray(T[]) gets the type information, granted, but in an almost completely brain-dead way. (Especially because it can cause two array allocations, which is just stupid. Or, worse, it can spring nulls on unsuspecting programmers if the collection shrinks.)

The only time in a system with actual working generics that you'd ever want to get an array that doesn't use the member type is when getting an array of a super-type. (Something like toArray(Number.class) on a List<Integer>.) Otherwise that feature is completely worthless.

Re:C# compatibility? duh...

[ncmusic]

I don't think there's any merit to that particular statement about backwards compatibility. Can you run you Java 5 code on a Java 2 VM? (They skipped 3, 4 and 5 right?) Generics were released with .Net 2.0. All the the .Net 1.1 code written runs on the 2.0 VM. There wasn't a whole mess of API changes that were obsoleted with the 2.0 it was ehancements to the API and bug fixes. What does forward compatibility even mean?

Re:C# compatibility? duh...

[e2d2]

Uhm, can someone explain to me how NEW features of a language can be backwards compatible?

Can I create generics in Java 1.1? If not then how exactly is their generics implementation backwards compatible? Call me crazy but I'm a bit skeptical. I just don't see how this can be done in ANY language. Just because you can run multiple versions of the runtime on the same machine doesn't mean that your new code is backwards compatible.

Re:C# compatibility? duh...

[heffrey]

Office 97/2000/XP/2003/2007, for example. I take it you've never used MS software.

Reading Generified Code Makes My Brain Hurt

[MCTFB]

I don't use any of the generic syntax at all in my code as I feel it makes it virtually unreadable to other developers. The syntax is just absolutely horrible, plus as most adept Java programmers know (been coding in Java myself since 1.0), the way generics is implemented in Java is broken (depending on your point of view on this matter).

Then there is the Collections API itself which upon first glance seems like it was written by amateurs who have never had to write any performance critical code in their lives. For this reason as well, I generally try and avoid using anything in java.util as well.

And now they are talking about adding closures (more bloat) to Java which as I understand the proposal will be implemented under the hood in basically the same way as inner classes (another feature that is a maintenance nightmare that gets abused by novice developers ad infinitum).

Is Java not bloated enough? Do the guys at SUN have such feature envy of C# (the bastard child of Java), that they can't just say enough is enough?

I feel like this is all coming full circle with C++ in the sense that Java now has so many language features that it is becoming too complicated for entry-level developers to be truly productive with and now a new language is needed that has the best features of Java, minus all the bloat that totally overwhelms the initiates.

With more features, generally comes more power, but with more power there is more room for abuse for those who don't have the wisdom to use it (i.e. newbies). Everyone in programming starts off as a newbie and needs to get their feet wet, but once you make a programming language where everyone has a light saber, but does not have the Jedi training or wisdom to use it, well then you are going to have a lot of people causing a whole lot of trouble.

One of the main reasons why Windows software development has slowed to a crawl (besides of course the cannibalizing nature of MS on the Windows platform), is that it takes a good 4 years or more of full-time experience with the Windows API's just to become adept at programming on that platform, on top of being decent at C/C++ itself. I know Microsoft has tried to reduce that learning curve with C# and .NET, but nevertheless the learning curve is still huge. With Java, the same thing is happening. What was once a simple, yet powerful programming language has evolved into a monster on par with the same kind of crap that comes out of Redmond that is overengineered and the last thing from elegant.

I guess it is time for a new application programming language.

Re:Reading Generified Code Makes My Brain Hurt

[Cyberax]

Bullshit.

Generics syntax is quite readable and easy-to-use, especially with good IDE support. And generics certainly make the code more readable because the add type information.

Foreach loops, varargs and autoboxing is just a minor syntax sugar, nothing really big.

I've used a lot of collection frameworks in a lot of languages (and even wrote my very own vector and string for C++), Java Collections Framework is quite OK. It's not hard and reasonably fast.

Re:Reading Generified Code Makes My Brain Hurt

[MCTFB]

an IDE should not be a requirement for any programming language just to write "Hello World".

Re:Reading Generified Code Makes My Brain Hurt

[Anonymous Coward]

Welcome your python overlords with open arms

Re:Reading Generified Code Makes My Brain Hurt

[Cyberax]

You can use generics without IDE. I do it all the time for small fixes when I don't want to setup a project in IDEA.

There's nothing complex in adding a type parameter in angular brackets.

Re:Reading Generified Code Makes My Brain Hurt

[Achoi77]

Then there is the Collections API itself which upon first glance seems like it was written by amateurs who have never had to write any performance critical code in their lives.

forgive me for being ignorant, but I haven't really found anything wrong with the Collections API. I found them to be pretty useful and saves a big of time from having to redo the wheel on each project I come across.

performance is a funny word. To some performance is depending on how much raw speed you can crank out of those transistors; to others it's simply looking at the Big O notation. I think Sun looks at the Big O and assumes the user will be responsible for taking care of the rest.

A slightly humorous quote I read on about an interview/talk someone had with the people from a online game (based on the hardware mention you can probably guess which one):

In the center they run a central database that they have pushed to the maximal edge by throwing Big Hardware at it (millitary spec TI RAM hard disks for instance.) Their only answer to future scaling was "well Moore's law has saved us so far..."

Not to be bashing the developers above as I am certainly in no position to talk, but if you truly are relying on trying to get bleeding edge performance by using optimizing techniques and throwing bigger hardware at it in order to catch up to the scaling necessary to maintain a certain qos, then perhaps it really is time to step back and really take a look at the overall scheme, even if it really means starting from scratch.

now, whatever that means from a business sense, it's a completely different matter...

Re:Reading Generified Code Makes My Brain Hurt

[marcosdumay]

Exactly. Since I've met Python I can't help not thinking it is the VB killer.

What creates a lot of problems for the language on my point of view, but I was never the target audience of any of those languages.

Re:Reading Generified Code Makes My Brain Hurt

[harry666t]

> I guess it is time for a new application programming language.

How about a mix of COBOL, brainfuck and swahili?

Re:Reading Generified Code Makes My Brain Hurt

[LarsWestergren]

Do the guys at SUN have such feature envy of C# (the bastard child of Java), that they can't just say enough is enough?

Sun does not control the development of Java, the Java Community Process does. And it is not C# that is seen as a threat I believe, but Ruby and functional languages. There is a VERY heated debate in the Java community over the new language features that are proposed for the Java platform, and both sides put up some very convincing arguments (simplicity is good vs a language needs to evolve, for instance). See for instance the different Closures proposals...

Re:Reading Generified Code Makes My Brain Hurt

[Anonymous Coward]

Agreed. It's not Java vs C# anymore. It's Java/C# vs Ruby/python.

For evidence, look at some of the features added in C# 3.0.

Re:Reading Generified Code Makes My Brain Hurt

[phasm42]

Who said anything about requiring an IDE? I write all my code in a text editor, and yes I use generics, the new for loop, enums, etc. Your point is valid by itself, but the implication that using generics in Java requires an IDE is just plain wrong.

Re:Reading Generified Code Makes My Brain Hurt

[MCTFB]

My point is that standard library API's that will be used by millions of developers should get a lot more attention in terms of their performance than some UI widget that is rarely used.

Every time you layer one thing on top of another, you generally get a performance hit. If the lower layers are poorly implemented, or rather they have not been given the sort of attention they need for their purpose, then building on top of them is like building a skyscraper on a foundation that is designed for a single story house.

Re:Reading Generified Code Makes My Brain Hurt

[Procyon101]

// Java's Readable syntax, using a fold function as an example

public interface Functor2 {
    R apply(T1 value1, T2 value2);
}

public static R fold(Collection coll, R init, Functor2 func) {
    R result = init;
    for (T value : coll) {
        result = func.apply(result, value);
      }
      return result;
} // Since the compiler already knows the types from context, // this is how it might be written with absolutely no loss of information.

public interface Functor2 {
    R apply(T1, T2);
}

public fold(coll, init, func) {
    result = init;
    for (value : coll) {
        result = func.apply(result, value);
    }
    return result;
} // This is a trivial example. More complex use of generics // make the readability difference more pronounced.

Re:Reading Generified Code Makes My Brain Hurt

[bckrispi]

Then there is the Collections API itself which upon first glance seems like it was written by amateurs who have never had to write any performance critical code in their lives. For this reason as well, I generally try and avoid using anything in java.util as well.

And you can justify to your boss spending weeks implementing your own collections framework to save a whopping 50 ms of processing per day? To say nothing of the ramp-up time required of the poor schmuck who has to maintain code that uses your wonderful non-standard libraries.

Seriously, I've been using the Collections framework since it was beta, and have never had a situation where its performance wasn't "good enough". Is it really "that bad" for your business need? Or are you committing the cardinal sin of premature optimization???

Re:Reading Generified Code Makes My Brain Hurt

[Anonymous Coward]

Good god, all that crap just to do a fold? Horrible. Just horrible.

Re:Reading Generified Code Makes My Brain Hurt

[Procyon101]

It's worse than that... it stripped out my pointy brackets...

// Working Java version
public interface Functor2<R, T1, T2> {
    R apply(T1 value1, T2 value2);
}

public static <R, T> R fold(Collection<T> coll, R init, Functor2<R, R, T> func) {
    R result = init;
    for (T value : coll) {
        result = func.apply(result, value);
    }
    return result;
}


And here is what Java SHOULD look like if it were readable:

// Not Real Java
public interface Functor2<R, T1, T2> {
    R apply(T1, T2);
}

public static fold(coll, init, func) {
    result = init;
    for (value : coll) {
        result = func.apply(result, value);
    }
    return result;
}


The second definition of fold doesn't seem so bad. Too bad it's not legal Java.

Re:Reading Generified Code Makes My Brain Hurt

[SporkLand]

See for instance the different Closures proposals... Meanwhile C# added closures to 2.0 and is borrowing / stealing great ideas from functional languages for 3.0. lambdas, lisp macro-like features (Expression Trees), type inference, extension methods.

I'm not a microsoft warrior, I rather like ruby, but the fact that the Java people are still arguing over closures makes me wonder if Java is already dead, rather than just dying.

Re:Reading Generified Code Makes My Brain Hurt

[Anonymous Coward]

I feel like this is all coming full circle with C++ in the sense that Java now has so many language features that it is becoming too complicated for entry-level developers to be truly productive with and now a new language is needed that has the best features of Java, minus all the bloat that totally overwhelms the initiates.

I agree. Hey, I know! They could call that language Modula-3!

Re:Reading Generified Code Makes My Brain Hurt

[Rick BigNail]

"Then there is the Collections API itself which upon first glance seems like it was written by amateurs who have never had to write any performance critical code in their lives."

I think the situation has improved since Java 5.0 thanks to Doug Lea.

http://gee.cs.oswego.edu/dl/concurrency-interest/i ndex.html

Yes, some Sun engineers are amateur. But I don't think you can claim that for Doug Lea!

Re:Reading Generified Code Makes My Brain Hurt

[Anonymous Coward]

Maybe you should try Delphi. Native compiler, fast, better wrapper round Win32 than C# (with no pinvoke), and a simple elegant language.

Re:Reading Generified Code Makes My Brain Hurt

[Anonymous Brave Guy]

The second definition of fold doesn't seem so bad.

Ah, but this is one of the big problems with syntax-bloated languages, of which Java is one of the worst. A basic definition of fold requires only two lines: one for the recursion rule, and one for the end case. When you start thinking that using "only 7 lines" to write fold is good, you know you've been used to bloat for too long!

Re:Reading Generified Code Makes My Brain Hurt

[Procyon101]

For fairness, lets compare Haskell's version, with this (fictional) Java-like syntax.
Being as the Java version has additional OO features (requiring the public and static keywords) and 2 of the 7 lines are brackets, because it doesn't use layout, which is purely stylistic, and it needs to use an accumulator, since it's strict and needs tail recursion, I still say it's not so bad. Any tail recursive fold is going to require the extra overhead of the accumulator, which is the bloat you see over Haskell's 3 line version (4 if we add type signature) since Haskell's laziness removes the need for the tail recursive version.

Java's horribly bloated (my original point), but this fictional language based on Java syntax is not a good example of it IMO.

// Idealized-Java TCO
public static fold(k, z, xs) {
        acc = z;
        for (x : xs) {
            result = k.apply(acc, x);
        }
        return acc;
}
// Haskell not tail call optimized (actual prelude code)
foldr k z xs = go xs
    where go [] = z
                go (y:ys) = y `k` go ys

// Non-tail recursive version in Idealized-Java. Not as pretty as Haskell's, but what is?
public static fold(k, z, xs) {
        return xs.empty() ? z : k.apply(fold(k,z,xs.rest()), xs.first());
}

Re:Reading Generified Code Makes My Brain Hurt

[Raenex]

Java Collections Framework is quite OK. It kills me that there's no SortedList interface or implementation in Java Collections. It's such a basic feature. Let's say you wanted to keep a sorted hand in a card game, where the suit doesn't impact the value. What class would you use?

This issue has been filed as a request for enhancement, but Sun doesn't want to implement it.

Re:Propz To Dead Homies yo!

[Profane MuthaFucka]

The bat signal is sweeping the skies! Jon Katz, where are you?

Re:C# compatibility? duh...

[JebusIsLord]

Man, that is just not fair. Microsoft has been burdened with backwards compatibility like no other company out there. I mean, except on 64-bit Vista, you can still run 16-bit DOS apps in the latest release of Windows, 20+ years later! Try running a circa 2001 OS9 app on a new Mac, and let me know how that goes for you. Microsoft has been hamstrung by their commitment to backwards compatibility; I am convinced that (and bad management) are the reasons for Vista's mediocrity. Yeah, some stuff broke, but I wish they'd broken more in the pursuit of a "good" OS.

On topic, C# 2.0 was introduced with .NET 2.0, which included bytecode optimizations that aren't backwards-compatible. The generics stuff probably could have been, but meh; Microsoft controls the only real .NET platform anyhow. Its not like they had to remain compatible with mobile phones and such, like Sun did.

Re:All Roads Lead to Rome

[Cyberax]

Unworkable. Polymorphism and ifs/switches are SEVERAL ORDERS OF MAGNITUDE faster than database access. So it's better to keep them separated.

As for metaprogramming - you can look at Nemerle (http://nemerle.org/Main_Page) which excels at metaprogramming. It's one of the best languages I've seen.

But there's research in bridging the gap between databases and code - see http://en.wikipedia.org/wiki/Language_Integrated_Q uery for an example.

Re:C# compatibility? duh...

[drooling-dog]

Uhm, can someone explain to me how NEW features of a language can be backwards compatible? Ummm... I think it means that programs that were written with previous versions of the language will not be broken by the new version and will continue to run correctly. That's what "backward compatible" has always meant, at least in my lifetime...

Re:C# compatibility? duh...

[MobyDisk]

It's compatible in that you can code something with a Java 5/Java 6 compiler, but is still runs on the Java 4 runtime. This is because they implemented generics as a language kludge rather than a true feature of the runtime. They traded performance for compatibility. Whereas with Microsoft, you can't compile something to use .NET 2.0 generics then run it on the .NET 1.1 framework.

Re:C# compatibility? duh...

[alyawn]

The language feature of generics *is* new. The compiler can still compile Java 1.1 source and can even compile to older class file versions. The generics implementation is for compile-time type checking, not runtime type checking. The compiled class file has no knowledge of generics.

Re:C# compatibility? duh...

[zlogic]

It probably gets translated into functions that run on older machines. Like C++ macros, templates and inline functions get translated into "pure" C++ code by the preprocessor, or C# 2.0 partial classes are combined together before compilation.

Re:C# compatibility? duh...

[twbecker]

Just because you can run multiple versions of the runtime on the same machine doesn't mean that your new code is backwards compatible.

Uhm, how did this get modded up? Backwards compatability isn't referring to running multiple JVMs. It's referring to the fact that you can write new classes that use generic types and methods, and those classes are still byte code compatible with pre-generic classes. This is because the type checking done by generics is compile time only - typing info is removed from the final compiled class via type-erasure. Asking how something can be true is one thing, asserting it isn't when you obviously have no idea what you're talking about is trolling.

Re:C# compatibility? duh...

[Proud like a god]

I think they mean the Java6 Generics code is compiled to bytecode that will run on previous versions of the JavaVM, in effect allowing you to create Generics in older Java, although I admit I haven't checked this.

Re:C# compatibility? duh...

[Cyberax]

No, you can't.

If your code uses Java 5 features then it won't run on JDK1.4. You can use tools like Declawer or Retroweaver to run 1.5 code on 1.4 but only to a certain degree.

Re:C# compatibility? duh...

[Hikaru79]

Who ever saw a version of a Microsoft product that was compatible with the previous version?

Are you joking? I hope you're joking. Because the alternative is that you are being criminally thick. I really think Slashdot should have a mod option -1 Misinformed

Say what you will about Microsoft, but backwards compatibility has always been one of their cornerstones. Their compatiblity layers still allow you to run apps from the early 90's on a modern copy of Vista today. I have managed to get some very old VB3 code working with a minimum of modification on VB6, which then, using Project Analyzer, got compiling in .NET in a matter of (admittedly frustrating) days.

And who are you comparing them with? Linux? You must be joking. Linux has trouble (read: is completely unable to) maintain binary compatibility with even relatively recent "old" code because of changing libc versions, etc.

Please, name ONE other operating system out there that can claim to run decade-old binaries flawlessly in its most recent incarnation.

Disclaimer: I'm a dedicated FOSS user and not a Microsoft shill in any way. But please, let's give credit where credit is due.

Generics, jeez

[kahei]

The original post is being just a little specious on generics -- the reason Java generics are backwards compatible is that they aren't generics, they're just automatic type conversions when accessing collections. Whee. C# generics may not be up to the level of true generic programming (e.g. C++) but they are at least 'templates' in the sense that ArrayList is a different type from ArrayList.

Java has come a long way but there's still a reason Java programmers cost about 60% of the cost of actual C++ programmers (curse them).

Re:Generics, jeez

[HotBBQ]

Java has come a long way but there's still a reason Java programmers cost about 60% of the cost of actual C++ programmers (curse them).

Not trying to be a pain, but I don't understand the cost observation. What are you implying? I've been working with Java extensively in my profession and my pay is the same as any programmer with my education and experience. Just curious.

Re:Generics, jeez

[Shados]

Normally, something like a mainstream 4GL programmer (like VB6, though I can't think of any that are quite mainstream anymore) is pain less than a .NET programmer, who's pain (slightly) less than a Java programmer, who's pain less than a C++ programmer, who's paid less than an assembly programmer.

Or something. Just a matter of supply and demand. Demand for C++ programmers ain't so hot anymore, but supply is extremely low, with the only place really to get them is straight out of college, since otherwise right after they'll flush all their C/C++ experience for one of the newer environments.

Not really hard data to back this fact, just my observations from last time I was looking for a job (a few months ago), so take that with a grain of salt, but...

Re:Generics, jeez

[cs02rm0]

Normally, something like a mainstream 4GL programmer (like VB6, though I can't think of any that are quite mainstream anymore) is pain less than a .NET programmer, who's pain (slightly) less than a Java programmer, who's pain less than a C++ programmer, who's paid less than an assembly programmer.

Yeah, I find C++ programmers a pain too.

Re:Generics, jeez

[Shados]

Hmm... now thats a nice freudian slip.

Re:C# compatibility? duh...

[Anonymous Coward]

Simple: in the case of Java Generics, old code can still use generic collections.

So, for example, if you have some old code that adds Strings to a List, you can pass it a List of Integers from new code, and it'll happily add Strings into your generic List of Integers.

A more useful example might be something where old code promises it'll only add Strings so you can pass a generic list of Strings, only to discover at some random point later where the legacy code accidentally added a StringBuffer.

Seriously, though, you can't use generics in pre-1.5 code. Any code that uses generics generates binaries that only work in 1.5 or later JVMs. (Despite the fact that generics are compile-time only.) The only "backwards compatible" part is that pre-1.5 code will still compile and pre-1.5 binaries will still run. As I've suggested above, though, that backwards compatibility completely defeats the purpose of generics.

Which isn't to say they're completely useless, but they're essentially no more useful than a simple comment to indicate what the programmer wants the collection to contain rather than what it actually contains. Especially when legacy code is involved.

Sticking to Java 1.4.2.x

[roman_mir]

There was a time when I actually was hoping to move from Java 1 to 1.1 and then later from 1.1 to 1.2 The move from 1.2 to 1.4 was still a good thing. However after trying Java 5 and 6 I refuse to move away from 1.4 I do not feel the need to move from something that works to something that pretends that it does more than it really does and introduced an entire set of problems on the way. As far as I am concerned the language is already bloated. I would love to see Java drop inheritance off entirely (and I have used it correctly too,) but there is no need for it really. Everything can be done with interfaces and libraries. From what I see the game is not really concerned with 'correct' implementations of pure coding paradigms, but it is rather concerned with good easily maintainable solutions where the mix of developers mostly consists of below average coders. Oh, and bringing varargs into a language? Talk about shooting yourself in the foot.

Re:Sticking to Java 1.4.2.x

[MCTFB]

I agree mostly, though varargs I have found to actually be very useful in a few cases where it can greatly improve readability. (though due to the reflection aspect of how varargs works under the hood, they should never be used in performance critical code). As for everything else, well yah it is just syntactic sugar.

Unfortunately, lazy or newbie programmers will use autoboxing and varargs more than just sparingly and being the second generation coder on a project where these features are used liberally is a hell I would not wish on my worst enemy.

Re:Sticking to Java 1.4.2.x

[Cyberax]

Sorry, but that means you don't want to learn new things.

Generic code is much easier to maintain and read because you have MORE type information. Another changes like foreach loop and varargs are just syntax sugar and do not deserve more than a few minutes of attention.

Re:Sticking to Java 1.4.2.x

[Doctor Faustus]

I would love to see Java drop inheritance off entirely (and I have used it correctly too,) but there is no need for it really. Everything can be done with interfaces and libraries.

You know, one of the biggest critisisms of classic VB was always that it only had interfaces and libraries, and not real implementation inheritance.

I think what I'd like to see if for polymorphism to be done entirely with interfaces, and for implementation inheritance to be supported, but hidden from client code.

Re:Sticking to Java 1.4.2.x

[Have Brain Will Rent]

Unfortunately, lazy or newbie programmers will use autoboxing and varargs more than just sparingly and being the second generation coder on a project where these features are used liberally is a hell I would not wish on my worst enemy.

I'm curious as to what, in your opinion, would be an example of a justifiable use of autoboxing and what would be unjustifiable?

For everybody tossing around the phrase "syntactic sugar" just a reminder that everything besides 0 and 1 is syntactic sugar of one sort or another.

Re:Sticking to Java 1.4.2.x

[Anonymous Coward]

You do know that you can use Java 5 (and 6) without having to use any of its new language features. By snubbing your nose at the newer versions, you're effectively throwing away performance benefits of the newer JVMs for no good reason. Just compile your code with the -source=1.4 flag and you should faster execution times without having to deal with generics, annotations or any of the new stuff in 5.0.

Re:Sticking to Java 1.4.2.x

[roman_mir]

I learned new things alright, I learned that these so called generics do not in fact create new types in the JVM but simply add meta information to already existing Lists. You can still add an object to a list, which was not defined in the declaration and you can still get a ClassCastException.

As far as I am concerned my comment is correct. (Java 5 and 6) pretends that it does more than it really does and introduced an entire set of problems on the way. I am not thrilled about the novices laying their hands on varargs and autoboxing, it is going to be a nightmare to maintain in large projects.

Re:Sticking to Java 1.4.2.x

[roman_mir]

At this point I believe that the fewer language features and sugars allowed by the compiler outweighs the performance benefits of the newer JVM. I wouldn't let a new project start on anything above JVM designed for 1.4

Re:Sticking to Java 1.4.2.x

[roman_mir]

forgot to add, that it is possible to use a newer JVM 5 or 6 to run 1.4 code, there is a compiler directive for that.

Re:Sticking to Java 1.4.2.x

[roman_mir]

Well, I don't control the mods, but the intent of my previous post (the parent post) was most definitely not to troll anyone. Any intelligent person would see that.

Re:C# compatibility? duh...

[Cyberax]

It means that you can create List and pass it to a legacy method which takes only unparameterized List. Or you can get unparameterized List and cast it to parameterized type.

It's impossible to do in C#/C++.

Re:C# compatibility? duh...

[Anonymous Coward]

You can compile code that uses generics and run it on older versions of the virtual machine, that is, the bytecode implementation of generics looks like regular, pre 1.5 bytecode

Re:C# compatibility? duh...

[CastrTroy]

I like the way MS implemented their Geneics. Too bad they tie the .Net framework to specific versions of VS.Net. So those of us stuck using VS.Net 2002 don't get to use .Net 2.0. And no, Generics aren't worth the cost of the upgrade.

Re:C# compatibility? duh...

[nuzak]

It's compatible in that you can code something with a Java 5/Java 6 compiler, but is still runs on the Java 4 runtime.

Which happens seldom, because by default the JDK will output a classfile version that older JVMs will refuse to run. People compiling for retrograde targets usually use a JDK from that version too, otherwise they could inadvertantly target standard library API's that don't exist in older versions. Java could make non-erased generics in the future too, just by way of changing the classfile specification and just not erasing them from version 8 on (it's too late for 7). All in all it's mystifying why they did as little as possible with respect to generics, especially in the face of superior generic systems like those in Pizza, other than that they didn't want to disturb the programmers and managers that they believe, by and large, are stupid sheep and easily frightened.

I didn't know that Wadler was behind GJ. I can call GJ's erased generics a kludge, a crock, a hack, a half-assed unsound system, but Wadler really does know his shit.

Erasure isn't the complete end of soundness anyway -- scala generics are erased too, and it still has a far superior type system.

Re:C# compatibility? duh...

[alyawn]

Right... but you can recompile the source telling javac to produce class files that are 1.4 compatible: `javac -target 1.4'

Two words: Type erasure

[BitwizeGHC]

Java generics are kept back-compatible with the old VM spec by way of type erasure: parametric information is "erased" from the type when it is compiled. So List and List and List all compile down to the same type: List.

Among other hiccups this makes it impossible to overload methods whose argument types differ only in the parametric information included with them.

By contrast, C++ templates and C# generics create a type disjoint from all other types in the same type class for each set of parameters in the type declaration.

Yet another sterling example of Java lossage.

Re:Two words: Type erasure

[MCTFB]

Hey if you like 23234290234^345 sized megabyte applications where most of the program memory is used up by a bunch of redundant templates, then more power to yah (-:

Re:Two words: Type erasure

[Keith Russell]

C++ has that problem, but Microsoft was a bit more efficient with that in .Net. It tries to share code wherever possible.

For structs and values, code is generated per-type. Thus, there are separate code blocks for List<int> and List<DateTime>, but multiple List<int> instances will share code.

For classes, all instances share one single code block. Thus, List<LeftHandedScrewdriver> and List<SelfSealingStemBolt> share code.

Re:Two words: Type erasure

[cnettel]

That's true for C++ (in most implementations and unless you are conscious about it, like STL, which casts to void* internally in several places), but for C#, a conversion is made back for all "reference types". That is, all non-value types basically share one set of IL and JITed code in the workset. The binary representation in the file will always be a single IL copy for List and List.

I don't see any reason to consider the Java approach superior. The backwards compatibility is only an issue if you have made (somewhat) bad choices about argument types: you generally shouldn't require an ArrayList in the first place, but just a List. Back to .NET: all the generic collections (for example) implement the corresponding non-generic interfaces, so if you used an IList in some piece of 1.1 code, you can plug in your generic List just fine.

Re:Two words: Type erasure

[jgrahn]

Hey if you like 23234290234^345 sized megabyte applications where most of the program memory is used up by a bunch of redundant templates, then more power to yah (-:

Absurd. Let's assume I use 5 kb of std::list<T> (and that's probably generous). To use up a megabyte on that, my program would have to use lists of 200 different non-pointer types. You should probably worry more about massive, recursive inlining.

Re:Two words: Type erasure

[Anonymous Coward]

Hey if you like 23234290234^345 sized megabyte applications where most of the program memory is used up by a bunch of redundant templates, then more power to yah (-:

If you don't need multiple instances, don't create them. It's pretty easy to make the template around generic wrapper code that does exactly what Java forces you to do everywhere, you just have to know to do it.

Re:Two words: Type erasure

[andr0meda]

Well, as opposed to C++, you can use the generic type List without actually having the source of it. This is different in C++ where every new template instance requires that you link with the original template definition. In Java, you can use release versions of distributed jars from 3rd parties and still use your own generic instantiations, which is a feature that is often overlooked.

I agree on the overloading issue, but I think using interface types to address the issue can help you in most of the cases.

I think overall C# does the better job on both accounts.

Java-only programmers?

[mr_mischief]

Wouldn't someone have to be used to _only_ Java to not be familiar with at least some of these concepts?

Enumerations are available in Pascal and pretty much all of its descendants IIRC. It's also a type of field in an SQL database for much the same purpose as enumerations in programming languages.

The foreach loop has been in Perl since 2.0 in 1988. C# got foreach in 2000. It's in PHP. It comes from earlier FOR..IN loops from shells.

I'm sure there are examples of the other features which are similar to the Java version of them. The syntax may be different, and the exact details of darker semantic corners may be different. The concepts, however, are pretty easy to have run across unless someone has only used the one language.

The review seems to imply that bringing in what has been proven to work well in other languages is too confusing and should be done at a slower pace. The truth is, people program in a subset of any general-purpose language at first, and that subset grows over time. If someone works with code from other programmers, one picks up the parts of the language to which they are exposed as they are exposed to them. No one needs to cram all night to be up on all the new features of a language the day after the manual gets updated.

Re:C# compatibility? duh...

[FunkyELF]

They can do this because all checking is done at compile time. No features were added to the runtime to get this.

Once compiled into bytecode a Vector>> looks just the same as a regular vector of objects and the compiler takes care of all the casting for you.

No more
int i = ((Integer)((Vector)((Hashtable)vec.get(3)).get("wo w")).get(2)).intValue();
Just
int i = vec.get(3).get("wow").get(2);

Well, this example used the auto-boxing feature too to convert the Integer to an int.

Two words: Bracket erasure

[BitwizeGHC]

Sentence in the above post should have read as follows:

So List<String> and List<java.math.BigInteger> and List<javax.swing.JComponent> all compile down to the same type: List.

Re:Two words: Bracket erasure

[MythMoth]

> Sentence in the above post should have read as follows

I just thought you were being ironic...

Re:Two words: Bracket erasure

[Anonymous Coward]

Oh, I just assumed you had run your comment through a java compiler :)

warning: nitpicks ahead

[PhrostyMcByte]

introducing generic programming in a simpler, safer way than C++ templates and, unlike generics in C#, maintaining backwards (and forwards) compatibility with existing Java code."

*prepares to be modded troll*

People need to stop comparing Java/C# generics to C++ templates - they take similar syntax, but they aren't the same thing. I'm not sure how one can even be safer than the other.

And C# 2.0 maintained compatibility with existing C# 1.0 code (you still have access to the old containers) while actually giving significant performance benefits where Java is only syntax sugar that still produces the same old slow code.

Re:warning: nitpicks ahead

[jinxidoru]

This is so true. Although generics give Java/C# a similar tool, they are very different. C++ templates actually create entirely different chunks of assembly code. C++ templates provide compile-time type-checking but they also provide run-time binaries. This makes C++ templates very fast and able to create extremely optimized code for each type used. This may surprise you, because you've heard from people with no C++ knowledge that templates are slow. People who say that are not familiar with templates in the least. On the other hand, generics simply provide compile-time type-checking. They do nothing more. So, as you can see, they are quite different from C++ templates.

Re:warning: nitpicks ahead

[andy9701]

introducing generic programming in a simpler, safer way than C++ templates and, unlike generics in C#, maintaining backwards (and forwards) compatibility with existing Java code."

And C# 2.0 maintained compatibility with existing C# 1.0 code (you still have access to the old containers) while actually giving significant performance benefits where Java is only syntax sugar that still produces the same old slow code.

What I'm assuming that he meant is that Java 5 is byte-code compatible with the previous version. You can take an app built with Java 5 and run it on a machine with Java 1.4.2 installed, and it will run.

This is not the approach taken with C# - if you run an app built with C# 2.0 on a machine with 1.1 installed, you'll get an error message saying that it can't read the assembly, since the internal format has changed between the two versions.

Re:warning: nitpicks ahead

[Anonymous Coward]

You can take an app built with Java 5 and run it on a machine with Java 1.4.2 installed, and it will run.

Well, I certainly wish the reverse were true. Most of our applications will crash and burn if run under Java 5. The developers had to disable automatic updates for Java 1.4.2 to prevent the customers from breaking them.

And modded up, too

[dedazo]

That's clever, yes. I suppose there has to be one of these in every "discussion". Thanks for increasing the signal-to-noise ratio and all that.

Re:C# compatibility? duh...

[FunkyELF]

Replying to self....Should have used preview.... my <'s and >'s didn't show up right in the text.

It should have said ...

Once compiled into bytecode a Vector<Hashtable<String,Vector<Integer>>> looks just the same as a regular vector of objects and the compiler takes care of all the casting for you.

Re:C# compatibility? duh...

[laffer1]

While you are mostly correct, Microsoft has been removing compatibility features in newer versions of Windows. OS/2 and POSIX subsystems present in Windows 2000 and Windows NT were removed for Vista. Actually, one of them was removed in XP SP2.

There is nothing wrong with offering compatibility. Microsoft's approach to compatibility needs to change a bit. Separating the legacy system from the modern system should be more exact like Classic support in OS X (pre intel). Really old apps ran in a sandboxed OS9 install. (non carbonized) Microsoft could even go a step farther by working on something with Virtual PC. They could provide a built in DOS/9x compatibility system with say directx 5 support. That would allow most really old stuff to run while they trim some of the fat from the current winapi.

Java One session

[LarsWestergren]

Naftalin and Wadler are also holding a Java One session this year, it is on Wednesday, session id is TS-2890. If you have a Sun Developer Connection account (free) you can watch it online after the conference is over.

I agree with reviewer, the book is very good. It is true that Java generics is a compile time check, and that the generics information is removed (erasure). Nevertheless, that was a deliberate tradeoff for backwards compatibility, and it still makes coding complex Java a lot safer and easier. Look for instance at the 1.5 and 1.6 improvements to the concurrency libraries with Future, Callable and Executors.

Re:Java One session

[sjelkjd]

>>Nevertheless, that was a deliberate tradeoff for backwards compatibility

What does this mean exactly? You can have type safe generics AND backwards compatibility. My old non-generic code will still work in a language with generics. Maybe you wanted to pass ListofT to a method that takes List. That's really a different issue - it's NOT backwards compatibility, more like cross-compatibility. If you wanted backwards compatibility you probably should have written your method to take IList in the first place. Whoops. The so-called backwards compatibility is really an excuse for lack of proper runtime support of generics. But nice try to spin it as an advantage.

Re:C# compatibility? duh...

[Anonymous Coward]

Use Mono and it runs on other plantforms: don't whine at Microsoft stuff before learning all facts.

Re:C# compatibility? duh...

[_xeno_]

As soon as you use a generic, the Java compiler requires -source 1.5 and -source 1.5 requires -target 1.5 or higher. So -target 1.4 won't work, even though theoretically generics needn't require 1.5 binaries as all the checking is done at compile-time.

Re:C# compatibility? duh...

[Cyberax]

That won't work if you use new Tiger features. It's just like you're using an older version of compiler.

Re:C# compatibility? duh...

[Anonymous Coward]

You have that backward. VS is tied to a particular version of .Net, not the other way around.
And yes, that does suck.

Re:C# compatibility? duh...

[forgotten_my_nick]

> If your code uses Java 5 features then it won't run on JDK1.4.

Your wrong. Or at least when it comes to Generics (I haven't tested the rest). Everything is done at the compiler level. So even if you use Generics the code is changed to work in 1.4 if you set javac -target 1.4.

Re:C# compatibility? duh...

[fireboy1919]

but meh; Microsoft controls the only real .NET platform anyhow

This is what makes it so utterly astounding to me that a great many of the standard libraries that Microsoft pushed on everybody for .Net 1.1 are replaced with something else entirely in 2.0.
They didn't even bother with a deprecation phase - just gone.

So not only will code compiled for .Net 2.0 not necessarily work on 1.1 - code written for 1.1 will not necessarily work for 2.0.

You have to manually check which version you're running and run different segments of code to do certain tasks.

That's why I think of .Net code as being a lot like Java code, except probably not portable between VMs.

Re:C# compatibility? duh...

[Pxtl]

Yep. I was extatic when C# got generics... for a while - but pretty quickly you start runnign into their limitations (or at least the limitations of the standard ones).

For example, you want a class that contains a list - you get to look forward to either (a) reams of boilerplate code as you forward all the methods of the list that an outside user might need, or (b) publicizing the list and completely mucking up your class invariants.

Plus, no typedef, so get, nested> class, declarations> - twice if you need a constructor. And Using statements are not a substitute unless you write your whole project in a single .cs file.

A lot of coders use subclassing instead of typedef, but that opens a new can of worms - forwarding constructors, destroying the substitutability of the class, etc.

Re:C# compatibility? duh...

[Jugalator]

Microsoft has been hamstrung by their commitment to backwards compatibility; I am convinced that (and bad management) are the reasons for Vista's mediocrity. Yeah, some stuff broke, but I wish they'd broken more in the pursuit of a "good" OS.

The sad part of this story was that the pursuit of a better OS was scrapped. Longhorn was more than a mere codename; it was a radically different vision than what Vista ended up as. I can only imagine the frustration at Microsoft as they had to make that decision. They lost more than WinFS in the process, that's for sure.

Re:C# compatibility? duh...

[RetroGeek]

What does forward compatibility even mean?

The hope that deprecated will never happen.

Not a good way to teach

[Yurka]

OK, this finally is a comment about the book itself, and not about its subject. In my practice, it is almost impossible to get people to understand that generics do not mean "a List of Objects now becomes a List of objects of certain type". Once a person latches onto this notion (that parameterization is simply a way of indicating something similar to a collection), he is almost impossible to shift from it - I've tried explaining the declaration of the base Enum (which is Enum<E extends Enum<E>> - to get the compareTo () to work in a type-safe manner) to seasoned Java developers, only to get (without exception, or even a Throwable): "Oh, I get it, that means that Enum contains other Enum-like things!". And yet the book dives right into this concept; the first glimpse of the actual meaning of parameterization does not appear until the section 2 of chapter 3, a good one third way through. If I were to do it the right way, I'd start with <T extends Comparable<T>>, explain it thoroughly, and only then allow Collection to enter the picture. So, I would disagree with the reviewer - if you want to understand ? super Foo, this is not the book, unless you are willing to skip the first 2 chapters.

Re:Not a good way to teach

[Anonymous Coward]

> generics do not mean "a List of Objects now becomes a List of objects of certain type"

Actually, it means pretty much exactly that for Lists. It's just better to also introduce things into the mix that aren't containers.

Comparable is pretty easy when you just use the word "with". A comparable is comparable with other comparables, and only with those that are subclasses of its own type. Enum is the same way though it's harder to explain it in words. I still think the syntax isn't quite right though.

C++ Templates

[fittekuk]

While Java generics may be simpler and easier to use than C++ templates, they fall far short of the feature set of C++ templates. They do not really provide "generic programming" in the same sense that C++ templates do. There is much more to generic programming than being able to have a HashMap.

Re:C++ Templates

[Vintermann]

What C++ gives is not generic programming, but template/macro/metaprogramming, which is general enough to be used for generics. Generics was its original purpose, which shows in the syntax.

Templates can be used for generics, but generics (as a language feature, as in Java, Ada, and C#) are not for metaprogramming. That is neither a strength or a weakness, they're just something different.

Re:C# compatibility? duh...

[Anonymous Coward]

That doesn't sound right to me. Can you give me some examples?

Re:C# compatibility? duh...

[Pxtl]

Ick, pwned by the same mistake as parent poster. I meant some, this>.

Re:C# compatibility? duh...

[wezeldog]

OS/400. I believe it ran system/36 code. When they switched to PowerPC, programs 'converted' to 64-bit on the fly thanks to TIMI. Hope this helps.

In this case I'd take the tutorial over Wedler.

[Anonymous Coward]

Which explains why Philip Wadler, one of the people responsible for Haskell, was part of a team that wrote GJ (Generic Java), one of the experimental Java mutations (others included PolyJ and Pizza) that, back in the day (late 90s) helped explore how parametric polymorphism could be added to Java, and which formed the basis for the generics introduced in Java 5.

So if you want to understand generics, Wadler is your man.

I think that this a very twisted and silly conclusion. Just because someone wrote or developed something doesn't automaticly imply that he or she is the best person when it comes to explaining everything about it. Quite frankly I think its much more of the opposite. Developers are by definition not the best people to turn to when you wish to really learn whatever they developed. While a developer would try to approach his ideas from a technical point of view most students would be more helped when you begin slow and abstract and eventually work your way up.

Naturally I'm a bit cynical here but heck. To me this has once again nothing to do with an intersting article but simply yet another post to try and push some "interesting" book forward thus hoping that someone is going to make more money out of it.

My opinion in all this is simple. If you're interested in Generics then the best place to start learning is the Sun Java tutorial. In this case the trail about Generics would sound like a good idea to start reading.

And you know whats so good about this tutorial? Its free, its from the company which developed Java (a company which doesn't only have very good developers when it comes to Java but also has people available who are quite skilled on documenting) and you can even download it so that you can read and study even if you don't have a permanent connection to the Internet.

Re:C# compatibility? duh...

[JebusIsLord]

Totally not how it works. You can (and should) install both 1.1 and 2.0 concurrently, and the bytecode runs on the vm it was compiled for. Problems averted.

Re:C# compatibility? duh...

[Helios1182]

Some IBM mainframes such as the zSeries still run System 360 code unmodified. That is 4 decades right there.

Static type checking

[igomaniac]

Isn't all static type checking some kind of compile-time hack? I think you're completely misinformed about 'generics' in C++, as they are more like macros than anything else. C++ templates are nothing like a real type system which can be found in Haskell amongst others...

Re:Static type checking

[nuzak]

C++'s templates are just as much a type system as any other. All type systems are essentially about substitution, it's just that C++ templates do it in a more literal sense. C++'s syntax for it happens to really suck, but the theory is perfectly sound.

Troll? Try sarcasm

[Anonymous Coward]

Sun did jump from 1.4 and 5.0 in the past. Java naming and versioning is a sad story.

Re:C# compatibility? duh...

[cortana]

Solaris?

PS, you said "Linux" when you meant "GNU/Linux". AFAIK the kernel ("Linux") takes backwards-compatibility pretty seriously... obviously that's only a small part of the puzzle, the rest is up to the various distributors.

At the end of the day, does it matter? If you have the source to the programs you run then you can always update them to work with newer systems. If not then, well, that comes with the territory.

Poppycock

[the eric conspiracy]

The most far reaching changes to Java in Java 5 are the changes to improve support for concurrency. Generics are just syntactic sugar that improve compile time type checking. The concurrency support features offer fundamental improvements in the way you can structure your applications to take advantage of increasingly parallel hardware architectures.

Re:Poppycock

[elFarto the 2nd]

I agree completely, the Concurrency stuff in 1.5 is absolutely lovely. I even ported one of the classes (CountDownLatch) back to 1.4 because it is so useful.

Re:Poppycock

[matfud]

Why not try the backport of the concurrency package http://dcl.mathcs.emory.edu/util/backport-util-con current/

Re:Poppycock

[the eric conspiracy]

I used this concurrency backport. It is really helpful if you are looking at a slow migration to Java 5 but want some improvements in your Java 1.4 application.

Re:C# compatibility? duh...

[ClosedSource]

To be fair, this is a trade-off. Generics in Java allow backward compatibility which you pay for with type erasure (i.e. generics provide compile-time autocasting so the JVM still thinks everything is an object).

If you're maintaining an existing Java application, it's not likely that you're going to rewrite it in C# anyway. If you are starting from scratch without any commitment, I think C#'s approach to generics is better (I'm just talking about this particular issue, I'm not saying that C# is better than Java for all new projects).

foreach

[Mike McTernan]

This is a great construct, but I found that it can be quite inefficent because it creates an Iterator and uses that to traverse whatever is being passed. For some collections such as ArrayLists, I found using a good old loop and .get(index) performed much faster and avoided creation of Iterators and therefore needed less garbage collection. Foreach is very neat and great in lots of places, but it should come with a small health warning for the cases where performance is critical.

My application was very heavy on traversing ArrayLists though.

Re:C# compatibility? duh...

[Gr8Apes]

Who ever saw a version of a Microsoft product that was compatible with the previous version?

Are you joking? I hope you're joking....

Say what you will about Microsoft, but backwards compatibility has always been one of their cornerstones. Their compatiblity layers still allow you to run apps from the early 90's on a modern copy of Vista today. I have managed to get some very old VB3 code working with a minimum of modification on VB6, which then, using Project Analyzer, got compiling in .NET in a matter of (admittedly frustrating) days. Obviously, your and my definitions of backwards compatibility differ a bit. OS/2 2.0 apps ran on all version through 2.4, and those OS versions also ran a lot of 1.x apps. No recompile or tweaking necessary, thank you very much. On Macs, apps compiled for OSX 10.2 run just fine on 10.4. Heck, apps compiled under 10.2 PPC run just fine on 10.4 Intel. All with no recompiles. Stuff just works.

Microsoft doesn't work. Look at all the apps they broke with XP SP2. Look at everything that doesn't run under Vista. Heck, look at what didn't work under Win XP/2K that did under NT 4. Remember the Office 95 fiasco? Microsoft is the poster boy for incompatibility. I'd dare you to name a company that had greater incompatibilities between versions than MS.

Re:C# compatibility? duh...

[Anonymous Brave Guy]

It means that you can create List and pass it to a legacy method which takes only unparameterized List.

Whether that is a useful compatibility mechanism or a fundamental weakness in the type system that defeats the entire point of generics is left as an exercise to the reader.

Re:C# compatibility? duh...

[Anonymous Brave Guy]

int i = vec.get(3).get("wow").get(2);

Heh... Now you just have to get operator overloading and type inference, and you'll be able to write

i = vec[3]["wow"][2];

like those of us with real programming languages. ;-)

Java 5 SCJP

[hansamurai]

I'm less than two weeks away from taking the Java 5 certification exam, and Generics are definitely the most difficult new concept for me to get my head wrapped around. Granted I haven't studied it nearly enough yet and haven't done any large scale projects in 1.5 (we use 1.4.2 at work), so hopefully I'll be well prepared by the time next Friday rolls around. I use the Sierra, Bates SCJP book to study and it supposedly has everything I need to know about Generics for the exam, but is it everything I need to know for the "real world"? Maybe I'll check this book out, but after the exam. Don't want to get confused with real applications of generics. :)

What they said

[wilder_card]

Java generics are mildly useful. To even mention them in the same breath as C++ templates, however, is extremely misleading. C++ templates go far beyond simply providing type-safe collections.
<soapbox>Of course, both mechanisms are work-arounds for the defects in the strongly-typed language paradigm. For the right way to handle types, look at python. Python uses untyped references to refer to typed objects, and written code is far simpler.</soapbox>

Re:What they said

[Anonymous Coward]

Weak typing is a nice tool, but it requires a lot of discipline to use safely. Say you write a string-reversing function. In Python, that function will work, unmodified, on any subscriptable type, which may include objects having a __getitem__() method. This may seem like a free feature, but in reality it's an invitation for bugs in your code. I mean, you expect reverse() to be used only for strings, so if you ever invoke it with any other data type, it is by definition a bug. And it's a bug which may not cause an exception until much later in your program, by which point you have absolutely no idea how this variable got the value it has. Or worse yet, your program may not give any errors at all, it may just silently produce the wrong output.

You can of course work around this using e.g. isinstance(). But that carries the double-edged sword of being a run-time check. That lets you do some incredibly powerful things, but it also means that you won't spot a bug until the last possible instant. If you've got a big application that takes hours to run, that can be a real bitch to debug. You'd better be damn good at unit testing.

Strongly-typed languages, on the other hand, can spot this common class of problem at compile time (or even while you're still typing away in the IDE). Well, not always, if you've got inheritance and polymorphism, which is why you've always got to be real careful with those beasts. But even if it's not perfectly safe, it's at least more difficult to be unsafe than it is in Python.

I love Python - I really do - but the only reason it hasn't got the reputation for terrible security that PHP does is that most Python folks were good programmers before learning the language.

Re:What they said

[gss]

umm Java generics do go far beyond simply providing type-safe collections.

Re:What they said

[Anonymous Coward]

Python is strongly-typed. Look up the difference between strong/weak typing, static/dynamic typing.

Re:C# compatibility? duh...

[kaffiene]

Utter BS. I worked for a couple of years developing Win32 apps. We supported everything from 95 through to XP and I can assure you that there is NO FUCKING WAY that the OS runs the old binaries flawlessly!

The code is riddled with conditional paths for different OS versions. Testing across windows versions was a nightmare.

I suggest it's you who is being criminally thick.

Re:C# compatibility? duh...

[Anonymous Coward]

> PS, you said "Linux" when you meant "GNU/Linux"

Give it up, Richard, no one's listening.

> AFAIK the kernel ("Linux") takes backwards-compatibility pretty seriously

ballocks -- drivers break with every patchlevel release, sometimes because maintainers decide the functions looked nicer with different names and in a different order. It's the userland that tends to remain compatible over time.

Re:C# compatibility? duh...

[bckrispi]

Loose typing and Operator Overloading in Java?? Smithers, release the hounds!!!

Re:C# compatibility? duh...

[maxwell demon]

It means that you can create List and pass it to a legacy method which takes only unparameterized List.

Whether that is a useful compatibility mechanism or a fundamental weakness in the type system that defeats the entire point of generics is left as an exercise to the reader.

Especially since the summary states: "safer way than C++ templates" (why does virtually every text about Java add some C++ bashing?).

Troll

[Anonymous Coward]

introducing generic programming in a simpler, safer way than C++ templates

Nice Java Troll.

Re:C# compatibility? duh...

[Anonymous Coward]

The backward compatibility can be that library written in older version such as 1.4 can be used in JDK5. This sounds like forward compatible, but it's the JDK5 can work with 1.4 binaries. For example, if a third party lib take List, but if generic was in place in 1.4, they would have taken List. So, now, users can code with List and pass into the old library and it works. You may ask why bother. This is important because that list is also passed around in the new code, so checking is important.

Some people also says it's useless. To me, it's very useful. It's not 100% perfect doesn't mean it's useless. I think those people doesn't have a clue . Performance increase or not, or how it's compiled in byte code is almost irrelevent, because at least to me, it's about reuse of code in a safe way (compile time checking). Some can argue that but compile time checking doesn't work well. Sure, it's not perfect, but it works most of the time. You can always find loop whole in the language to crash your OWN code, but that's the power of the language, so you can crash your OWN code. For the sane people, generic is very helpful for a large project with many developers.

Re:C# compatibility? duh...

[cortana]

>> PS, you said "Linux" when you meant "GNU/Linux"

> Give it up, Richard, no one's listening.

Please pay attention. My reasons for making the distinction were clearly laid out in the post. When talking about the kernel vs the whole "operating system" (whatever that means) there is a clear distinction between Linux (the former) and GNU/Linux (the latter).

> > AFAIK the kernel ("Linux") takes backwards-compatibility pretty seriously

> ballocks -- drivers break with every patchlevel release, sometimes because maintainers decide
> the functions looked nicer with different names and in a different order. It's the userland
> that tends to remain compatible over time.

We are clearly talking about user-space apps. The stability of the kernel itself is not under discussion--merely the API presented to user-space programs.

Re:C# compatibility? duh...

[ink]

$ javac -target 1.4 ./messenger/*
javac: target release 1.4 conflicts with default source release 1.5

That doesn't work. Backwards-compatible means that the 1.6 JRE will still run Java bytecode compiled under old platforms (back to the original Java 1.0).

Re:C# compatibility? duh...

[Anonymous Brave Guy]

why does virtually every text about Java add some C++ bashing?

It doesn't, but since a significant part of Java's target audience is people who don't understand/appreciate C++, it's not surprising that some of the commentary demonstrates an ignorance of the underlying models in the two languages and their relative strengths and weaknesses.

Re:C# compatibility? duh...

[644bd346996]

To be fair, try finding a popular OS9 app circa 2001 that was not updated with a PPC OS X binary. A lot, probably most, of the popular OS9 apps can still be run in one form or another on an intel mac, using only included and free software. For example, Starcraft got an OS X installer at some point, and it now runs better through Rosetta than the windows version does through wine. Myst III also got an OS X update after release, and now runs on my intel Mac.

Also, Microsoft has really been prioritizing backwards compatibility too much. There is no reason for current versions of Windows to still be able to run DOS apps outside of an emulator, and it is absurd to try to pass that off as a selling point or even a nice extra feature. We would be better off if microsoft were willing to forgo some of that compatibility so that the current operating systems could be made more secure and stable, and most importantly, so that they could spend more time developing new features that would offer users a compelling reason to upgrade.

Re:C# compatibility? duh...

[Jerry Coffin]

It means that you can create List and pass it to a legacy method which takes only unparameterized List. Or you can get unparameterized List and cast it to parameterized type.

It's impossible to do in C#/C++.

I think saying it's impossible in C++ is a bit misleading at best. C++ has had templates since the very first version of the C++ standard. As such, at least in terms of standard C++, there's simply no version that lacks templates with which to be compatible. You can't cast std::list to some unparameterized type, because there's no unparameterized list type to which to cast it -- but if you decide to create your own StringList class (or whatever you prefer to call it) it would generally be quite trivial to make it support such a cast if you wanted to (though, of course, it's probably a poor idea to create such a class).

OTOH, back before the standard, there were some class libraries that did about like Java does, and Smalltalk did before it, with a monolithic class library rooted with Object (or something similar). When compilers added templates, some of these libraries added template front-ends for the containers that worked a lot like Java generics, basically just automatically adding casting where needed. In these cases, it was pretty easy to mix the two in about the same way as Java does.

Sneaky compiler error?

[keester]

If you see the error at compile time, then it's not sneaky. Feel free to use generics with Java 5. Just be sure that your work compiles ...

Re:C# compatibility? duh...

[JebusIsLord]

I agree completely, but understand that Microsoft is catering to business much more than Apple, and legacy applications (which often go unmodified for a decade or more) need to run on newer OSes. Otherwise businesses simply won't upgrade, and thus Microsoft looses the sale.

Apple forced the 3rd parties to release updates for OSX, and therefore all the teething problems Vista is having can be seen as a good thing... UAC means that we'll finally have 3rd party apps that work properly with unprivileged user accounts.

Compared to Duck Typing?

[misleb]

I have not done any Java in years. I wonder how this compares to duck typing as in Ruby. Can anyone explain this in terms of Ruby's duck typing and collections?

-matthew

Re:Compared to Duck Typing?

[jma05]

> I have not done any Java in years. I wonder how this compares to duck typing as in Ruby. Can anyone explain this in terms of Ruby's duck typing and collections?

Generics is a compile time concept. Duck typing is a runtime concept. It's the difference between static vs dynamically typed languages. Both work very differently but effectively save you from redundant type casts.

Re:Compared to Duck Typing?

[RussellClarvoe]

Duck typing allows type information to be applied at run time.. Generics allow the programmer to specify all ( well, a lot ) of the type infromation at compile time.

If you're interested in a comparison between Ruby and Java you should check out Beyond Java by Bruce Tate.

A lot of the posts have been comparing java and C#'s generics, but the real question is closer to what you asked. Are generics helping programmers write better code?

The jury is still out, but in my opinion the future will look more like Ruby and less like Java or C#.

Re:All Roads Lead to Rome

[Tablizer]

Unworkable. Polymorphism and ifs/switches are SEVERAL ORDERS OF MAGNITUDE faster than database access. So it's better to keep them separated.

CPU speed is not always the bottleneck and RAM caching blurs the distinction to some extent. Beefier servers are usually cheaper than less productive programming tools, and will get more-so over time. Further, a table lookup is often already performend anyhow. (Of course, it depends on the domain.)

As for metaprogramming - you can look at Nemerle (http://nemerle.org/Main_Page) which excels at metaprogramming. It's one of the best languages I've seen.

Perhaps, but why deviate from the relational model when much of your data is already in a RDBMS? Mixing too many paradigms requires too much translating between them, plus the mental disconnect.

(And why was I modded "offtopic"?)

Re:C# compatibility? duh...

[SporkLand]

I guess my definition of backwards compatible isn't backwards compatible with yours.

Re:C# compatibility? duh...

[Pipelino]

No, YOU are wrong: target indicates that the bytecode will be compatible with the specified VM. In fact, there are many steps that have to be taken if you want to compile code that will run for a previous VM with a modern version of a Java compiler:

1. disable language unsupported features (generics, assertions can be compiled within a certain degree - enumerations can't) ;
2. compile against the libraries version of the target VM, otherwise even if the class files remain compatible, there may be calls to non-existent methods) ;
3. ensure yourself that all of your libraries will be compatible with that VM version (not as straightforward as it sounds)
4. Perform tests against the VM you're targeting, and if it's a desktop distributable application, against all VMs that came after that version ;
5. ??? I forgot.

In fact, in most projects that target an obsolete VM, it's much, much easier to get yourself the compiler for that VM, and code only on it. As an example, I'm currently running Eclipse on Java 6 VM, but since most work is still done on Java 1.4, or even 1.3, I keep most of those JDKs on my hard-drive..... In fact, I think this is one of the main reasons many people still code on Java 1.4 (as opposed to a MS pure environment, where most C# 1.2 projects translated into C# 2.0 when it appeared 2 years ago), even if it's really hard to imagine otherwise.... Sun could really have done a lot more to encourage Java development.

Duck typing requires

[Anonymous Coward]

a Duck Tape ribbon.

Re:C# compatibility? duh...

[omicronish]

Utter BS. I worked for a couple of years developing Win32 apps. We supported everything from 95 through to XP and I can assure you that there is NO FUCKING WAY that the OS runs the old binaries flawlessly!

But just recently I ran Civilization 1 and SimTower on Vista. Both are Windows 3.1-era games. All my other games from 95/2K/XP run flawlessly on later versions of Windows.

Re:All Roads Lead to Rome

[Anonymous Coward]

Unworkable. Polymorphism and ifs/switches are SEVERAL ORDERS OF MAGNITUDE faster than database access.

Unless of course if you happen to have a very fast DB like, say, an "in memory DB". In-memory DBs are hot since quite some time. Oracle is on a buying spree since a few years and has bought a few companies whose sole products were "in memory DBs".

It is not uncommon nowadays to have either in memory DBs or caching technology caching amount of data so huge that, in practice, they work like an in-memory DB.

For the GP slightly on crack, try to explain to a great many Java programmer who think that Java is an OO language (the jury is still out to see if it's possible to properly do OOP in a third-generation language like Java) that set theory is the way to go. OO and set theory are two quite different beasts and I don't see much love between these two anytime soon. But, like the GP, I'm all-in for "blurring the distinction between database and app" and this is already happening in the Java world: when you've got your whole DB in memory and super-fast lookup for most of your queries ("super-fast" as in "smoking any 'traditional' DB"), you tend to start thinking that the DB "on disk" (either a relational DB or an OO DB or monkeys writing down the infos with pencils) is a detail...

Now I don't say that set-theory is bad: it is mathematically sound... While what OO really is still a matter of debate. But my point is that "more or less OO language" like Java and C# are here to stay and they don't seem to show much love for traditional DBs. In other words, the DB world is adapting to these new kids on the block, not the other way round.

Re:C# compatibility? duh...

[Anonymous Coward]

Who marked this flamebait? It was answering a question about compatibility between generics and various versions of Java. Several other people made similar responses, none marked like this. WTF?

Features or Fixes

[v4vijayakumar]

Any features included to the language, after the first release, would hardly be called as features. They just are fixes for incomplete first release. Either language designers were not aware of these already existing features (obviously, this can not be true), or, they chose not to include those features to the language.

Re:C# compatibility? duh...

[HiThere]

It's been many years since I used an MS product, but my memory says that they were much better at promissing backwards compatibility than at delivering it. This may have improved.

In particular I am remembering MSAccess95/MSAccess2000, which they definitely advertised as being compatible. I ended up keeping two separate machines, one for each, with a different copy of the program on each. Changes, including data updates, were transmitted between the two as ASCII files, because if MSAccess2000 ever opened the MSAccess95 version (even when told not to save any changes) within a month the MSAccess95 version would become corrupt. The interesting thing is that it didn't happen immediately, which made it a real fun problem to trace down.

It was necessary to keep both versions running, because different clients had different versions, and they weren't about to spring for the $$$ to get a new computer just to run MSAccess2000. I never did get a straight answer about how to solve this problem out of MS, I had to figure it out myself. (Fortunately the program had been running for about a year before we bought a copy of MSAccess2000....so I had a strong hint as to where the problem lay.)

I also heard various horror stories about MSWord incompatibilities, but none of those ever affected me.

N.B.: As you can see, this all happened several years ago...around 2001. Things may well have improved. Perhaps.

badly designed

[nanosquid]

unlike generics in C#, maintaining backwards (and forwards) compatibility with existing Java code

As a consequence of Java's attempts to maintain backwards compatibility, Java generics are nearly useless. They fail to make your code statically type-safe, and they fail to make it run faster. Yet, despite failing to achieve the two primary purposes that generics have, they still make the language considerably more complex. In contrast, using generics in C# does give you extra type safety and extra performance compared to casting.

Re:C# compatibility? duh...

[neaorin]

If THIS is meant by 'backwards compatible' then someone needs to check their facts. I mean the 'unlike C#' part.

Re:C# compatibility? duh...

[neaorin]

Install both versions of the runtime (or demand their presence if you have no control over deployment).

And I have yet to come across C# v1 code which doesn't compile / run in 2.0, but I'd be interested in an example.

Re:C# compatibility? duh...

[bentcd]

(They skipped 3, 4 and 5 right?)
If only it were that simple. Presumably, Java 1.5 and 1.6 (also known as Java5 and Java6) are still Java 2 products. The Java 2 terminology appears to have been deprecated, however, once it became clear the Microsoft would not be pushing the Java angle anymore.
The "Java 2" term came into existence at about the time when Sun was having trouble with the Microsoft Java VM being deliberately incompatible (and in violation of contract). It appears to me that "Java 2" was the brand name Sun used to differentiate their own "real" Java from Microsoft's Java 1 VM. The "100% pure Java" effort was at about the same time.
So JVMs continued being called "Java 2" systems throughout 1.2, 1.3 and 1.4. I am not sure if it survived into 1.5 (aka 5) though. They may have discontinued it beforehand in order to avoid (further) confusion.
Java 1.5 became Java5 because Sun engineers seem completely immune to bumping major versions and the marketing people feel that "upgrade from Java 1.5 to Java 1.6" seems less compelling than "upgrade from Java 5 to Java 6".
So version-wise, Java skipped 2,3 and 4 (it went from 1.4 directly to 5.0), but system-wise(-ish) it went from 1 to 2 and then to nothing in particular since there's no pressing need to fight Microsoft on this particular battlefield anymore.

Re:C# compatibility? duh...

[kaffiene]

Wow, so that one datapoint completely disproves what I was saying!

Some old binaries work. That doesn't negate anything I said about developing apps to work across Win32 versions. Civ1 probably works well because it was written to use the system GUI support directly rather than doing anything funky.

I have dozens of apps that no longer work (Mechwarrior2 for Win95 is my most mourned OS-upgrade casualty)

Re:C# compatibility? duh...

[Anonymous Coward]

.NET compatability concerns don't really 'matter' between versions in the same way Java does. When Java talks about compatability, they're on about old programs breaking between versions. This just doesn't happen (or has failed to happen yet) with .NET. The CLR is able to run multiple concurrent instances of the various framework versions and even supports cross-communication between the application domains using various mechanisms. Every program from 1.1 compiles fine as a 2.0 (and thus a 3.0) program, the only difference is some new base class libraries (all backwards compatible) and a few warnings about deprecated methods. Your standard Windows PC these days probably has 4 versions installed (1.0, 1.1, 2.0 and 3.0) depending on how often the user updates (.NET installers tend to ask the user to install the latest versions during setup anyway).

A lot of my clients run a heavy mixture of 1.1, 2.0 applications because there's no need to worry about compatability issues like this at the present time. If 1.1 ever suddenly disappeared, we could move to 2.0 and likely not have to change a thing. Java is too worried about maintaining IL-compatability between versions and since most people can agree there's a lot of room for improvement it's hard to see why bytecode can't be version-targetted with a translator to on-the-fly upconvert older bytecode formats when executing. That way the newer code can take advantage of generics, the older code doesnt need changing and you'll only ever have problems if you try to use a new feature on an old platform.

Re:C# compatibility? duh...

[forgotten_my_nick]

As I point out again Generics will work on 1.4 as long as your 1.5 compiler compiles the code to support 1.4.

Generics will also work with 1.4 / 1.5 code working together. Also 1.4 code works fine in a 1.5 JVM.

The reason being again is because it is done at the compiler level and doesn't actually add anything to bytecode in relation to Generics.

C# probably does it differently or correctly (I don't use it).

Having earlier JVMs on your machine if you have Java6 is wasteful. You just tell the compiler/eclipse to act as if the code is 1.4/1.3 and it will handle it.

There is a third choice.

[master_p]

C# does not produce the generic versions of code until in the last moment...bytecode translation allows that. Assemblies contain the generic version of the code, so there is no bloat, and the code runs with maximum efficiency (in the context of C#) when translated to native code.

A PL is not mature until it is an OS!

[master_p]

There is an old saying that says "a programming language is not mature unless it as reached operating system status". That's what has happened to Java, which is on par with C++ in complexity.

I do not fully agree though that powerful APIs need to be complex. There are two examples that contradict this: the Qt library (very simple, yet the most powerful C++ library) and the Be Toolkit, which was very powerful as well and completely written in C++.

What happened to 'warnings are bad'?

[master_p]

There was a time where the IT industry kept buzzing about how wrong C/C++'s warnings are, and how they can introduce subtle bugs etc. Now that Java has warnings, are they good?

Re:C# compatibility? duh...

[tgv]

No, the parent is completely right. I too worked on code that had quite a few ifdefs to maintain compatibility across the different versions of Windows. Actually, since it ran as a DLL in Office, it also had ifdefs for different versions of Office.

Games are different beasts: quite a few of them only read the keyboard and the mouse events and show an image on screen. They interact very little with the OS. And they usually break down in the parts that are not play-related, such as starting up, self-updating, etc.

Re:C# compatibility? duh...

[Nurgled]

I think Microsoft saw the binary compatibility break between 1.1 and 2.0 as a necessary evil, and I agree with them. The .NET Framework was something very new for Microsoft, and they didn't get it quite right first time. 2.0 is a marked improvement that fixed almost all of the limitations of the platform, and opened the door to easier support of a wider variety of languages such as Python and F# in addition to enabling features like generics.

However, now that 2.0 is out there, I don't think Microsoft is eager to break binary compatibility again. The 3.0 "Framework" is really just a set of new class libraries on top of 2.0, which makes the install footprint for 3.0 a lot smaller amongst other things. The CLI is pretty mature as of 2.0, so I expect that only the CLR (the class libraries) will change for the forseeable future.

Re:C# compatibility? duh...

[petermgreen]

1.5 and 1.6 are still the version numbers used intenally afaict. java 5 and java 6 seem to be no less marketing names than java 2 (though it is a bit strange that they never used the names java 3 and java 4 but stick to java 2 for a few versions).

Re:C# compatibility? duh...

[e2d2]

yes, thats what it means to me to. So how is using a new feature, generics, backwards compatible? That was my original question.

I got the answer below though - you can compile using a new compiler that supports generics and then run them using an older VM because the bytecode is compatible.

It's just a confusing statement in the review. I wish Java freaks wouldn't jump the gun anytime a person questioned the language. Relax, you still have a job.

Re:C# compatibility? duh...

[godefroi]

So I decided to read the link in your sig. It's a good laugh.

1) Public Domain APIs - Right, MS is gonna sue me because I called a method they didn't want me to.
2) Standard Library Source Code Availability - You can get it through Rotor, or get the source to Mono.
3) dotNet Purity Is A Myth - Yeah, JNI doesn't exist.
4) 75% Of Enterprise Software Development - Something about statistics being made up on the spot?
6) Superior Platform for Web Development - Mmm hmm. LAMJ? Right.
7) Write Stored Procedures using Java - MS SQL Server lets one write sprocs, udfs, and triggers in any .NET language. One can write udfs for SQLite in any .NET language.
8) An Abundance of Experienced Practitioners - Noone knows how to write software for .NET, wtf?
9) Supportive Open Source Communities - No open source ever gets developed in any .NET language, right?
11) No Lizard Brain - What the hell does this even mean?
14) No Mandatory Upgrade Fees - Noone pays for .NET, they pay for Windows. If I run Java on Windows, am I paying mandatory upgrade fees for Java?

I could go on and on. There's strengths and weaknesses to any platform, but making ridiculous shit up does nothing good for your platform-of-choice's image.

Just a side note:

[warrax_666]

Interestingly laziness often makes Haskell code less efficent because of laziness. (TCO can end up forcing evaluation which isn't needed.)

In strict languages it's basically mandatory if you want to support functional programming styles (CSP, recursion instead of looping, etc.).

... and a correction.

[warrax_666]

Of course I meant

Interestingly writing tail call optimizable code often makes Haskell code less efficent because of laziness[...]

Re:C# compatibility? duh...

[fireboy1919]

Yeah...because I want to require people to run whichever version I compiled it with...I'm sure that's a good idea.

Totally how it works. You can (and should) write as much code as possible that'll work anywhere.
Then load the assemblies that are specific if you have to.

ZOS

[Anonymous Coward]

Please, name ONE other operating system out there that can claim to run decade-old binaries flawlessly in its most recent incarnation.

IBM's mainframe OS runs code from the '60's, methinks.

Re:C# compatibility? duh...

[omicronish]

Wow, so that one datapoint completely disproves what I was saying!

Actually, yes. You claimed there was no way the OS could run old binaries, and I disproved your claim with evidence that old binaries do run.

I can assure you that there is NO FUCKING WAY that the OS runs the old binaries flawlessly!

Re:C# compatibility? duh...

[kaffiene]

*sigh*

Go look up the term "polemic"

Re:C# compatibility? duh...

[kaffiene]

Wow, so that one datapoint completely disproves what I was saying!

Actually, yes. You claimed there was no way the OS could run old binaries, and I disproved your claim with evidence that old binaries do run.

I can assure you that there is NO FUCKING WAY that the OS runs the old binaries flawlessly!

No.

I was talking about the apps I worked on as a Win32 developer. I said that "there is NO FUCKING WAY that the OS runs the old binaries". Note the word "the" - meaning the specific apps I was talking about. I never said that the OS runs NO old binaries, just that the binaries we had didn't run without alteration between OS revisions.

If I'd meant what you claim I said, I'd have said "there is NO FUCKING WAY that the OS runs old binaries" - which I didn't say.

Which is why what you said has no relevance to my claim - which clearly, you didn't understand in the first place.

Re:C# compatibility? duh...

[SporkLand]

I guess my definition of troll isn't backwards compatible with yours.

Re:C# compatibility? duh...

[Pipelino]

You just tell the compiler/eclipse to act as if the code is 1.4/1.3 and it will handle it. Listen, I'm not trying at all to downplay you, nor to disallow your expertise. I have more than 3 years of professional experience in Java development, and I can tell you that sentence is just plain wrong. I know of all javac/Eclipse compiler options, and they aren't (and can't) be enough to cleanly compile code into previous VMs versions, period. In fact Eclipse has a nice feature that let's you target the right VM when you are compiling (among those installed in your system). Hell, I have even had troubles targeting JVM 1.4.0 from JVM 1.4.2 (the reason: at the time, new XML-related API and implementations override behavior from third-party libraries).
Trust me, you want to avoid hours and hours of debugging, however, if you still aren't convinced, I seriously advice you to try it and get back to this forum in a couple of years. Back to the main thread, C# did great in not having those "semi-backwards" compatibility issues: all of C# 2.0 new features are incompatible with previous CLR versions. Therefore, if you want to benefit from them, you have to adopt all of the new (by then) .Net 2.0 environment: Visual Studio 2005, CLR 2.0, compiler version 2.0, ASP .Net 2005, etc. All or nothing, which is why, by pure coincidence, Microsoft released all of those new things roughly a the same time.
Instead, Sun chose to release some backwards incompatible features, and the ones who are compatible, must be turned on with compiling options (and you must remember to turn off those that aren't) ; Sun released it's next three different IDEs (Netbeans, JSC, JSE) at months separated dates, and they featured different degrees of Java 5 support ; and last but not the least, if you find .Net version numbering difficult, just check the Java one.

Unedited Version

[andrew cooke]

No really exciting differences, but the text without Slashdot's edits (which removed links, sub-headings and a paragraph that explained what I was doing) can be found here.