Scala 2.6.2 getting support for Java generics

Scala is a far superior language to Java. In fact, of all the languages that I have investigated, it is the most powerful language that also targets the JVM and Java libraries easily (sorry CAL). I have long held the position that there are no (with one corner case) rational justifications for using the Java programming language for anything but educating our children on how not to design a programming language even when targetting legacy code. This has of course, been met with ‘what about this?’ and ‘what about that?’[1] all of which I have been able to refute, except for one niggling corner case.

Client code of existing Java-compiled code would not receive the benefits of generics, since they were erased. For example, if you were to call a Java-compiled method that returned a List<Integer> from Scala, you’d have a reference to java.util.List without the type argument. If you were to call this method from Java, then many methods on the returned List would return Integer in place of the type argument, however, for Scala, you’d have a type AnyRef (an alias for java.lang.Object) just like Java did in the pre-1.5 days. This gave Java one (and only one) case where its use was an improvement over the use of Scala.

This has been the only remaining use case where Scala does not match or exceed Java in ability, however, Martin Odersky (creator of Scala) has revealed that the next version of Scala is to do away with this limitation! Furthermore, we can use the feature today! That is, we can start moving over any Scala <= 2.6.1 code to 2.6.2 right now and have the full advantages of a powerful language and do away with Java forever, unless of course, you're still out there appeasing the irrationalities of the suits (you poor buggers, no really, I mean it).

From Martin on the Scala mailing list:

Just to confirm:

The nightly build of Scala contains now support for Java generics. The
first official release supporting this will be 2.6.2. For instance
java.util.List is considered a generic type in Scala in this release.
I announce now so that you can experiment with the new feature. Maybe
you also already want to start to migrate your codebase to the new
scheme.

More precisely, the following things have changed:
continues

[1]
Here are some that I have met and convincingly (and often quite easily) debunked in conversation. Perhaps I could write about them some time.

  • From the CTO of X Corporation, “I don’t have any programmers capable of using Scala”. This myth is both easily falsified, but also extremely detrimental to the interests of the organisation — far more than is initially realised. That is to say, after debunking this myth, my opponent in the argument often has an enlightening experience and then an “Oh no! Given this (new understanding), look at what (detrimental decisions) I have been doing to the organisation!”. Of all fallacies, this is the one I’d like to put in the box of past events from which to learn.
  • But Java is enterprise-ready
  • But Java is a robust language with many libraries

