James is a DZone MVB and is not an employee of DZone and has posted 7 posts at DZone. View Full User Profile

Scala as the Replacement to the Java Compiler?

  • submit to reddit
Don't get me wrong - I've written tons of Java over the last decade or so & think its been a great evolutionary step from C++ and Smalltalk (lots of other languages have helped too like JavaScript, Ruby, Groovy, Python etc). However I've long wanted a long term replacement to javac. I even created a language to scratch this itch.

Java is a surprisingly complex language (the spec is 600 pages and does anyone really grok generics in Java?), with its autoboxing (and lovely NPE's hiding in there), primitive types, icky arrays which are not collections & general lack of polymorphism across strings/text/buffers/collections/arrays along with extremely verbose syntax for working with any kind of data structure & bean properties and still no closures (even in JDK7) which leads to tons of icky try/catch/finally crapola unless you use frameworks with new custom APIs & yet more complexity. Java even has type inference, it just refuses to use it to let us save any typing/reading.

This issue becomes even more pressing with there being no Java7 (which is even more relevant after Snorcle - I wonder if javac is gonna be replaced with jdkc? :). So I guess javac has kinda reached its pinacle; closures look unlikely as does any kind of simplification or progression.

So whats gonna be the long term replacement for javac? Certainly the dynamic languages like Ruby, Groovy, Python, JavaScript have been getting very popular the last few years - lots of folks like them.

Though my tip though for the long term replacement of javac is Scala. I'm very impressed with it! I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.

So why Scala? Scala is statically typed and compiles down to the same fast bytecode as Java so its usually about as fast as Java (sometimes a little faster sometimes a little slower). e.g. compare how well Scala does in some benchmarks with groovy or jruby. Or this. Note speed isn't everything - there are times when you might want to trade code thats 10x slower for more productivity and conciseness; but for a long term replacement for javac speed is important.

Yet Scala has type inference - so its typically as concise as Ruby/Groovy but that everything has static types. This is a good thing; it makes code comprehension, navigation & documentation much simpler. Any token/method/symbol you can click on to navigate to the actual implementation code & documentation. No wacky monkey patching involved, or doubting of who added a method, when and how - which is great for large projects with lots of folks working on the same code over long periods of time. Scala seems to hit the perfect sweet spot between the consise feel of a dynamic language, while actually being completely statically typed. So I never have to remember the magic methods that are available - or run a script in a shell then inspect the object to see what it really looks like - the IDE/compiler just knows while you edit.

Scala has high order functions and closure support along with sequence comprehensions so you can write beautifully concise code. Scala also unifies functional and OO paradigms beautifully together into a language thats considerably simpler than Java (though the type system is of a similar order to truly understand than generics - but then thats usually an issue for framework creators rather than application code developers). It also lets folks gradually migrate from a traiditional OO/Java way of coding to a more functional way - which is particularly relevant for folks writing concurrent or asynchronous code (which due to the GHz of chips no longer going up but instead we're getting more cores is becoming more necessary). You can start the OO way and migrate to using immutable state if/when you need its benefits. Increasingly functional programming is becoming more and more important as we try and make things more concise and higher level (e.g. closures, higher order functions, pattern matching, monads etc) as well as dealing with concurrency and asynchrony via immutable state etc.

Scala also has proper mixins (traits) so you don't have to muck about with AOP wackiness to get nice modular code. There's even structural types in case you really do need some duck typing.

The thing which most impresses me is the core language syntax is pretty small and simple (the spec is about a quarter the size of Java's); but its way more powerful and flexible and is very easy to extend in libraries to add new semantics and features. For example see the Scala Actors. So its ideal for creating either embedded DSLs or external DSLs. There's really no need to have Java , XPath, XSLT, XQuery, JSP, JSTL, EL and SQL - you can just use Scala with some DSLs here and there (examples of this later...).

Scala does take a little bit of getting used to - I confess the first few times I looked at Scala it wasn't that pleasing on the eye - with Java you're kinda used to dumb verbose code which doesn't do very much - it can be quite a shock to see quite a few symbols at first. (It took me a while to get over the use of _ in scala which is the 'wildcard' symbol since * is an identifier/method).

If you've been doing lots of Java then Scala does feel quite different at first - (e.g. the order of types & identifiers in method/variable/parameter declarations - though the reason for that is to make it easy to miss out redundant type information).

e.g. in Java
List<String> list = new ArrayList<String>()
in Scala
val list = new List[String]
or if you want to specify exact typing
val list : List[String] = new List[String]
However if you keep at it, the beauty of Scala soon becomes apparent; its simplified so many of the gremlins in the Java language, allows you to write very concise code describing the intent behind the code rather than the implementation cruft - together with providing a nice migration path to elegant functional programming which is awesome for building concurrent or distributed software.

I highly recommend you take a look at Scala - with an open mind - and see if (once you're brain adjusts) you can see its beauty too.

Some scala links and online presentations

If you have a spare hour or so these video talks are great to watch
Handy Scala frameworks and libraries
  • liftweb the rails of scala
  • specs and ScalaTest for BDD and more literate testing showing how a typesafe DSL can help you write more consise and expressive code that is very IDE friendly
  • scalaz a handy library of utilities
  • dispatch for working with HTTP/JSON services
BTW for those like me who love JAXRS you can now use lift templates with Jersey via the new jersey-lift module.

As an example of this in action you can check out RestMQ which is an open source project I've been working on lately to provide a RESTful API and web console to message orientated middleware which is built on JAXRS (Jersey), Scala and Lift.

From a tooling perspective there's Ant/Maven plugins, an interactive Scala console (REPL) and IDE plugins for IDEA, Eclipse, NetBeans along with the usual editors (TextMate/Emacs etc). The IDE plugins are not yet up to the Java grade, but they are very useful with good code navigation & completion.

I've tried the plugins for NetBeans, Eclipse and IDEA they all have strengths and weaknesses; it seems Scala folks are split between them all. For code navigation and completion along with maven support I've found IDEA to be quite good. When you open a Maven pom.xml it seems to grok the code nicely, finding the scala source so you can navigate through any type/method to see its documentation/source etc. (You do typically have to manually add the Scala facet to run/debug stuff). Though IDEA is not always the best at highlighting syntax errors as you type. They could all use some work to bring them up to line with their Java counterparts though - try them out and see which you prefer.

Scala nits

With any language there's gonna be bits you love and bits you're not so keen on. Early impressions of Scala do seem like there's a bit of an attempt to use a few too many symbols :-; but you don't have to use them all - you can stick to the Java-ish OO side of the fence if you like. But then I guess longer term its probably better to use symbols for the 'special stuff' to avoid clashing with identifiers etc.

I'm not a massive fan of the nested import statement, using _root_.java.util.List to differentiate a 'global' import from a relative import. I'd have preferred a child prefix. e.g. if you have imported com.acme.cheese.model.Foo then to import model.impl.FooImpl i'd prefer an explicit relative prefix, say: import _.impl.FooImpl which would simplify things a little and more in keeping with Scala's attempt at simplifying things and removing cruft (being polymorphic to import java.util._).

However compared to all the massive hairy warts in Java, these downsides of Scala are tiny compared to the beauty, simplicity and power of Scala.


Given that MrJava, MrJRuby and MrGroovy are all tipping Scala as javac's long term replacement, there might be something in it. So what are you waiting for; get the Programming Scala book or the O'Reilly Scala book and start having fun :)
Published at DZone with permission of James Strachan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Dieter Krachtus replied on Wed, 2009/07/08 - 12:05pm

won't happen, but I agree Generics is somewhat frustrating at times.

Jacek Furmankiewicz replied on Wed, 2009/07/08 - 1:04pm

That's what Microsoft server-side propaganda said about Linux a few years ago...and look at it now.

After dabbling in Erlang recently and learning about list comprehensions, pattern matching and Actor-based concurrency, I am actually quite ready to expand my knowledge and learn Scala (which fuses the best of Java and Erlang together). My copy of "Programming Scala" is in the mail.

Considering the glacial pace of Java development from Sun in the last 2 JDKs, it would be useful to a new VM language to take it on (since Scala already has what Java won't even have in the next 2-3 JDKs).

Don't count Scala out. I am personally giving it a shot and learning about it.



Tom Wheeler replied on Wed, 2009/07/08 - 1:45pm

On a related note for anyone near the St. Louis (USA) area who's interested in functional or dynamic languages, I'd highly recommend coming to a Lambda Lounge meeting where we talk about these topics every month. 

Our May meeting featured a language shootout in which members volunteered to solve the same problem (implementing a simple vending machine) in different languages and then briefly explain the solution to the group.  It was very interesting to see how developers approach the same problem in different languages -- we had Scala, Clojure, Ruby, Groovy, Perl 5, Haskell, Squeak, JavaScript, Python and a few others.  You can see videos of these presentations on blip.tv, linked to from the right sidebar of the group's Web site.

Rainer Eschen replied on Wed, 2009/07/08 - 2:52pm

I don't had a look at your language implementation or Scala in detail. But, I can't recognize so much difference that I would start learning a new syntax to get the same results. Would be interesting to get a real life, enterprise-ready and mission-critical example that tells me, the software architect, that my developers need two-third of the implementation time of a classic Java implementation or something similar.

New language concepts are only useful if a projects gets advantages out of it. One is time, another is maintenance, etc. Every change in language creates extra efforts. For this I need something back that is woth changing something that is done for a long time with a lot of experience, etc.

Mrmagoo Magoo replied on Wed, 2009/07/08 - 4:20pm

Very true. I think sometimes people seem to think that switching a team/organisation over to a new language is not a huge endeavour. Politically as well as time/money investment. Many of the people I have worked with have enough trouble with their core language let alone trying to master a new one while remaining productive?! Also, that the elegance of the language, the size of the code and the ability to take syntactic shortcuts is the LEAST important thing about an enterprise language!

One of my bigger concerns would be how easy is it for developers to tie themselves in knots and write unmaintainable code. Showing me code that can increase the number of ways a developer can (mis)represent what they want to write is not necessarily a good thing given the reality of developers many of us have to work with.

What about IDE support? (and no, colouration is not enough!)

What about support for things like findbugs/checkstyle and other means of assuring maintainability?

But making an argument about "code size" and "short cuts" and then relating that to decreased "complexity" is not a strong argument. There are many programming competitions out there (perl in particular) that make this theory look foolish.

It may be syntactically more elegant, but this is the LEAST important part of complexity to anyone thinking further than just academically.

IDE support for scala cannot possibly be as good as for Java (probably very weak by comparison) and this sort of support can make navigating and understanding java code deceptively easy...even if the language is being more verbose.

I am NOT poo pooing scala since I am no expert in it. Just pointing out that the issues disscussed here are not the important ones. Those that are seem to be missing?

Much like groovy, scala would have to prove itself in these or simply become a niche language for writing "fast and loose" code. (for both the good, bad and just plain ugly applications of such - just like groovy is)

Alex(JAlexoid) ... replied on Wed, 2009/07/08 - 4:45pm in response to: Rainer Eschen

Would usage of Scala by LinkedIn be good enough for you, a fellow architect?

Or maybe this link will help open your eyes: Scala in the Enterprise

Osvaldo Doederlein replied on Wed, 2009/07/08 - 6:10pm

As someone who despises dynamic-typed languages, I find incredibly sweet to read this testimonial from the creator of a major dynamic language. I will save a link to this article and use selected quotes as ammo for years to come.

Static typing + good type inference rules. The rest is junk. ;-)

Otengi Miloskov replied on Wed, 2009/07/08 - 10:52pm

Im disputing in one of the Dzone articles releated to this about Scala and the problem I see is maybe Scala is complex for replace Java maybe Im wrong but today I changed my mind little bit and maybe I will give a shot to Scala more deep. Also thanks to Haskell I understand better functional.

Two problems I see right now are:

1.There is not good tooling or a good plugin with Eclipse.

2.I would like to use Scala for web and server apps but the only framework I know is lift framework have lots of dependencies.

Otengi Miloskov replied on Wed, 2009/07/08 - 11:22pm

One question, if Oracle/Sun decide tomorrow that Sun JVM will be propetary and you cant download it anymore with just paying, where we could run our Scala programs free again, Apache Harmony?.

Artur Biesiadowski replied on Thu, 2009/07/09 - 12:29am in response to: Otengi Miloskov

One question, if Oracle/Sun decide tomorrow that Sun JVM will be propetary and you cant download it anymore

They cannot, OpenJDK is open. They could possibly, somehow try to forbid calling it java (same would apply for Harmony and friends). They could stop distributing new versions for free, but whatever is there now in openjdk stays open.

If something bad would happen to java, .net version of scala would probably get more attention and you could run it on Windows .NET ;) And as we all know, Sun is bad for not giving TCK to IBM, and MS.NET is fully open, because they have submitted 50% of the platform specs to ECMA.

Otengi Miloskov replied on Thu, 2009/07/09 - 1:47am in response to: Artur Biesiadowski

Alright, thats awesome that Scala can run on .Net too. Or if we contribute, Scala could run over LLVM. Thanks for your reply Artur, it was informative :)


Jeroen Wenting replied on Thu, 2009/07/09 - 2:46am

The Scala community (what there is of it, seems to exist of a few dozen people) must be terribly insecure.
All that ever comes out of them are wordy rants against Java and even lengthier statements about how Scala is going to "take over" from Java.
Meanwhile the rest of the world recognises it as JASL (just another scripting language) that's marginal at best.

Johan Compagner replied on Thu, 2009/07/09 - 3:12am

Scala is a great language, i have read (or still reading) the programming in scala book


The only thing is that the tooling should be improved, full navigation and refactoring support.

So if possible have really a SDT  (besides the JDT) in eclipse with the same functionality.

Robin Small replied on Thu, 2009/07/09 - 4:12am in response to: Jeroen Wenting

Jeroen: I've not seen any core Scala people say that Scala is going to take over from Java... Links? Of course some random person who has just discovered Scala might. Otherwise I think you are confusing it with Ruby. BTW, there are loads of people on the mailing lists, certainly more than a few dozen.

Thomas Auzinger replied on Thu, 2009/07/09 - 9:52am

Sounds good, but there needs to be a corporate or large institutional sponsor or it won't survive (remember Eiffel?).  Try to sell the idea to Oracle.

Osvaldo Doederlein replied on Thu, 2009/07/09 - 9:59am in response to: Jeroen Wenting

Why do you call Scala a "scripting" language? Scala has absolutely zero scripting traits. Not different from Java in that matter. Perhaps you didn't even look at it (or you're just trolling).

