Anders Hejlsberg: Java's generics implementation was based on a project originally called Pizza, which was done by Martin Odersky and others. Pizza was renamed GJ, then it turned into a JSR and ended up being adopted into the Java language. And this particular generics proposal had as a key design goal that it could run on an unmodified VM [Virtual Machine]. It is, of course, great that you don't have to modify your VM, but it also brings about a whole bunch of odd limitations. The limitations are not necessarily directly apparent, but you very quickly go, "Hmm, that's strange."

For example, with Java generics, you don't actually get any of the execution efficiency that I talked about, because when you compile a generic class in Java, the compiler takes away the type parameter and substitutes Object everywhere. So the compiled image for List<T> is like a List where you use the type Object everywhere. Of course, if you now try to make a List<int>, you get boxing of all the ints. So there's a bunch of overhead there. Furthermore, to keep the VM happy, the compiler actually has to insert all of the type casts you didn't write. If it's a List of Object and you're trying to treat those Objects as Customers, at some point the Objects must be cast to Customers to keep the verifier happy. And really all they're doing in their implementation is automatically inserting those type casts for you. So you get the syntactic sugar, or some of it at least, but you don't get any of the execution efficiency. So that's issue number one I have with Java's solution.

Issue number two, and I think this is probably an even bigger issue, is that because Java's generics implementation relies on erasure of the type parameter, when you get to runtime, you don't actually have a faithful representation of what you had at compile time. When you apply reflection to a generic List in Java, you can't tell what the List is a List of. It's just a List. Because you've lost the type information, any type of dynamic code-generation scenario, or reflection-based scenario, simply doesn't work. If there's one trend that's pretty clear to me, it's that there's more and more of that. And it just doesn't work, because you've lost the type information. Whereas in our implementation, all of that information is available. You can use reflection to get the System.Type for object List<T>. You cannot actually create an instance of it yet, because you don't know what T is. But then you can use reflection to get the System.Type for int. You can then ask reflection to please put these two together and create a List<int>, and you get another System.Type for List<int>. So representationally, anything you can do at compile time you can also do at runtime.

Issue number 3: for the first time in java's existence, bar primitives Object is not the all-encompassing root type; some Objects are more Objecty than others.

It is not possible to have arrays of generic types. Up until Java 5, apart from primitives, anything could go anywhere (and, in all critical cases, primitives could too)

What planet do the people behind this crap live on? Planet "I'm too stupid to know what an array is, so I don't care about not using them"? Or just "java was doing too well in the markeplace - let's screw it up, refuse to be runtime backwards compatible, and hopefully everyone will go use C# instead"?

Shrug. Since I'm still waiting for an answer to "what happened to the documentation for NIO?" I guess it's going to be at least another 5 years before we get any explanation for the mindless stupidity that went into deciding what would go into Java 5.

Up until Java 5, apart from primitives, anything could go anywhere (and, in all critical cases, primitives could too)

You can still NOT use generics with Java 5.

Quote

I guess it's going to be at least another 5 years before we get any explanation for the mindless stupidity that went into deciding what would go into Java 5.

I, for one, don't blame Sun for the current implementation. I'm sure that, like now that everyone is bitching about it, a few years back when the decision was being made the same people were pushing hard for not breaking anything in the VM and keeping strict backwards compatibility.

And that's why C# is probably going to take over everything. Because, well, it's Microsoft's pet and they're not afraid to move forward. I won't be surprised when I see C# running on a non-Microsoft console, long before Java does.

This is why I started writing an article on it. People who believe this are kidding themselves, and due for a nasty shock the first time they try to use an API that uses generics in signatures.

You don't get a choice: if your API's require a certain platform version, you have to upgrade to it, and use whatever new features they're using. Up until now, that hasn't been an issue in any case I can remember, except for a SLIGHT upset at being forced to use Collections.

However, the reasons to object to using collections are miniscule compared with the problems of generics, IMHO.

Quote

I, for one, don't blame Sun for the current implementation. I'm sure that, like now that everyone is bitching about it, a few years back when the decision was being made the same people were pushing hard for not breaking anything in the VM and keeping strict backwards compatibility.

No.

Sun refused to let us have any of the critically important language features (like regexps) for no other reason than that excuse.

Now they've not only broken with their own stricutres that held back java for many years, but done so in spectacular style, admitting something ugly, practically useless, and damaging to the language.

