GlassFish OSE 3.1 is out with WebSocket support included

By now you likely know that we released 3.1 of GlassFish today.  It's all over twitter with much of the jubilation around the return of clustering and HA support.  But closer to my own heart is the inclusion, finally, of websockets support.  I've blogged about it before, so I won't go in to too many details here.  But this is the first actual release of GlassFish to feature support for it which I'm personally pretty excited about.

Some caveats still apply, however.  WebSockets are an exciting new technology but still remain under active development.  The version of the specification shipped with GlassFish 3.1 is the -76 version which is rather old by now.  It is still, as of this writing at least, the version supported by most of the browsers that support websockets.  So the good news is that apps you write today should work with most of the browsers out there.  As the specification evolves, however, browsers will begin to support newer versions of the specification and the GlassFish code will no longer work.

In the grizzly source tree, I have implemented support for the -05 version of the specification (with work started on the -06 version) for the 1.9 tree (which ships with GlassFish).  Should you find yourself needing newer support, I have written a simple bash script that will do that heavy lifting for you.  The script below needs to be run from the glassfish3/glassfish/modules directory.  In addition, you'll need to specify the version of grizzly you'd like to upgrade to.  The -05/-06 support will be present in 1.9.33 release coming up soon.

#! /bin/sh
NEWVER=$1
 
if [ -z "${NEWVER}" ]
then
	echo Please specify the new version as a parameter
	exit
fi
 
asadmin stop-domain
for i in grizzly-*
do
	DEP=${i/.jar/}
	wget http://download.java.net/maven/glassfish/com/sun/grizzly/${DEP}/${NEWVER}/${DEP}-${NEWVER}.jar
	[ $? -eq 0 ] && mv -v ${DEP}-${NEWVER}.jar $i
done
 
rm -r ../domains/domain1/osgi-cache/felix/
 
asadmin start-domain

This script will download the artifacts we've pushed to maven and update your existing grizzly jars.  It will also stop and restart your glassfish server for you so you don't need to worry about that.  The -05 spec is not compatible with the -76 version shipped with GlassFish 3.1 and we do not support the -76 version in the newer code for a variety of security/sanity related reasons.  So know that once you upgrade, you'll need browser support for the new version or your apps will stop working.

A word of warning, though.  I've done this locally and it works just fine.  But, as with any patch, you should back up your GlassFish directory first and/or test it in a development environment first.  If you have a support contract with Oracle, you'll likely need to discuss with them first to see how it would impact any agreements you have.  Ominous as that may sound, this should be safe enough to do (especially for a development environment) but just consider yourself warned.

WebSocket support is evolving constantly along the protocol itself.  While API changes are kept to a minimum, as we upgrade our support for the newer specifications and you upgrade your system to support them, you might encounter various changes in the API.  I really try to minimize such changes but please understand that things can change from release to release as everything beings to stabilize over the next few months.

I'm working on a number demos to help you get started with your own applications.  I'll be sharing a handful of those and presenting on building websocket applications at next month's The ServerSide Java Symposium in Las Vegas.  I'll be covering development using both 1.9 (and GlassFish 3.1) as well as grizzly 2.0 which just went final as well.  If you're there, please stop by and say hi.  I'd be happy to try to answer any questions you might have.

PHP better than Java?

After seeing this shirt I almost started believing it. Then I noticed the following tag line:

Please do not attempt to wear the screen--this t-shirt is just an image!

Does this "magazine for PHP professionals" think so poorly of their readers that they have to tell them they're looking at a computer screen? Maybe PHP types need that kind of reminder...

Why GCJ is bad (for newbies) and why Sun is to blame

I spend a fair bit of time helping out beginning Java programmers. My favorite is when they ask why their swing code doesn't work. When they post their stacktrace, there's all the GCJ/GIJ classes. I explain to them how GCJ isn't java and doesn't (fully) support swing and that they should just download Sun's VM and work with that. The problem with this scenario is multifaceted. For many, they use Debian (or some derivative) and the Debian ideologues choose ideology over functionality and ship a partial, non-certified implementation of a VM call it "java." Beginners, unaware of the distinction, run into problems and blame Java rather than misguided package managers. Others get it closer to right, like gentoo, and make it relatively easy to install Sun's VM. However, it's not entirely the package managers' fault.

Sun's insistence on the pointless click-through license to download the VM make it impossible for most linux distros to sanely package a working java implementation. (The same also holds true for maven/ivy repositories but that's another matter.) Since no one can redistribute the VM and many/most of the Sun provided libraries, automated package management becomes impossible and people, like RedHat/Fedora, end up shipping GCJ and calling it Java even though it is demonstrably not Java.

Now, I know some of you will point at Fedora Core shipping Eclipse all pre-compiled with GCJ but I'd like to point out that most of the hard stuff (the UI) is already native code. I have nothing against GCJ, per se, but calling it Java and making it the default Java package is misleading and, I think, just plain wrong.

Sun's insistence on this licensing is leading to efforts like what our friends over at the Apache Software Foundation are working on: complete, reimplementation of all (major) java specifications with "sane" licensing terms that are freely redistributable. So rather than working with the community to speed the progress of these APIs, they've "forced" the community to reimplement things under terms we're comfortable with. With yesterday's announcement that McNeally stepped down as Sun's CEO and Schwartz taking the helm, I'm hopeful we'll see some progress on this front.

I know the issue has been beaten to death, but maybe now we'll see a truly open source(tm) VM. I think the model of OpenOffice, Apache's httpd, and Linux make a great model. Sun can keep the trademark and even "editorial" control over the main source tree. But greater freedom in using the VM can only lead to greater involvment from the community. Examples, like python, PHP, perl, and ruby show that languages can have open communities contributing without fragmentation. There are far too many bugs that have languished for far too long in the bug parade. Opening up the source to more traditional open source models can only help in the long run. I know many people who are turned away by the relatively draconian licensing terms the source is currently under.