I googled some blogs repeating this mistake, it seems that for some people, scripting == concise or high-level syntax, and easy programming of certain tasks like parsing. That's obviously wrong.

Walter Bogaardt replied on Thu, 2009/07/09 - 11:22am

I"m agreement with some posters that there has to be a good compelling reason to move to another language, beyond cool new shinny simple features. Especially if you have to make a business case. How many Scala programers can you find in a job pool or organization? Sure you can train and convert over to technology X, but it requires mentorship, and training; most of the time this is for quit a while.

It's one thing to learn, which every developer should do, just to expand on their knowledge base. It's another thing to change an entire enterprise to some new programing language. 


Otengi Miloskov replied on Thu, 2009/07/09 - 11:51am in response to: Walter Bogaardt

Somone said to me look like this. Scala is the next Java 3. But it does not need to be in the JCP or JSR it is an open source programming language already everybody free to use it whatever you like.

The upgrade path is similar as you went from Java 1.1 to Java 1.4 slowly but little by little begin to convert your people and projects to Scala even takes 5 years to do it, Scala will be there because they way how I see, There is not Java SE7 spec so means there is not Java standard anymore. But Scala is a refactor of Java 1 and Java 2 it is a better and much expressive langauge than Java.

Im not a Scala zealot this just my opinion of what I have seen about Scala and I was disputing Scala could be complex to replace Java but I think Im wrong, Scala could replace Java pretty well. Im reading Odersky book righ now and it looks exciting this new language.