What really takes the piss is that they decided to make java 5 NOT RUNTIME BACKWARDS COMPATIBLE, even though - as Toby has proved - their excuses for not doing so were pretty hollow.

What is the ****ing point of including type erasure "so that java 5 code will run on old JVM's" (paraphrase), when the java 5 compiler is deliberately written to make it impossible to run java 5 code on old JVM's?

What is the ****ing point of including type erasure "so that java 5 code will run on old JVM's" (paraphrase), when the java 5 compiler is deliberately written to make it impossible to run java 5 code on old JVM's?

I don't think that's erasure's point. The point is that pre-5 code and post-5 code can work together on a Java *5.0* virtual machine (edit: even without re-compilation).

This of course implies that there's no reason anyone wouldn't want to move to a 5.0 VM (I mean runtime execution only, not compilation). And I don't think there is one, I hope we agree on this.

I don't know about you, but I was quite happy with the RegEX support. *shrug* :-)

Quote

Now they've not only broken with their own stricutres that held back java for many years, but done so in spectacular style, admitting something ugly, practically useless, and damaging to the language.

Perhaps that because the only way those features could be added was in an ugly and practically useless way? I was one of the many who lobbied against Generics, Autoboxing, and several other features that various OO dweebs "just couldn't live without". As if it was so hard to write some bloody damn code instead of using syntatic sugar.

Java was popular because it was simple. The only thing it ever needed were libraries to cover holes and continually build up the platform. But people couldn't leave well enough alone, and now we've got Java 5. Thanks guys.

Quote

What is the ****ing point of including type erasure "so that java 5 code will run on old JVM's" (paraphrase), when the java 5 compiler is deliberately written to make it impossible to run java 5 code on old JVM's?

As I understand it, it was originally Sun's intention to make the code fully backward compatible. However, they were told by the community at large that backward compatibility is not a big deal, so just get it in there. Sun listened, and now we're where we're at.

What is the ****ing point of including type erasure "so that java 5 code will run on old JVM's" (paraphrase), when the java 5 compiler is deliberately written to make it impossible to run java 5 code on old JVM's?

I've been wondering about that too - for a veeery loong time!

Quote

As I understand it, it was originally Sun's intention to make the code fully backward compatible. However, they were told by the community at large that backward compatibility is not a big deal, so just get it in there. Sun listened, and now we're where we're at.

Right, but why the hell didn't they fix the generic bugs then??? and speed up the implementation.

Right, but why the hell didn't they fix the generic bugs then??? and speed up the implementation.

I haven't had a chance to use Generics, so I can't really comment on the bugs. What I can comment on is that things were plenty fast enough without generics. Prior to generics, the HotSpot VM would take note of collections that only had one type of Object in them. As long as there was only one type of object, hotspot optimized away the cast. Once you added in some other type, the optimization was undone. My guess is that the addition of Generics destabilized that feature.

Everyone should really keep in mind that the JVM is a tremendously complex piece of software, and that Sun has limited resources. It's doubtful that any of us could do better without something nearing Sun's resources. Nonsense demands like generics and auto-boxing are not helping anything, but Sun is making the effort none the less.

So it would be nice if people would stop being so critical. Either deal with what exists, join a project like Blackdown to help improve the code, or tone down their complaints to helpful suggestions.

I don't know about you, but I was quite happy with the RegEX support. *shrug* :-)

Perhaps it wasn't obvious, even with the original context: I was referring to the many years where Sun refused to allow regexps into the language. I was using them for years via 3rd party libs that there was seemingly no good reason not to have in the language - no syntax changes required, no mangling involved, a pretty standard expected feature of any programming language, and commonly used all over the place in programming.

Then they go and put in trash that mangles the syntax, makes a mess of the language itself (c.f. arrays), has practically no use at all, has no basis for its existence in tried and tested langauges elsewhere, *and* is deeply unpopular.

We're not talking about a minor change of direction here, but a full-on turn-around-and-spit-in-your-face revolution.

So it would be nice if people would stop being so critical. Either deal with what exists, join a project like Blackdown to help improve the code, or tone down their complaints to helpful suggestions.

You're being incredibly biased towards Sun here, conveniently ignoring the one major factor that is the cause of so much ire: Sun owns Java, and we are *forced* to suffer if they do not take their ownership seriously, or exercise it in stupid ways.