15 Responses to “Scala 2.6.2 getting support for Java generics”

  1. Pseudonym Says:

    I agree with you about the CTO argument, but I think the open source argument is stronger. There are only so many open source programmers willing to put in the time to learn Scala.

    Having said that, there’s one other argument I’d like to suggest: You need to learn to read Java in order to use libraries targeted for the JVM. Put another way, there are lots of good reasons to learn Java even if you never use it in anger.

  2. Robert Says:

    I don’t agree with you about Java itself but I do agree that Scala is one honking good language.

  3. ok Says:

    I like Scala too, but at this point the Eclipse and Netbeans plugins only do basic highlighting and code completion.
    No form designer support, etc.

  4. Willem Says:

    Could you comment on why you think Scala is a better choice then CAL ? I am trying to learn about functional programming, and given my experience with Java, I’d like to start with a functional language that targets the JVM and can integrate well with regular Java code, rather than Haskell for instance.

    Having read in one of your previous blog posts that you found CAL better/cleaner/… than Scala (you did say that you had not yet thouroughly investigated CAL though), I took a look at it and took a liking to it (without any real reason, other than being the first functional language I actually tried hands-on).

    Reading now that you prefer Scala over CAL makes me wonder just why :)

  5. Tranto Says:

    Ah, crud. Scala is an eclectic pile of individually cool pieces, but put together the way it is, its total rubbish — a single glimpse at its libraries should illustrate this point beyond any doubt.

    Java can (and will) be extended to include Scala’s features, but Scala can’t be redesigned to achieve Java’s coherence and simplicity (or it wouldn’t be Scala anymore, would it :)
    We’ve no particular use for a language aping functional languages — mostly because we already have functional languages around…

  6. Tony Morris Says:

    Hi Willem,
    I’m still on the fence there. When I can articulate a conclusion, I will :)

  7. Tony Morris Says:

    Tranto,
    I’ve glimpsed the libraries, I have doubt, lots of it. Care to explain rather than attempt a proof by assertion fallacy?

    Java cannot and will not be extended to include Scala’s features, not ever. Generics don’t even come close to Scala’s parametric polymorphism and the closures proposal is a sad waste (need I point out their inferiority to Scala?).

  8. Artur Biesiadowski Says:

    Main issue with Scala I have atm is lack of real integration in any of the big environments (Eclipse/Netbeans/IDEA). Navigation/refactoring possibilities given by java tools these days are really great and I would hate to see people coming back to ‘medieval age’ of notepad+syntax highlighting.

    I think Scala is already good enough from the point of language. Now it is time for it to become good from tool support aspect.

  9. Jim Menard Says:

    Artur and “ok”,

    Sounds like you are Tool Mavens, not Language Mavens (http://osteele.com/archives/2004/11/ides).

  10. tranto Says:

    Erm…I must say I was quite surprised to see that the libraries had gone such a long way since about two years ago :)
    They still look a bit funny to me, though it’s quite worth it having another look at them. Of course, I’ve forgotten most of the language by now, but I’ll be sure to revisit it.

    I’m taking my words back, for the lack of a better answer, but that’s not final yet ;)

  11. tranto Says:

    I just finished having a look..

    Bah.. it’s all crud all over again.

  12. tranto Says:

    Huh? Mama mia! Who is this last tranto?
    I am the first one, and I dont know what he is talking crud about!

  13. Artur Biesiadowski Says:

    As far as Tool versus Language Mavens are concerned - there is a lot of truth there. Unfortunately, there are way too many niche languages out there and most of them will die in obscurity - and hopefully, during their 1-2 years of fame, nobody will be ’smart’ enough to use them in some kind of project requiring maintenance. Same is of course true for nonstandard IDE extensions - especially things like custom form builders are completely useless few years down the road. I think that my reliance on good tool support is a sign of something else - I want mature languages. I might be missing best-of-the-breed tool to solve the problem, but with mature languages I’m at least more sure that they will not disappear next year. It seems to me that tool support is a good sign of the mature language (has nothing to do with being good language of course). There are some notable exceptions - PowerBuilder comes to mind.

    As far as article you have mention is concerned, I do not think that graphs shown there (choice between focusing on the language features versus focusing on tools) are really true. I don’t see tool versus language development as a choice. In most cases, same people will not do both things. New language obviously requires language developer - it cannot come from tool developer. And ’small’ languages stay with language developers only - they are not attracting tool developers. In some way, it reminds me of the case with many games appearing on the internet. Often you end up with bunch of game programmers and no artists to support them. In some way, programmers are ‘cheaper’ to get for internet projects then modelers/graphic guys. Most probably it is because programming in such cases is fun (you mostly implement what you want), while art assets are work (you need to provide whatever assets are needed for the game). I somehow feel it is similar for new languages - implementing compiler is fun for some guys, adding tools on top of them is a pain nobody wants to touch.

    Do I want to bet the project maintenance on the language nobody can be bothered to write tools for? Probably not if the language is fresh. Does anybody remember kiev? I almost made a mistake of writing a big project in that…

  14. λ Tony&#8217;s blog λ &#187; Blog Archive &#187; Offending Religiosity Says:

    [...] In my recent post, I made the following introductory statement: Scala is a far superior language to Java. [...]

  15. Igor Hjelmstrom Vinhas Ribeiro Says:

    Hey - your blog is very nice.

    “Scala is a far superior language to Java. In fact, of all the languages that I have investigated, it is the most powerful language that also targets the JVM and Java libraries easily (sorry CAL).”

    I am just curious about whether you have ever heard of / investigated SISC ( http://sisc-scheme.org/ ).

Leave a Reply