[quote]I’m just deeply unhappy that it a) can’t take primitives b) can’t be used with arrays and c) erases the type information under the hood, making whole classes of optimization impossible 
Cas 
[/quote]
Agreed re: (a) and (b), especially. Practically I find that using the tech is very valuable for typing collections, but it is kinda crap that they’ve been so poorly implemented.
When I first heard about generics, I thought great, now I can have collections containing primitives… but no!
[quote]But maybe they think we should use autoboxing instead, which is one of the worst features of Java 1.5. It is very seldom useful, will create many strange bugs and the performance and memory usage sucks compared to using special collection classes for primitive types.
[/quote]
Yeah, I did some C# programming and that was my experience as well - autoboxing is a crap “feature” because it effectively weakens typing.
[quote]I know an awful lot about compilers
[/quote]
Ditto (having written half a dozen decent compilers, and having been beaten to death with the dragon book at Uni whilst specializing in Compilers).
I think the reasons for the current implementation are less to do with implementation practicalities than with political reasons, in much the same way as the seemingly strange decisions about the Logging API etc - from a technical POV. When you start mixing in politics it becomes much easier to rationalize.
Excellent point. I’m sure there’s a workaround using covariance, but:
IMHO a true OOP language needs covariant types, so I’m surprised Sun has made such a small thing out of them ??? Sadly, I’m really rusty on this topic and need to go revise it again…
I think Sun just want us to pretend that primitives don’t exist and use them in very restrict ways. Since Java primitives are not real objects, just like C++ primitive types. Also Java troubles come form being mixed OO so its natural they get a lot of troubles from that mixing that do not happen in pure OO langs. Still i prefer Java generics to C++ generics which mix everything.
I don’t know about having generics that force typechecking at run-time. Maybe they could just do two types of generics like, mormal typed generics:
List list;
and dynamic run-time generics with a different syntax like:
List<> list;
Incidentally, I haven’t heard much about the enums introduced with 1.5. Is that because they gasp actually work as expected? With the amount of state-machine-esque code knocking around in game logic I’m surprised people havn’t been more interested in them.
Well… colour me ignorant! What is convariance?
(ps. i’ve written several compilers as well - I usually keep making LISP variants ;o) I’m a fan of flex and bison but recently have discovered the joys of ANTLR - a great tool for you Java-ophile compiler writers ;o) )
[quote]1. Sun have stated that they are considering making that (“raw types”) illegal syntax in the long-term (perhaps java 6?)
[/quote]
Why?! ???
I have things like
List list = new ArrayList();
all over the place. It makes sense to me if I can choose to use another implementation of List (like my own) whenever I choose to.
Live chat: New Language Features in J2SE 5.0
SUN folks: Scott Seligman, Joe Darcy, and Peter von der Ahé
Oct. 12. 11:00 A.M. PDT/6:00 P.M. UTC
You will be able to write
List = new ArrayList();
And replace ArrayList by MyOwnCollectionClass at some point in future. Only thing which can be deprecated is using List instead of List. Raw type means here type not specialized in ‘generics’ meaning (instead of not being specialized in ‘inheritance/implementation’ meaning as you think).
I have followed the progress of JSR-14 quite closely. In my opinion, given the constraint of backward compatibility with all that code out there, Sun’s engineers have done a remarkably good job.
There is scope for addressing some (or even all) of the problems in future revisions.
At one point the proposal did extend type safety to generic arrays, but the language concepts introduced to manage that left many bemused. So the the simpler concept of wild cards was invented, and unfortunately the question of arrays had to be put off for future work.
Most commentators seem to have missed the fact that generics does bring one potential performance improvement — covariant returns. Covariant returns are not just a compile time transformation; in the JVM the method signature has always included the return type.
Most developers will simply use generic classes designed by others (mostly collections). This should cause few problems and have many benefits in terms of more comprehensible code. Developers implementing their own collections can just use the provided examples as a ‘template’ and should also have little difficulty. That leaves a very small number who need to investigate the shady corners of generics; well they will just have to get learning.
Those who think Java generics in j2se5 should have gone much further are simply dreaming. I think the current change is probably about as much as the Java community as a whole is able to accept (and there are quite a few who think it is a step too far as it is). OK, so the refuseniks and luddites are always with us (more so as a number of Java fans are escapees from C++ template and overloading nightmares).
Great article. Very constructive and informative. I love it. Thanks Mark.
[quote]I have followed the progress of JSR-14 quite closely. In my opinion, given the constraint of backward compatibility with all that code out there, Sun’s engineers have done a remarkably good job.
[/quote]
Care to highlight any particular examples? I’m still confused by the fact that 1.5 has NO “-source 1.5 -target 1.4” combination - it seems that on the one hand we’re told generics is this way “to provide backward compatiblity” yet the compiler itself refuses to allow you to compile backwards-compatible code !!!
If you can’t run the classfiles on older VM’s, what is the point of making the changes compiler-only ???
We have this situation repeatedly appearing where people have compiled on 1.5 and posted their game on this board and it just fails to run on most people’s machines because it’s default -target 1.5 and has produced non-usable classfiles.
c.f. the long debate 6 months back about whether JCP/Sun would ever take advantage of that possibility, e.g. by changing the bytecode in future to reflect the new language syntax. ISTR there wasn’t much cause for hope that it would actually happen.
If there are some public comments about anyone’s intent to address these concerns in future I’d love to see them (where “anyone” means someone with enough clout to matter - e.g. a large corporate JCP member, or Sun staff, etc).
But…it leaves me wondering why such major changes (syntax changes) were pushed through with outstanding problems - is it just me, or does this mark a major change in java’s direction? (nb: there has been much talk from Sun about how 1.5/5 marks a major change in direction, c.f. their new release strategies, but they don’t seem to have said much about this aspect, the seeming relaxation of the determination not to make large changes without very good reason)
That is a different form of backward compatibility. The constraint was that old code would run on the new JVM, not that new code would run on old JVMs. In practice the generics stuff is almost able to run on old JVMs (see Toby Ryelt’s tool). It is the other language changes (enums, enhanced for loops) that don’t work well (or at all) on older VMs. They didn’t want to subdivide the source 1.5 option so that you could say “source 1.5 except for enum, for” and target 1.4. In other words the source option is an all or nothing choice. The bits of generics which don’t work on older JVM are obtaining reflective access to generic information about a class (note you can’t obtain the actual Type values for a particular instance).
One point of minimising the JVM changes is that other JVM writers can easily bring their JVM from 1.4 to 1.5 level.
Similar problems have occured with several previous major releases.
I think the maintenance and clarity advantages of generics do constitute a very good reason.
[quote]Bruce Eckels has a much shorter commentary, dwelling on far fewer of the problems, here:
http://mindview.net/WebLog/log-0050
that concludes:
only solve the problem of automatically casting in and out of containers
[/quote]
Perhaps that is 90% of the problems addressable by generics (counting over general applications)? The perfect solution will have to wait (C# isn’t perfect either).
Why does java.util.Properties extend Hashtable<Object, Object> and not Hashtable<String, String> as you might expect? Well it seems that some people put objects in to Properties which aren’t String’s — there are apparently examples of this within the core libraries.
Sure, but that’s one of things I lump into “political reasons” - it’s not for end-users and it’s not for technical superiority (although indirectly it can affect both - which is often true of political reasons).
I remember them happening during betas, and then being “fixed” in time for release? My memories back beyond about 1.3 are vague because until then I always upgraded automatically (so many critical bugfixes!) and it seemed almost everyone else did too.
But it’s all relative…for instance, it seems to me that structs would provide greater advantage in more situations with less change to the language (syntax) - yet they seem to be held back largely because they require “too much” of a change. (this may be unfair, it may be only true of non-sun staff, but I’m just laying my thoughts on the table here - this is how it seems to me).
And other things that would have a much wider and greater beneficial effect on java - for instance true (or even semi-true) contracts. Or aspects…
Not that I’m saying “we should have ALL of these” but they are all things that people have been clamouring for for ages, have good reasons for needing, and every single one of them seems considerably more useful than generics and to require considerably less change to the existing java language! And all of them have reference implementations of one sort or another that are quite stable (for reference implementations) with people offering to donate these references as a base for Sun or JCP to build an better implementation on top of.
IMHO, this is a large part of why it leaves a sour taste in the mouths of many java developers - there’s a sense that the users of the platform are being screwed over / left out in the cold / manipulated by “the powers that be” with “improvements” that few want whilst being denied much more powerful and useful improvements with less reasoning.
Anyway, I’m still wavering on this whole topic - hence starting the thread. I’m just keen to find out what other people think and to expose myself to some wildly different opinions on this :). But I admit the weight of evidence has me leaning towards “== bad for java”.
Generics is something that has been hanging around as unfinished business for a long time — far longer than many of the other changes you suggest (since the very genesis of Java in fact). Politically of course there is the fact that the C# version of generics has also appeared (and this doubtless was the inspiration for some of the other changes).
Static type safety without generics is something of a half baked cake. Nevertheless pragmatically many will be happy without it (never know what they are missing?). Language theologists (Gilad Bracha), on the other hand, strongly feel the need to complete the job. <fx: insert suitable Monty Python reference here>
In his original RFE for structs, Cas has conflated two issues (which in my opinion should be separate): his need for objects that efficiently map directly to external structures, and a more general desire for lightweight classes. There is as yet no real consensus on how these two issues should be resolved.
[quote]Well it seems that some people put objects in to Properties which aren’t String’s — there are apparently examples of this within the core libraries.
[/quote]
Just because they do it, doesn’t mean they shouldn’t be flayed alive for it…
Nah… you are allowed to put anything into it. You won’t be able to save it to a properties file anymore - that’s the only price you had to pay for doing so.