Don't give me the "take it or leave it" talk; I've had enough of that to last me a lifetime from open-source developers using it as a *justification* for making their software crap (fx: whiny voice: "No-one's going to shoot you if don't use it. You don't HAVE to use it. I don't care about you. Go away"). Responsibility is not something you get to take or leave at your leisure: once gained, it's there whether you like it or not. Sun has a huge responsibility towards java, and java 5 gives the worrying impression that, deep down, they couldn't give a rats's arse - they will do whatever the hell they feel like, despite the obvious and inherent wrongness of it.

I know Sun is legendary for ignoring both it's customers and the market (c.f. the Solarisx86 fiasco. Yes, I'm still waiting (4 years and counting) for my copy of Solarisx86), but I really thought that things were different with java. I believe they were, but it looks like the last vestiges of those with some sense and care in managing java have vested their options and retired / moved on to more lucrative jobs elsewhere. It's the classic pattern of paradigm-shifting software: the inventors get rich, and sooner or later hand over to a bunch of *-nuts who don't quite knwo what to do with it, and it degenerates into a total mess.

For people with long enough memories, the big question now is: is it even worth the risk of using java any more, given the near certainty that this is the end? The same patten happens again and again, and each time you hang on in there saying to yourself "maybe this time a company will pull out" you simply set yourself up to be thoroughly buggered in a few years time, when you're locked-in to a platofmr that has no escape path and is self destructing.

