Lambda the Ultimate

...I suppose, to breaking in expected ways. :-)

...there are many reasons why controlled failure (an exception being thrown by a downcast, instanceof returning false) is preferable to uncontrolled failure (what you get with many typecasts in C/C++).

Of course, I'm sure you know that already. :)

In some applications, of course, neither form of failure is acceptable. In other applications (including the sorts of things Java is frequently used for), controlled failure is perfectly acceptable behavior.

At any rate, I'd be interested in what this paper has to say. At first blush, I'm a bit puzzled how generics manage to break the Java type system, as typechecks which are not statically proveable (and checkable by the bytecode verifier) are dynamically checked by the JVM. (The JVM is designed that ALL Java bytecode passed to it is either proven to be typesafe, or rejected outright; it is designed to defend against hostile compilers--a more difficult challenge than defending against merely incorrect ones).

On the other hand, the Java library contains many classes with intimate under-the-cover relations with the JVM. Some of them are straightforward (like String and [] arrays), but others (classes having to do with weak references, and possibly lots of introspection-related stuff) I could see causing problems if not implemented correctly. Perhaps a flawed extension of one of these is causing problems, and the flaw is inherent in the design of Java 5 (rather than being a bug in some Java environment)...

And, the word "uncontrolled" in this context might need clarification. I've been assuming "undefined behavior", but perhaps what the author really means is "an exception occurring in a context were the programmer might not expect it." One expects a ?= b to possibly return an exception; one doesn't expect a = b to do so.

Parametric polymorphism for Java: is there any hope in sight? (ppt slides)

Parametric polymorphism for Java: is there any hope in sight?

The powerpoint link doesn't appear to work...

fixed

it appears my last thought above was correct. The "uncontrolled" behavior appears to be exceptions where the user doesn't expect them, not anything which causes the JVM to exhibit undefined behavior (or would otherwise compromise the security features of the Java platform).

While disturbing, not as ominous as one might suspect from the title of the presentation.

It is widely known that generics in Java are implemented by type erasure. The choice for allowing raw types and unchecked conversions has been discussed at length as well. So, I really don't get why this is news and why this is presented as being shocking at a gathering of researchers who are expected to discuss the state of the art and recent developments. Serious, anyone with decent knowledge on parameterized types could have given this talk about 3 years ago.

But, maybe I'm all wrong: apparently, people are still surprised if you show them examples of how generics are just a facade for plain good old Java. I don't want to offend the presenter, but I would like to stress that this is nothing new and that no horrible leak has been uncovered in this presentation.

It would be great if someone in the know would clarify.

Can't say I'm in the know, but my impression is that as long as you play strictly within the rules (you do NOT perform certain kinds of casts), your Java program is guaranteed to be type-safe.

I've been trying to implement a type-preserving stream library for Java, and have run afoul of the "invisi-cast" problem that results from irresponsible casting. The problem is, there's no _responsible_ way to do what I want to do.

I have generic methods (drop, where, sort, etc) that I want to be able to call in chains (.first(5).where(Name.Equals("Ross").sort(), but I also want to be able to create subclasses of my basic stream types and extend them. My interface def looks something like this:

public interface Stream<IN, OUT, OP extends Stream<?, OUT, OP>>
extends
Iterable<OUT>,
StreamInternal<IN, OUT, OP>,
Begin<IN, OP>
{
/** Dump the contents of the stream to the display.
*
* @return
*/
OP dump(String header);
OP trace(String header);
OP execute();
<K> Stream<K, OUT, OP> end(Pipeline<K> pipeline);

So to get around the absence of virtual types I implement a sneaky clone operator with casts. The difficulty I have with erasure is that whenever the erasure boundary is transitioned at runtime invisible cast operations are inserted by the Java compiler. These cause your code to fail at points where it doesn't look like anything is going on...This is obviously a consequence of breaking the rule, but the language doesn't really give you any other way to get around the problem (that I can think of, at any rate).

I just found this nice flame on the weblog of Peter Ahé. He doesn't seem to like the work of Dr. Suad Alagic ;) .

Btw, the position of Peter Ahé is quite interesting, since it resulted from quite a unique collaboration between Sun and researchers from the University of Aarhus (Denmark). Peter Ahé and his Danish colleagues contributed to the new wildcard feature of Java, which was described in the paper Adding Wildcards to the Java Programming Language. Apparently, Sun liked their work so much that they immediately hired Peter after finishing his Master's Thesis. As far as I can see from the outside, Peter is now the new main developer of the Java compiler at Sun (was Neal Gafter, who left for Google). Amazing!

I think the wildcard paper is a very interesting read and wrote a bit about it here. It has been covered before at classic LtU, but that thread wasn't very successful at the time. I think it deserves more attention.

That may be an entertaining flame, and Alagic may express himself in controversial and unneccsarily combative ways (he certainly did at IBM PL day), but he happens to be right. Java 5 can cause expressions without casts to produce ClassCastExceptions. That's an invariant that every other java version preserved, now broken. And the place where the exception is thrown is *not* the incorrect code.

Also note that code compiled for JVM 1.4 will not run on JVM 1.5, since there's a version check. So since *they* broke backward compatibility for no reason at all, it seems like breaking type safety would be a good reason to fix the issue.