Oliver Plohmann replied on Fri, 2009/07/10 - 4:28am

I would say Java was a great step back in the times before Smalltalk ... ;-). With closures, traits, static typing through type inference I would say that Scala would be a step ahead, though. If we have hot code replacement 100% working in Scala (which is not the case at all in Java), we will also get a developer productivity level in Scala comparable to Smalltalk. But I'd not be surprised if the issue of ot code replacement at development time being important for deveoper productivity is not understood by the Scala people in the same way it is not understood or ignored by the Java folks at Sun.

Artur Biesiadowski replied on Fri, 2009/07/10 - 1:52pm in response to: Oliver Plohmann

If we are at subject of full hot code replacement in Smalltalk - how it was working in the case you have removed some fields and added some others to class which already had instances? To what values new fields were initialized? How it behaved if you have changed hierarchy (by changing parent class) which would cause given class to have different implementation of certain method and another thread was in the middle of executing old method?

Unfortunately, some trick would be prohibitively hard to do in java due to type safety. Imagine array of X[] where you put Y (which extends X) and then you reparent Y to not extend X. It could be detected (by sort of full gc-like mechanism), but what to do then? Clear the entry to null? Leave it there? Any solution will lead to major inconsistency with current java (and even more with Scala, which has stronger type system in many cases).

