More Haskell in Java 7 or 8?

An interesting blog post from Ralf Lammel which may raise some reactions...

The post refers to the paper JavaGI: Generalized Interfaces for Java (Stefan Wehr and Ralf Lammel and Peter Thiemann). Here's a teaser:

generalized interfaces cater for retroactive and conditional interface implementations, binary methods, static methods, default methods, interfaces over families of types, and existential quantification for interface-bounded types. As a result, many anticipatory uses of design patterns such as Adapter, Factory and Visitor become obsolete...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

JavaGi is the bee's knees

+1 to any effort to improve Java's orthogonality and extensibility, specially if it leverages my knowledge of Haskell's type system ;)

It's interesting to see how they fit this type-classish mechanism (almost) seamlessly into Java and apply it to the [in]famous expression problem. Until this paper I had lost hope for a saner type system for Java (with the current closure madness going around Java bloggers).

Cool, but what about Java 7 or 8?

I agree that this looks promising for those of us who use Java,
but I didn't see anything that suggested that this will make it
into a future version. Something like this will need to have a
champion who wields clout in the Sun world, and would be helped by
a reference implementation.

In other words, very cool, but don't get too excited.

Something like this will

Something like this will need to have a champion who wields clout in the Sun world

I agree. The interesting/weird thing about the blogger (and co-author) is that he works for Microsoft.

So C# gets it and then Java

So C# gets it and then Java follows in half a year...</cynicism>

Re: So C# gets it and then Java

Another interesting tidbit from the blog post: "I couldn’t find anyone who wanted to work with me on this topic for C#; too bad"

A lot (probably not all, but

Doesn't Nice already do most of this? A lot (probably not all, but I'll need to read the paper further and think fairly hard about some of the ins and outs of the Nice approach) of the examples seem like things which Nice can already do more elegantly, with the way its abstract interfaces and multimethods work.

Of course, Nice manages this by being very emphatically not a conservative extension of Java. JavaGI still looks fairly neat, and has a better chance of some of its features being bolted on... err elegantly incorporated into to Java.

Poor man's type classes

See the following talk for an alternative embedding of type classes in Java-like languages:

Poor Man's Type Classes
Martin Odersly
July 2006

It's of course not upwards compatible with Java, but it provides
type-class like behavior at very low conceptual overhead. It's all available today, as part of the Scala release.

Nice and others

When was the last Nice release? Three years ago? I can't say for sure,
but I suspect that the level of activity around the Nice compiler
is so small that it using it at work would be foolhardy. Yes, I
think multimethods are great and they also remove the need for
Visitor, like the extended interfaces of JavaGI. Too bad Dylan never
took off.

Right now, it looks like Scala is the best bet for a JVM based,
interoperable-with-Java new language. And I'd love it if JavaGI
or something like it were Java 7 or 8, but without a reference
implementation or a Sun connected promoter, it doesn't look promising.
Perhaps Ralf Lammel knows someone associated with Java and he can
push the idea there?


Don't forget Quark.

There's actually a moderate

There's actually a moderate level of background activity on the Nice compiler still ongoing (the last release was just under a year ago). Not as much as I'd like, but it's there. Hopefully it might be picking up in the next year, but no guarantees. (And sure, Scala is probably the best bet at the moment. But I have a history of backing the underdog. :-) ).

Still, the above wasn't a "You should use Nice!" plug. I was just pointing out that most of what JavaGI does can be and has been achieved without abandoning the subtyping based interfaces.

Isn't that the same with structural subtyping?

I haven't read all the details, but it seems like JavaGI is like structural subtyping: design the classes without dependencies on interfaces, then design wrappers around them which invoke the implementations on a per need basis.

This type of typing is more flexible because the type relations are not hardcoded: any implementation can become a type, as long as it statically fulfills a contract.