OSGi, Scala, maven, and git
I've noticed a few people are integrating OSGi and Scala. In particular Heiko Seeberger is building OSGi bundles for the Scala language plus various utility modules and DSLs. Then he's using maven for build and git for version control.
I am, of course, a fan of OSGi. I'm rapidly warming to git. But I'm not sure Scala and maven really solve more problems than they introduce. I don't want to dwell on maven as I'm not sure other build systems are really much better, but Scala does raise lots of question in my mind.
Many years ago, I was keen to adopt new technology and some combinations worked really well while others just seemed to multiply the overall complexity. One particular combination was the use of Z specification language embedded using literate programming in a subset of our target programming language with proof rules. It was possible to create proof trees of simple specifications refined to the target language. The main problem was that there were very few people who could acquire the skills necessary to master the combined technology.
Well, perhaps that was an extreme example and maybe it was doomed from the start, but I have a niggling doubt about the size of the Scala language.
So I'd be delighted to understand what features of OSGi and Scala work well together (and what features are simply best not used as part of this combination). In particular, are there any particular problems which are significantly simplified by combining OSGi and Scala which cannot be attacked very well using OSGi (and Java) or Scala alone?
Postscript
This document partially answers my questions. Scala makes it easy to write a DSL for handling OSGi services simply.
This is similar to the kind of function provided by Spring DM (or, equivalently, the OSGi Blueprint service).
The main difference is that there is still some minimal clutter in the Scala program whereas with Spring DM POJOs are configured in XML to provide and use OSGi services. I suppose the Scala approach favours sophisticated use of OSGi services, but this is not the norm in typical enterprise applications.
10 comments:
You said you have a niggling doubt about the size of the Scala language. Do you worry that it's too small or too large? It's a smaller language than Java so presumably you're concerned it may not be rich enough to express certain concepts, however I believe that Heiko and Roman's work on ScalaModules shows that not to be the case.
The point of the DSL is not to do exactly what Spring-DM does. In ScalaModules you have direct access to the lower level APIs offered by OSGi. When dealing with those APIs in Java we must write ugly code because of the need to deal with all the try-finallys, null checks, synchronization blocks etc. With Scala we can write much cleaner code without losing any of the power of the lower level APIs.
By contrast, Spring-DM, DS, iPOJO etc are abstractions implemented in an external bundle, and there are certain things we can't do from DM. Also the implementation code for the DM extender bundle is complex and ugly. DM may have been easier to write if it had been written in Scala!
Why is sophisticated use of OSGi service not the norm in enterprise applications? Is it really because nobody wants to do it, or because it's too hard with existing tools and languages? What would happen if we made it easier for everybody to build sophisticated services by giving them more powerful language constructs, rather than hiding away complexity in an extender bundle?
When you are familiar with Scala, you will need fewer lines of code, your code will be more readable and if you adopt to the functional style your code probably will be easier to test. Hence you will be more productive and the quality of your code will increase. Sounds promising, eh?
Of course, in order to get familiar with Scala, you will have to spend a significant amount of efforts for learning, struggling with the tools, etc. I know what I am telling, believe me ;-) Hence in the beginning you will be less productive and your code will probably be full of bugs.
But isn't that common for each new technology? Just remember your first Java programs. Or your headache over some NoClassDefFoundError when starting with OSGi. In my opinion Scala's advantages are very promising, thus I am taking these initial efforts.
Regarding OSGi Scala can be used to ease development, because OSGi APIs are low-level and at some points "not-so-nice" (null references). Of course there are other weapons like OSGi DS, iPOJO, Guice Peaberry, BindForge (Scala-based) and of course Spring DM.
Spring DM offers a lot of benefits, especially if you additionally intend to use Spring. Hence why not add five great technologies? Scala, OSGi, Spring DM, Maven and Git ;-)
By the way: I am not religious about build or SCM systems at all, hence we could replace Maven by Ivy or SBT or XYZ and Git by Mercurial or SVN or ...
Hi Neil. Many enterprise programmers would prefer to spend their programming effort on the business logic. Some enterprise programmers do need to write infrastructure and I think your comment applies mainly to them. For the bulk, I think perhaps "out of OSGi container" testing is valuable to provide. Perhaps some suitable ScalaModules stubs could do the trick there?
Hi Heiko
I tried dipping in to Scala last year and it felt a bit like C++ or perhaps Ada with a complete rag-bag of OO and functional features smashed together with some nifty concurrency ideas. It seemed like a great research project but a not very pragmatic choice of programming language for the software I am developing. I guess the main hesitation was bringing the skills of the team (including myself) up to scratch while writing/shipping robust code.
Over Christmas I read a book on Haskell and did some of the exercises to gain familiarity of functional programming without the OO "baggage". Having just looked at the ScalaModules examples, I can start to appreciate the language constructs better than the first tinme around.
If I could lay my hands on a text book for Scala similar to the classic C++ texts, I'd be very grateful. Remember the "design and evolution of C++" and the other reference texts produced by Stroustrup? Maybe that was before your time.
@Glynn,
I'm concerned about Scala's size too. The smallest grammar I can find for C++ is about 1300 lines of EBNF. GHC Haskell 6.6 has a grammar of about 450 lines. The Java spec grammar is about 350 lines. In contrast, Scala's is only 250 lines. It's hard to see how such a small language can be pragmatic.
Also, I'm fascinated to learn from one of your comments that the language mashes in concurrency features beyond the ones offered by Java. My studies showed nothing. All the interesting Scala concurrency features I can find (e.g. actors) are in the library and from that perspective Java's library dwarfs Scala's, even in the area of concurrency.
Hmmm, is it possible we're talking about two different languages?
Hi James
Perhaps the syntax of Scala is smaller than that of Java, but there combination of features is the scary thing. Maybe I'll become more comfortable over time.
Yes, the concurrency features are mainly in the runtime library. You're quite right.
I think there's a reasonable amount to like about Scala, whether in OSGi or not. I don't think it's right to think about it making OSGi any easier (or more difficult) but rather as an alternative language to write code in. The fact that it has got (semi-)official OSGi support then makes it easier to use Scala programs inside an OSGi architecture. Ask not what Scala can do for OSGi but rather what OSGi can do for Scala ...
That said, I have a number of reservations about Scala's future success. As any language, there have been a few poster-child examples. But is Scala suitable for enterprise use? There's the tipping point (of where the number of people who know a language exceed a threshold whereby it becomes easy to argue for using it) and Scala's a long, long way off that. Hey, if Eclipse RCP can't even get to that point, then what chance does a new language?
Hi Alex
Yeah. Another thing that put me off Scala when I first looked at it was that the Eclipse plugin seemed pretty buggy. I guess that's better now?
I have heard OSGi folks in the past say "OSGi" allows code hotswapping. I have heard Erlang folks say "Scala does not have hot swapping". Could Scala + OSGi enable hot swapping of smaller code units?
My pipe dream is Scala with "code units" (bundles/modules/whatever term you like) where you can have various communicating Actors where Actor implementations can be reloaded while the system is running.
Problems I see at present are things like one Actor maintains a direct point to other Actor instances it needs to send messages to. Would you need a proxy to allow such hot swapping?
For a server, I could then imagine having a listening actor passing requests off to processing actors. Reloading the implementation of a processing actor does not need the listening actor to be shut down. The old processing actor run in parallel
Or is this all a solved problem now?
Hi Alan
> I have heard OSGi folks in the
> past say "OSGi" allows code
> hotswapping. I have heard Erlang
> folks say "Scala does not have
> hot swapping". Could Scala + OSGi
> enable hot swapping of smaller
> code units?
Yes.
> My pipe dream is Scala with "code
> units" (bundles/modules/whatever
> term you like) where you can have
> various communicating Actors
> where Actor implementations can
> be reloaded while the system is
> running.
>
> Problems I see at present are
> things like one Actor maintains a
> direct point to other Actor
> instances it needs to send
> messages to. Would you need a
> proxy to allow such hot swapping?
Yes. Spring DM, now standardised as the OSGi Blueprint Service, provides such proxying (for Java). Not sure how usable that would be from Scala, but the concept would carry across fine.
> For a server, I could then
> imagine having a listening actor
> passing requests off to
> processing actors. Reloading the
> implementation of a processing
> actor does not need the listening
> actor to be shut down. The old
> processing actor run in parallel
>
>
> Or is this all a solved problem
> now?
It should be possible to do something similar with existing technology, but the solution you outlined looks plausible too.
Post a Comment