As described in the article, A Scalable Language, Scala can be used both for scripting and for large enterprise applications. Because Scala can also be used seamlessly with an existing Java codebase, Scala can improve the productivity and maintainability of Java applications.
One of the productivity challenges Java developers face is the need to constantly reload classes that were changed during development. Dynamic languages, like Ruby, tend to have instant turnaround, whereas developing Java Web applications is a constant cycle of coding, compiling, and redeployment. That is exactly the problem ZeroTurnaround solves with their JavaRebel product.
At the Scala Lift Off unconference ZeroTurnaround met with the representatives of the Scala/Lift community and decided that they wanted to help facilitate Scala adoption by putting Scala productivity on par with that of dynamic languages. To that effect, they created a special JavaRebel license that can only be used to automatically reload Scala classes, and donated that code to the Scala community for free use for a year. They plan to extend that license on a yearly basis to help drive Scala adoption.
ZeroRebel is currently discussing with the Scala and Lift communities the necessary licensing for embedding JavaRebel in Scala and Lift distributions, but until then developers can download the nightly build that includes support for Scala-only licenses. You also need to download the free license itself, which must be placed in the same directory as javarebel.jar.
Using the free Scala-only JavaRebel tool, you can evolve your application in an agile manner, benefitting from the powerful Scala static type system, higher-level abstractions, and seamless code reloading typical of dynamic languages, at the same time.
What do you think of JavaRebel's approach to automatic class reloading?
Wouldn't this problem, such as it is, be better solved by incorporating the necessary features directly into the language, rather than by embedding limited licences to propietary technology owned by (with respect) an unknown company?
Isn't the current existence of propietary technology in Java precisely what is preventing it being fully open sourced at the moment?
What JavaRebel solves, as far as I know, is the need to have to reload classes to the VM after making changes to those classes. I don't see how the language itself would be able to solve this. It's also possible to have something like Tomcat watch for modified files, and periodically reload an entire Web app. But reloading just a modified class into an already running application is much faster, and the experience is a lot more agile.
Ah, I got the wrong end of the stick. Re-reading it, I see it's more a tool than part of the language, per se.
Nevertheless, the following line still raises questions:
"To that effect, they created a special JavaRebel license that can only be used to automatically reload Scala classes, and donated that code to the Scala community for free use for a year. They plan to extend that license on a yearly basis to help drive Scala adoption."
Would it be wise to encourage reliance (at whatever level) by the Scala community on a feature whose presence is outside the control of the community and whose continued existence cannot be guaranteed (by the community) from one year to the next.
> > Would it be wise to encourage reliance (at whatever level) > by the Scala community on a feature whose presence is > outside the control of the community and whose continued > existence cannot be guaranteed (by the community) from one > year to the next.
The Scala "community" already relies on many things outside of its control and whose continued existence cannot be guaranteed.
> The Scala "community" already relies on many things > outside of its control and whose continued existence > cannot be guaranteed. > > Think about it.
Relying on Java which is being open sourced is a bit different
> The Scala "community" already relies on many things > outside of its control and whose continued existence > cannot be guaranteed. > > Think about it.
Think about what? Are you suggesting that this dependency can be accepted because other dependencies already exist? It's not much of a case in favour (in my opinion).
> > The Scala "community" already relies on many things > > outside of its control and whose continued existence > > cannot be guaranteed. > > > > Think about it. > > Think about what? Are you suggesting that this dependency > can be accepted because other dependencies already exist? > It's not much of a case in favour (in my opinion).
There is no dependency or reliance on JavaRebel. But beyond that (and as a more philosophical point), there's no guarantee that Martin Odesky or anyone else won't get hit by a bus tomorrow.
Oh, and the whole argument about Java being open sourced and therefore "you can rely on its existence" is completely bogus too. I can rely on bits being on harddrives.
> Would it be wise to encourage reliance (at whatever level) > by the Scala community on a feature whose presence is > outside the control of the community and whose continued > existence cannot be guaranteed (by the community) from one > year to the next.
Supposedly, I was watching this thread, but didn't get any e-mails.
Anyway, in what particular way does the Scala community rely on JavaRebel? It is not really a dependency, since there is no references to it in the code or in configuration. The only thing it does is improve Scala developer productivity at least for one year and most likely for much longer.
The main reason to include it in the Lift install is because most people will use it anyway (starting with the Lift developers themselves).
Previous Topic
