Brennan Spies's blog
Shortly after acquiring Sun, Oracle announced they would be dropping support for JavaFX Script, the domain-specific language that would have been the only way to write "Swing 2.0" applications. Instead, Oracle decided to start work on JavaFX 2.0, which would feature a Java-only API. The fruits of that effort were released today. You can download the SDK and code samples here.
Ever felt excited about a single line of code? Well this one
WebView view = new WebView();
did it for me. Since there are too many features to cover here, I'd recommend going to the web site or downloading the samples, launching ensemble.jnlp, and exploring.
When Ruby on Rails was all the rage a few years ago, it really shook up the Java community. Many people tried to understand the impact of Rails, what made it so appealing, and how its success could be translated into Java. As a result of all this soul-searching, lots of reasons were given for Rails' popularity, but the most compelling one was the fact that its fast turnaround allowed developers to stay in the "hot zone" while they were coding: make a change and--bam!--see it instantaneously. This was, at the time, the very antithesis of the compile and (re-)deploy cycle that Java developers were used to.
But how could this be done in Java? It was certainly no easy task: though Java could load classes dynamically, redefining their definitions during execution was entirely another matter. In 2002 Sun had introduced a promising experimental technology in to the 1.4 JVM called Hotswap that was incorporated into the Debugger API. The idea was that you could recompile your code while you were still in debug mode and have the JVM pick it up instantly without needing a restart, thus enabling all kinds of developer productivity. The problem was, though, that Hotswap was very limited--it could only replace the body of a method--and most of the time you needed to restart the program anyway, so the productivity never really materialized.
Well, years passed (imagine a tableau of changing seasons) and Rails, though still a popular framework, never really gained the larger foothold among developers that its initial trajectory promised. The buzz died down, and Java developers by and large stuck to their old habits. But the promise of greater productivity in Java still remained, and has inspired a few to pursue it...
One of those few is ZeroTurnaround, maker of the award-winning JRebel. (They've even released a free version recently, though it has a few string attached.) JRebel makes use of some pretty sophisticated classloading tricks (with just a dash of instrumentation) to accomplish dynamic reloading of class definitions: within the classloader, it uses one master class and several anonymous support classes backed by the JIT transformation runtime. JRebel has its limitations as well, most notably in the area of redefining class hierarchies.
JRebel is by far the most well-known product in this area, and presumably with the one with the most commercial success. But it does have competition...
There's another product, Javeleon, which also does dynamic redefinition of Java classes at run time. Javeleon has been developed at the University of Southern Denmark in collaboration with Sun Microsystems/Oracle as a research project. It also claims to have advantages over JRebel and FastSwap in what type of redefinitions it can support at runtime.
But you're thinking: shouldn't this type of functionality just be provided within the JDK itself?
Well that's exactly what another, less-known alternative does: the Dynamic Code Evolution VM. DCEVM is a modification of the Java HotSpot VM (applied directly as a patch) that allows unlimited redefinition of loaded classes at runtime. DCEVM was developed as a research project of the Institute for System Software at the Johannes Kepler University Linz, and supported by Oracle and Guidewire Software.
In my personal experience with DCEVM (full disclosure: it is the only product listed in this article that I have direct experience with), I've found it to be really rock-solid and dependable. The only drawback that I have noticed is that it has stayed at version 0.2 for quite some time now, and seems to be slipping in its support of newer versions of the JDK. Now that one of the leads of the project (Thomas Würthinger) is an Oracle employee, one would hope that Oracle would eventually integrate this into the JDK itself. This would give all Java developers access to the amazing productivity gains that class redefinition provides.
Class redefinition is really a no-risk technology: in the worst-case scenario, the redefinition fails and you have to restart the Java program to debug--something you would have had to do anyway. So you really can't go wrong in upgrading your current option (Hotswap) with something far more capable. You won't just be saving yourself those reboots: you'll also be keeping yourself mentally in the "hot zone" where true productivity is found.
Proxy4J is a Java library for creating proxies. The project has recently released a stable snapshot (I'm not going to consider it "1.0" until the remoting is done). I originally created Proxy4J as a spin-off from my development on Workhorse, mainly because I wasn't really satisfied with other libraries out there that do proxying (the Commons Proxy library was the closest I could find, but its inability to leverage Java 5+ made it a non-starter).
Proxy4J was designed to allow you to quickly create a proxy for any one of a number of common use cases:
- Virtual Proxies. Also known as delegation proxies, these proxies simply pass the method invocation directly to the "real subject", which may have some indirection in how it is created or fetched (e.g. the classic lazy-loading proxy).
- Invocation Handlers. These are a direct parallel to proxies in the JDK, with a slight twist to include type safety in the common case where only one interface is being proxied. Method calls on these proxies are passed to an invocation handler which decides how to handle the call.
- Interceptors. These are proxies where one or more interceptors may get called prior to invoking the method on the "real subject". In Proxy4J interceptors are very granular and may be specified on a per-method basis.
Interceptors in particular are pretty slick: they allow you to keep a stack of MethodInterceptors (note that the library supports the AOP Alliance API), which are invoked in order prior to invoking the intercepted method. Proxy4J allows different underlying implementations, including CGLIB, Javassist, and the built-in proxying in the JDK itself.
The much anticipated Firefox 6 release is out. In keeping with its new Chrome-like strategy, Mozilla has done away with large, major releases and is instead releasing on a faster, more "agile" schedule, releases batches of features and improvements as they get fully baked.
So What's New?
- Mozilla claims that Firefox 6 is 20% than Firefox 5. This is a nice speed boost.
- Added support for EventSource (server-sent events). This API permits push notifications from the server in the form of DOM events.
- A touch event for touch-sensitive screens.
- Support for the latest draft of WebSockets.
- The result of a media query string can be evaluated programmatically using the window.matchMedia() method.
- Support for HMTL 5's
progresselement has been added.
- Support for HTML 5's
trackelement has been added.
- A host of
-moz-*CSS properties for styling progress bars, text decorations, and hyphens.
The release notes are here.
- Provider methods. You can now annotate methods in your
Moduleso you avoid manually constructing dependencies.
- Binding overrides. One
Modulecan now override the bindings in another.
- Private modules. You can now create bindings that are not externally visible, in order to encapsulate your dependency injections.
- The ability to inject members of sets and maps using
ServletModulenow provides programmatic configuration of servlets and filters.
GuiceServletContextListenercan be used to help bootstrap a Guice application in a servlet container.
- Custom injections. Guice now includes hooks that allow other frameworks to define custom injection annotations. This enables Guice to host other frameworks that have their own injection semantics or annotations.
- A tree-like structure for
Injectors, i.e., an
Injectorcan have children that inherit all of its bindings.
- An introspection API: like reflection but for Guice bindings.
- Pluggable type converters that convert constant string bindings to other types, i.e., Dates, URLs, etc.
- OSGi compatible. Guice now works well in OSGi managed environments, because AOP-generated classes use a bridge classloader.
- AOP is now optional, so Guice will work on platforms that don't support bytecode generation (Android).
On related news (Crazy) Bob Lee, the creator of Guice, and Rod Johnson, the creator of Spring, have gotten together to propose a standard set of annotations and interfaces for using dependency injection in Java under the banner of JSR-330: Dependency Injection for Java (still only a proposal, so JSR-330 is a tentative moniker). There is also a corresponding project over at Google Code. The standardization should greatly help the use of dependency injection in shared 3rd party libraries, allowing the application developer to avoid having to initialize more than one dependency injection framework.
These annotations are modelled closely on those currently in Google Guice:
- @Inject - Identifies injectable constructors, methods, and fields
- @Qualifier - Identifies qualifier annotations
- @Scope - Identifies scope annotations
- @Named - String-based qualifier
- @Singleton - Identifies a type that the injector only instantiates once
The utility interface
Provider is also in the proposed specification.
Plugins and extensions for Google Chrome have arrived. As of developer build 188.8.131.52 of Chrome, the browser is now extensible. A page showing how to create extensions recently went up on the Chromium project documentation site as well as some samples--including a Gmail checker. A recent developer release is required to try out the functionality.
The main document page for Chrome extensions is here. Support for extensions is still very early stage, so they are not yet ready for general consumption.
You can view the list here. My favorites? The Structure and Interpretation of Computer Programs, Thinking in Java, Programming Ruby, and Communicating Sequential Processes. But I haven't read all of them--yet :).
The first "stable" release of Clojure has been announced. Clojure, a dialect of Lisp built for the JVM, is one of the few languages with built-in Software Transactional Memory (which I describe in more detail here).
There is also a TODO list of desired features targeted for the 1.1 release.
You can download the 1.0.0 release here.
After living on my hard drive for a few months, I finally decided to give my new project a home: http://code.google.com/p/workhorse/ (I literally checked in the initial code today). It's very alpha right now, but the general ideas are starting to take shape.
What is WorkHorse?
WorkHorse is a BPM engine written in Java. It is meant to be both lightweight (i.e., embeddable) and powerful. By the time that I am done, I hope to prove that you don't need to force-fit BPM into BPEL, or even have a heavy-weight XML process description layer at all.
The idea for the project originated with some of the concepts/ideas in BPMN, which I like, though I recognize its weaknesses. Workflow (I am using the older, less trendy term) is a natural fit for so many types of applications, but it often seems that developers avoid it because existing solutions are too cumbersome: they force you to run them on some proprietary server, or they are simply a headache to configure and embed in your existing application.
Can WorkHorse alleviate this headache? Stay tuned.
Oracle announced today that it will buy Sun Microsystems for $7.4 billion, finally ending Sun's search for a suitor. Oracle, a heavy investor in Java technology even prior to its purchase of BEA Systems, was a natural choice after Sun's courtship with IBM failed. As the resident "Java guy" around here, I'd be remiss if I did not share some of my own perspective on the big news.
First, the things I see as being positive:
- This is good for Java, at least the perception of Java in the marketplace. Fair or not, there are many people who equate business success with quality (just ask your friendly SharePoint administrator). A nose-diving Sun stock price did not do much for people's perception of the viability of Java as a platform going into the future. Oracle's stewardship should improve this dramatically.
- Like IBM, Oracle has always done a much better job than Sun actually making money on Java. Of course one could speculate endlessly on the reasons why (one invariably hears the fuzzy term "marketing"), but the fact remains: Sun executives chased the buzzword of the day while Oracle executives made money. In what reminds me of Apple in the late 90's, this is not uncommon in "R&D-oriented" companies; they just don't seem to learn how to sell the technology very well.
- Solaris. Long viewed as one of the best flavors of Unix (featuring DTrace and ZFS, to name a few cutting-edge technologies), Solaris is the other crown jewel that Oracle picked up in the merger. In the conference call following the announcement, Larry Ellison specifically named Solaris as one of the reasons for the move. Since both Oracle and Weblogic already run on Solaris, owning the OS itself opens up some possibilities for Oracle.
- Having followed Oracle's acquisition of BEA, I was generally impressed by the fact that Oracle did not automatically favor its own product lines over BEA's. In fact, a lot of careful thought seemed to go into which technology Oracle would adopt going forward. I hope the same will be true for Sun.
And now the less positive:
- Consolidation. Consolidation is usually a good thing for vendors (at least the winners), and not so much for customers. There is, of course, less choice and inevitably some "cool stuff" that you wanted to last forever winds up in the dustbin.
- MySQL. The MySQL community is unlikely to be very happy about the merger, given its traditional positioning as a cheaper alternative the the dominant database vendor. Personally speaking (and I'm no expert on the database market), I think that MySQL occupies a different end of the market than Oracle does, one which the the database giant would be foolish to ignore. Oracle is likely to keep selling Oracle database to its "Fortune 500" customers while also selling MySQL support to lower-end customers running LAMP stacks. The good news is that MySQL will remain a light-weight database. The bad news is that "enterprise features" are likely to fall off the development roadmap.
- Glassfish. Sun was doing some very interesting work with Glassfish, and it's hard to say what will happen to the project in the wake of the Oracle purchase. Will it simply get nuked in favor of Weblogic? Glassfish has not yet seen huge adoption in the marketplace, so it may not have the same argument in favor of it that MySQL does. There is a big question mark hanging around its neck now--which is a shame because Glassfish is the kind of light-weight JEE server that could really be a game-changer if marketed properly.
- Hardware. Sun is still very much a hardware company (at least in terms of revenue); Oracle is not. It's hard to say what will become of some of Sun's high-end hardware business after the acquisition. Personally, I think that Oracle will try to sell it off to a more hardware-oriented company in order to mitigate the cost of the buy.
Of course, this is all just speculation, and it is fun to speculate at times like these. One thing, though, is for sure: in the face of a bad economic recession, the market for enterprise technology will continue to consolidate.