I suppose that we cannot aim for 100% hot swap. Possibly, adding interfaces, adding null-initialized fields, removing fields and possibly removing non-exposed methods could be thought about in addition of what we have currently. Removing interfaces, reparenting classes, changing types of fields in incompatible manner are no go, regardless of what was possible in Smalltalk.

Christophe Hunt... replied on Sun, 2009/07/12 - 8:50am

first SMALLTALK was the root of all the main features of JAVA and object langages. Xerox parc creates 30 years ago, all the basics, patterns, and paradygms we use today,  in object language.

But the most important thing is JAVA is not only a language, but a mainly a plateform.

And SCALA is only one language over the JAVA plateform. SUN spend more effort on JAVA plateform than on JAVA API, and JAVAFX is a  good exemple of that policy. Plateform are more reliable on long term 

 That's why I continue to use JAVA.

I think that is the future of programming. We shall spend more time, while begining a software, in choosing the targueted plateform than choosing a language. SCALA, GROOVY, JAVAFX are proving that philisophy. A softawre can run using code developped on all that language.

Today, engineer shall focus on function, using the language that is dedicated to be efficient. JAVA plateform is  compliant to that way of working.


Oliver Plohmann replied on Mon, 2009/07/13 - 8:07am

If we are at subject of full hot code replacement in Smalltalk - how it was working in the case you have removed some fields and added some others to class which already had instances?

