Tricksy JBoss AS

So, initially when I heard that JBoss AS 5.0 was going to modular, of course I thought "OSGi". This has been the precedence for Glassfish and Spring DM. However, the next set of news I had was from some OSGi advocates railing on JBoss for rolling their own module system. However, I ran across this link that makes things more apparent Most Awaited JBoss 5.0 Soon to come.

If you read between the lines, it appears like JBoss went with their own module framework so that:

• they could find a way to appease the OSGi community (as they propose that their implementation is compatible)


• support legacy MBean components


• inter operate between various implementations (conjecture: jigsaw?)

It's my opinion that this was actually a wise move, assuming the effort was not very high. This is because Project Jigsaw is still an unknown in the modularization market, and perhaps JBoss is positioning themselves to be one of the first to support it.

As long as I can use some nice OSGi module-based solutions in the meantime, I think this is a big win for JBoss as an App server choice. I'd prefer however for modularization to make into Java via a JCP (and therefore into the JEE spec), so at least there's some kind of standard implementation that can be used (with servers like JBoss able to provide proprietary extensions if desired).

Why you want to learn Scala!

Why you want to learn Scala!

Below are the slides from the talk I gave to the Northern Virginia Java user's group.

A few random errata from the meeting:

• A few minor introductions to Scala's type system/generics may be helpful


• I messed up my description of Nothing and Unit. Page 130 of the Scala Spec has a diagram of the type system. Nothing + Null are at the "bottom" meaning they psuedo-inherit from every type.


• I need to flesh out my examples a bit, especially pattern matching. I'll try to update the slides as I find time


• Apache MINA + Scala - blog posting


• Planet Scala - A scala news aggregator. I recommend checking out old posts from scala-blogs and graceless failures

Update: Here's a picture of me giving the presentation.



Thanks to all who attended! I thought interaction was really good, and was excited to see so much enthusiasm!

-Josh

Way to go Spring Source!

<rant>

It's good to see some critical feedback on the JEE spec. I'm glad I'm not the only one questioning some of the merits of the JSRs. I'm also disappointed that the blog-o-sphere picked up on Apache's "the JCK is not really open" complaints, but seem to have completely missed (or don't have a response to) SpringSource's "too much, in the wrong places" complaint.

Granted, Seam looks to be very interesting. The biggest killer (IMHO) is JSF. Now, if the new JSF spec fixes that... perhaps it could be viable. The question remains, are Spring's complaints of "too much risk" valid? (Seam appears to be a pretty good working prototype of this JSR). Yes it would be nice to have way to easily piece together simple data driven web-apps. I personally believe JEE is still overkill for this.

Regardless, I think it is most important that the entire Java stack makes it easy to "compose" software. The easier it is to "compose" the more it encourages people to write modular code. I don't think dependency injection => modular code, but it sure encouraged *some* folks to start writing better code.

Although spring is a *rather large* codebase, it still feels to be one of the better designed library stacks for the Enterprise Development. I often find classes inside it highly useful. More so than the JEE spec. Possibly it's because they took a closure-like approach to their apis. Hmmm..... closures + java? what a novel idea.

</rant>