I've joined the crowd who are investigating the cost and side-effects of retraining into C# - even though it's something I never expected to do (why would I want that? - I used to say - it's got nothing significantly improved enough over java to justify switching).

Perhaps it wasn't obvious, even with the original context: I was referring to the many years where Sun refused to allow regexps into the language. I was using them for years via 3rd party libs that there was seemingly no good reason not to have in the language - no syntax changes required, no mangling involved, a pretty standard expected feature of any programming language, and commonly used all over the place in programming.

Quite a few people were doing the same. I actually was forced to use a piss poor excuse for a RegEx library (*cough*Blue Martini*cough*) around that time, but it worked. I can't say Sun was really ignoring people as much as didn't get around to adding it. Their release of Java 2 made a mess of Java, and they had to focus heavily on 1.3 to clean it up. The result was that regexs ended up getting slated for 1.4.

Quote

Then they go and put in trash that mangles the syntax, makes a mess of the language itself (c.f. arrays), has practically no use at all, has no basis for its existence in tried and tested langauges elsewhere, *and* is deeply unpopular.

What's wrong with the current RegEx libs? You have the choice of using the String methods I demonstrated, or you can use the java.util.regex package. AFAIK, the regex lib follows the "spec" as close as possible. Most of the things it doesn't implement are very PERL specific code constructs.

I rather like java.util.regex.*. I suspect I have found *one* bug once in it, which is good going considering how much I've used the package, and even that one bug I couldn't be absolutely sure of (it was in a long string with 40+ special chars in, so just trying to calculate the state engine required lots of pen and paper work) and didn't bother trying to narrow down,since it was probably just user error anyway.

I especially like the documentation for Pattern. Although it could *certainly* be significantly better (that would make it "excellent") - several conditions are left undefined, I think because the author ran out of energy and/or wasn't aggresive enough in their use of regex and didn't realise some of the questions that come up often (um, stuff like... how to OR groups of chars as opposed to individual chars isn't explained ever, IIRC). But at least 90% of cases are covered in more than sufficient detail.

What kind of hack job is this? Why couldn't Sun delay Java 5 for a little bit longer so they can get a real implementation of generics.

No amount of delay could provide the implementation you would prefer. What that would require is a change in the requirements set out when JSR-14 was first created. So where were you then?Did you respond to the public review of JSR-14?Do you know about the attempts to extend generics to work fully with arrays (and why that didn't appear in the final version)?

No amount of delay could provide the implementation you would prefer. What that would require is a change in the requirements set out when JSR-14 was first created. So where were you then?Did you respond to the public review of JSR-14?Do you know about the attempts to extend generics to work fully with arrays (and why that didn't appear in the final version)?

Whoops. I forgot about that.

It still doesn't change the fact that if Java continues it's current path it will be replaced by languages like C#.

I've joined the crowd who are investigating the cost and side-effects of retraining into C# - even though it's something I never expected to do (why would I want that? - I used to say - it's got nothing significantly improved enough over java to justify switching).

Aye, as soon as I've finished Quix I'm going to take a while and check out the alternatives. Currently on my list are: D, Nice, Blitz and C#.

So if you didn't respond to JSR-14 you're not allowed to complain ?What if I started with Java 3 months ago ?

Just because there is an option to comment on some proceedings, doesn't mean that they should do a piss poor job, and rely on people to tell them when they're doing something foolish.

That's not what happened. No one did a piss poor job. It was done this way because the Java community specifically *asked* for it. If we are to blame Sun for generics, we should be blaming all these too:

Yes, that's what we should be doing. I like the feature as it is now (blah^3: generics are not completely practically useless), but we know it could be improved in the future (dump erasure? does anyone know if that's a viable possibility?).

The system also has additional goals. Goals are different from constraints. Whereas all constraints must be met, it may not be possible to meet all the goals. Goals may be traded off against each other, or may be abandoned because they contradict constraints. No priority is implied by the ordering of the goals.

So if you didn't respond to JSR-14 you're not allowed to complain ?What if I started with Java 3 months ago ?

No you can complain, but you need to understand where your complaint should be directed. It should not be directed at people like Neal Gafter who have done a very good job of implementing generics subject to the constraints and goals they were given. In essence the "Java Community" has got what they asked for.

I do not believe that Sun could realistically introduced generics in the way that Microsoft has done for C#. That is the constraints in JSR-14 reflect what the "Java community" (i.e. IBM, Apple, etc as well as Sun) was willing to accept in terms of compatibility with existing code.

Yes, Microsoft does make changes that do not provide "migration compatibility", and much cursed they are for doing so. Yet they know they will not lose too many developers as a result. This is a strength that Sun does not have (in my opinion).

EDIT: I happily accept that my view on this topic is, perhaps, reactionary, and that other people have quite different views on Generics. The only concerns I have are that many people don't yet appreciate what a blow to the head G is, and that I can't seem to find a way to use java 5 without exposing myself to G madness as soon as someone else decides to give in and use Gs in their supporting code for anything I work on.

...and that it's a very very bad sign for the future of Java. If Sun takes their responsibilities this lightly...

If, for instance, Sun does a volte-face and actually removes or replaces G completely in the near future with something that is NOT runtime compatible (might be compile-time compatible) and actually provides generic types in java (which G definitely does not do), then I'll be first in line to congratulate and cry "catastrophe averted". Microsoft does exactly this kind of thing: recognizes the really big mistakes, and no matter the cost, attempts to turn everything around - sometimes even the entire company - just to fix them. Obviously they don't do it all the time, or people wouldn't complain about windows so much , but at the moment I'm wondering whetehr Sun even has that mindset. They didn't used to, but in recent yeasr appear to have started dabbling in this approach (once again, c.f. Solaris x86. That's a pretty mega U-turn)

Quote

That's not what happened. No one did a piss poor job.

I appreciate your point, but still disagree. It is about responsibility and "group think". NO-ONE gets to absolve themself of responsbility for their own mistakes "because everyone else in the group went for it". This is the classic excuse used in the public sector to justify the horrendous stupidity and/or cowardice on catastrophe projects; if someone took responsbility, they would have kicked up a huge fuss, saying "this is ridiculous; we cannot possibly take this **** to market".

Quote

It was done this way because the Java community specifically *asked* for it. If we are to blame Sun for generics, we should be blaming all these too:

Fair enough. There's a lot of people listed that - from personal experience of their organizations - I wouldn't trust in a million years to make decisions about the future of a programming language.

EDIT: next sentence doesn't read as intended. What I meant was that *to date* the AF has nothing to be proud of. Many of their projects (maybe most - I haven't tried them all) are going in very good directions for the future. Perhaps, one day, they will finish something, in which case it will be good. They have an awful lot of projects that "could be excellent if anyone ever finishes them", but somewhat make fools of themselves by "constantly re-inventing from scratch" and avoiding re-using existing stuff that would save them time when they have this history of not completing.

Why the hell is anyone, for instance, saying that a vote from the Apache Foundation (makes free software historically of extremely poor quality historically re-inventing the wheel over and over again, often badly, and famous for ownership of the world's slowest web-server) should even be listened to when deciding the future direction of something like java? I use a lot of AF projects, and none of them are complete, none of them work properly (even the simplest of those I use have had hiatuses of more than a year where no-one released anything even though they knew the things didn't work).

Shrug. Just looks to me *excatly* like another pattern thats common in the IT industry: at some point, the large corporate who owns a tech gives up control to the whims of customers / vendors, and the product sinks into depravity. Look at all the designed-by-committee howlers of the 1990's.

Quote

Yes, that's what we should be doing. I like the feature as it is now (blah^3: generics are not completely practically useless)

I've still not found anyone who has a cogent argument that they are anything more than a fix for a problem with Collections that made them look stupid to advanced programmers with wide experience of mainstream languages.

This was Eckel's conclusion, eventually: that most of his frustration came from erroneously thinking it was meant to be any more than that. (although, given how fluid his opinions seem to be, he's probably changed his mind again by now )

If you look at what works and what doesn't, and weigh the pros and cons and costs, I honestly can't see how you're going to gain benefit from then other than "seeming visually to fix Collections" and/or "reduce the number of typecasts you type in your source code".

if someone took responsbility, they would have kicked up a huge fuss, saying "this is ridiculous; we cannot possibly take this **** to market".

I would have certainly loved that, but wouldn't that make Sun a Microsoft then? People in this forum are developing games, they could have easily moved to a non-erasure implementation, but what about all the big companies? I can't imagine the mess it would produce.

Don't get me wrong, I don't like what happened, I just can say that I understand it. And I still admire the Java platform and hope that generics will be "fixed" in a future version of the Java language (when everyone will be using them), or at least wait for another language to take its place (that runs on the platform - not C#).

Quote

I honestly can't see how you're going to gain benefit from then other than "seeming visually to fix Collections" and/or "reduce the number of typecasts you type in your source code".

Well, I happen to be a clean code freak! And from what I'm seeing every day, our code is considerably cleaner with 5.0. Generics and stuff like the Iterable interface (one of the best API additions) are making a huge difference. I also happen to dislike Collections (e.g., too many object creation all over the place), I'm using my own implementations.

The code clean-up alone is a big plus. More readability, less typing, less bugs, less time. People are saying that Java became too complex with generics, but I'm seeing the exactly opposite. OK, it's specification may be more complex (more difficult for new people), but the Java *code* is simpler than it ever was.

The other important feature is, of course, reinforced compile time type checking. Especially with type constraints you can do many interesting things.

My biggest gripe is not being able to use primitive types. As for arrays, I've never needed that feature so far.

I can't seem to find a way to use java 5 without exposing myself to G madness as soon as someone else decides to give in and use Gs in their supporting code for anything I work on.

But that's exactly why erasure was chosen. For situations like this. You could move to generics, a library's implementor could move to generics, both of you could move to generics, but no matter what, the result would compile and run.

Well, I happen to be a clean code freak! And from what I'm seeing every day, our code is considerably cleaner with 5.0. Generics and stuff like the Iterable interface (one of the best API additions) are making a huge difference. I also happen to dislike Collections (e.g., too many object creation all over the place), I'm using my own implementations.

Howabout doing one of the first JGF opinion pieces on it ? You would need to go into considerable detail of what, precisely, you were seeing as differences, with before/after code snippets from real code, but as an opinion piece could have considerable leeway in being less-than-diligent. I guess as long as you don't try and conclude anything, it would be fine - people will get the implications of whatever conclusions you have, but it should not be written as a research-towards-making-a-conclusion piece.

Unless you have the time and energy to do a diligent detailed article on it instead.

PS: I'd be interested to see how G has any effect on amount of object creation from Collections

PPS: why do you care about object creation? Isn't it almost impossible to make it a bottleneck, unless you're doing something very unusual.

Sure, but I can't guarantee time of delivery . Send me the details (just generics or for other code-cleaning 5.0 features too?, etc) and I'll see what I can do. (spasi at zdimensions.gr)

Quote

PS: I'd be interested to see how G has any effect on amount of object creation from Collections

I don't think generics affect object creation in any way.

Quote

PPS: why do you care about object creation? Isn't it almost impossible to make it a bottleneck, unless you're doing something very unusual.

Well, I've had some nasty experiences with garbage collection in the past and I want to be sure that I'll not have again. I know of the better gcing in recent VMs, but I'm too used to my stuff right now .

Anyway, the implementations I use are "optimized" for game developing (always single-threaded), which means no synchronization and no things like creating a new iterator object each time.

Well, finally we found the ultimate reason why there are just a fistful of Java games. (I knew there had to be one.)It's all so simple. If somethings doesn't fit my fisheye perspective, it's bad.I think we're so smart. Too smart to be smart. ;-)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org