Anyway, to return to my original point, Sun's licensing is creating some awkward situations around the use and deployment of Java applications that serve no real practical purpose that I can see.  I think it's time to open it up a bit.

Software update

I haven't blogged anything lately because I've been trying to figure out what to do with my blog software.  Roller hasn't made me terribly happy.  It's been very quirky and seems to break a little too easily.  After some thought and too much hassle, I've decided to switch to wordpress.  It's enormously popular and has much better community support from what I can see.  It also has a handy RSS import so I could move over all my old entries.  A friend asked me if I was afraid to eat my own dog food by not using a java-based blog system.  I told him I'd rather have something that works with a minimum of fuss.  There are other things I'd rather do than beat on my blog software until it works.

So I switched to wordpress.  Hopefully, this will be much more stable and I can blog a little more frequently.

iReport 1.2 and Hibernate

I started playing with JasperReports'/iReport's HQL support today. I defined my hibernate datasource and added the hibernate annotation jars to my classpath. But when I try to define an HQL query in iReport, I get an error about needing an AnnotationConfiguration instance. Has anyone else played with this and figured it out?

Another failed roller upgrade

I played with upgrading to roller 2.0.1 last night. It went reasonably well in testing so I pushed it up online but things just didn't work so I rolled back to 1.2. Comments weren't working, layout was funky. I edited the templates and nothing changed. Just some real oddities. So I think I'm going to give wordpress a spin and see how that feels. It'll be sad to lose old entries but maybe wordpress will work better for me. Maybe I'll look into other blog systems like Pebble as well.

gizmo vs. skype

I finally signed up for an account with skype the other day and I'm pretty excited about the idea. (I know I'm coming late to the party.) But I was reading some random blog and the writer said he preferred gizmoproject over skype. Looking at the two, I'm not sure which is really better. Both offer apps to run on a cell phone to have VOIP goodness wherever you go. Both offer free calls to other service users. I'm not sure which I should spend my time with. Do I just stay with skype since I've already signed up? Do I switch to the gizmoproject? Should I use both? (That seems a little overkill.) Any suggestions?

IDEA 5.1

IDEA 5.1 has been released to much rejoicing. Well, I rejoiced at least. I've seen some occasional instabilities with 5.0.2 but I think I've traced it to cache corruption/staleness. IDEA would suddenly fail to parse my code and I'd get stack traces involving the PSI code in the error tracker. The workaround is to shutdown, delete the cache from disk, and restart. I don't think this is fixed in 5.1 as I just looked at the bug(s) entered against it but hopefully at least the Jetbrains guys are aware of it now. 5.1 is a bit snappier with some nice new features. You should definitely check it out.

RSS Readers

It's been a while since I've posted anything, but I did want to share a tidbit with you. I've been looking for a decent RSS aggregator for windows for the last week or two. Under KDE, I've been using akregator and been overall pleased with it (not to mention accustomed to its operation). So I've been trying to find something similar under windows. I think I've found it : RSS Bandit. It's a nice slick interface and is easily integrated with firefox though it does boast a built-in browser window, too. So if you're looking for a good reader, I'd definitely suggest you check out RSS Bandit.

EJB3 and Hibernate

Tonight at the Denver JUG the main topic was EJB3. While the spec isn't official just yet, it's as good as and people have started using it. The hibernate annotations developers, for example. I've been using these annotations for a while now on a couple of projects but I haven't really thought of them in the context of what's coming with EJB3. One of things coming is dependency injection from the EJB container. When the speaker mentioned this, it made much more sense of the dust up a few months back when the hibernate team started scrubbing references to IoC containers such as Spring from their website. Why bother with some other IoC when your parent (JBoss) is going to offer one. In one sense, this makes a little sense. On the other hand, EJB3's dependency injection doesn't really work outside the scope of the EJB classes. So if you want it for something that's not an EJB of one form or another, you're screwed.

I applaud the direction that EJB3 is taking: borrowing from RoR's example of convention over configuration, e.g. Having used that a fair bit with my Hibernate beans, I can say it's definitely a relief. The need for XML with EJB3 is almost nothing. The only XML the presenter used tonight was for the .par file (yes, another Blah ARchive) and that was for the datasource definition. It was about 7 or 8 lines. Nothing odious. A developer can use some XML to override the annotations at deployment time, if desired, but from how it appears, the XML is just about gone with EJB3.

EJB3 has some nice features that aren't really available in Hibernate, as far as I can tell, like extended transactions across calls for things like multiple step wizards. With the simple little example he went through tonight, EJB3 looks to be very very light indeed. The whole time I kept thinking, "These EntityBeans look like Hibernate POJOs." Which begs the question, "Why migrate to EJB3 if you're already using hibernate?"

And that's a fair question. There's not a lot of immediate value at first glance for sure. On the other hand, management of things like the SessionBeans and the like might be worth it. Integrated life cycle management from the container might be worth it. Overall, I didn't see a whole lot that says "Let's migrate!" However, EJB3 apps look more and more like how I've traditionally done Hibernate applications with some of the plumbing done for me. The one possible lack I see is the dependency injection being limited to EJBs only and no apparent way to plug in alternate implementations of those dependencies for testing. Have two DI mechanisms in place could get very messy, indeed. Perhaps the next version of the J2EE spec can address that. I haven't seen or used the new stuff enough to say whether that lack is real or perceived. Perhaps using the optional XML allows you to plug implementations. I'll have to wait and see.

Overall, I liked what I saw. EJBs certainly look a lot lighter than when I first saw 1.0 of the spec. And since EntityBeans are basically Hibernate POJOs (at least in JBoss' case), I'm halfway there.