Yes, that is an issue. You would evaluate something something like myClass allInstances do: [ :instance | instance become: '']. The instances are then strings and therefore myClass has no instances any more, and you can play around with the class definition (add/remove vars, etc.). Smalltalk is a little more dynamic than statically typed languages... However, this is not a vital issue that would turn 100% hot code replacement into a fundamentally problematic thing.

Today, engineer shall focus on function, using the language that is dedicated to be efficient. JAVA plateform is compliant to that way of working.

For those people who don't understand how much additional coding work they have to do without closures and don't understand how inadequate existing workarounds are at the absence of mixins/traits with regards to good OO design that kind of statement may sound very professional.

Alex(JAlexoid) ... replied on Tue, 2009/07/28 - 8:26am in response to: Christophe Huntzinger

How ironic that you made this spelling mistake.

And SCALA is only one language over the JAVA plateform. SUN spend more effort on JAVA plateform than on JAVA API, and JAVAFX is a  good exemple of that policy. Plateform are more reliable on long term 

  Because Java is starting to look like a plate-form thing.

Stephen McConnell replied on Sat, 2009/08/22 - 3:18pm

I haven't had a real opportunity to look at Scala, but I remember when Java was just coming out.  It was difficult to get shops to start using it without strong support from IBM and Oracle implementing it in many of their products.  Without the initial Visual Age for Java or JBuilder from Borland (and Oracles piggybacking on it), Symantics Java IDE, there would have been no wide range acceptance of Java.  Having programmed COBOL in VI, I can say that I definitely didn't want to program Java with that.

 There are big Catch 22 hurdles to having a language accepted as a new standard.

  1. There have to be really compelling reasons to adopt the new language.  Are there new technologies and paradigms that the old languages don't address.   With Java, it was the Internet and the myriad of multiple platforms (Just try doing the multi-threading, internet work in C/C++ or COBOL or RPG III... I can tell you it was a nightmare).  But what new technoligies and paradigms does Scala address?
  2. There has to be a set of stable, strong language supporters willing to participate in the definition of consistent across the board syntax and specifications.  With Java, Sun started the ball rolling and companies like IBM, Oracle, Borland and Symantic and even the Apache group were willing to sit down and hammer out a storng common language.  Languages like PHP and Python also have a strong group of backers.  PHP is beginning to be adopted on a wide scale like Java for web applications.  But I don't see this yet with Scala.
  3. There has to be a set of Visionaries willing to stick their necks out and say "We need to do our project in this new language because......."  And politically management has to agree.  I was VERY lucky to be able to convince management to re-write a major portion of their core company software in Java very early.  I was also lucky to participate in a Major IBM project that use IBM Visual Age for Java and EJBS for the first time.  And I was lucky enough to work for a consulting group that let me prototype and then rewrite an early Content Management System from VBScript to Java Server Pages/Servlets.  In this climate of "bottom line" and economic recession, I don't think there are many companies that have the "stones" to do this.

I see articles in JavaLobby, on IBM Developer's Network and various blogs touting a NEW language as a "replacement" for Java.  I just don't see it yet.  But just like the "Housing Market",  Java is becoming top heavy and is ready for a tumble.  Maybe Oracle's take over of Sun will be just the thing to do it.



James Strachan replied on Thu, 2010/02/18 - 7:25am in response to: Stephen McConnell

Stephen, 1. My blog post tried to list all the various reasons why Scala is much better than Java (first class functions & closures, traits, type inference, pattern matching, really concise code along with all the functional programming features etc) 2. I think its a very different time now. Choosing Java over Cobol used to be a major platform decision. These days writing a bunch of classes in Java or Groovy or JRuby or Clojure or Scala doesn't really matter that much - they all generate bytecode running on the same platform, sharing the same libraries & tooling & all the pieces can work just fine together. I see Groovy, JRuby, Clojure and Scala being used more and more despite an IBM backing any particular one. 3. As I said in my blog post - both Mr Java, Mr Groovy and Mr Ruby are all agreeing - thats not a bad start eh? :)

Comment viewing options

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