Java

Java dependency injection just got better: Google Guice 2.0 has been released.

What's new:

• Provider methods. You can now annotate methods in your Module so you avoid manually constructing dependencies.
• Binding overrides. One Module can 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 Multibinder and MapBinder respectively.
• ServletModule now provides programmatic configuration of servlets and filters. GuiceServletContextListener can 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 Injector can 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).

You can download the new release here. The new manual is here. Now all they have to do is update the public Maven repository.

javax.inject.Inject

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.

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.

Hot on the heels of the announcement that Java can now be used with the Google App Engine, the Google Plugin for Eclipse has been released, supporting both Google Web Toolkit and Google App Engine development.

GWT Features:

• Recognition of inline JavaScript (JSNI): syntax highlighting, auto-indenting, Java Search and Refactoring integration
• GWT compiler shortcuts and configuration UI
• Wizards to create entry points, modules and HTML pages
• Support for GWT JUnit tests

App Engine Features:

• Easy deployment to App Engine
• As-you-type validation ensures that your code is compatible with App Engine
• Build projects and 'enhance' JDO classes automatically without the need for ANT

The user's manual for the plugin is here. The plugin works with both Eclipse 3.4 (update site) and 3.3 (update site).

I've been looking into developing Java applications using the Apache Wicket framework. Because of looking into this my Java Guru buddy, Brennan Spies, sent me a link to a good post on getting started with Wicket. I've been looking at it and so far it is Wicket Good (sorry for the lame joke)!

Below is an excerpt from the post.

Our first feature: 5 days of Wicket!

• Day 1 - Setting up the Project
• Day 2 - Writing the Tests
• Day 3 - Designing the backend
• Day 4 - Designing the Wicket components
• Day 5 - Putting it all together

Each day this week will feature a new blog article with an in-depth look at the creation process behind setting up a Java project and implementing the frontend with Apache Wicket. Enjoy.

You can read the full post here.

As of the time of this writing all five post are not finished, but they should all be up there within the next few days.

If you are a Java developer then you are probably always looking for good resources to correct errors. If you are like me you spend a lot of time using "the worlds greatest debugger" (a.k.a. Google), but it would be good to have an additional good resource that focused on Java errors.

Well, over at idError they have put together a large collection of Java errors and solutions to the errors. Currently, the site focuses on Java, Weblogic and Oracle related errors and more errors and solutions are added all of the time.

Below is what they say about the site.

This site has been started by a group of professional IT consultants with the scope of providing a very simple and fast platform to find Solutions for most of the Java related errors and problems.

The site is absolutely free, and we hope to maintain this for the years to come…

We depend on YOU to submit high quality solutions, but please note that we will review and edit the solutions in order to maintain a consistent quality.

The main question people are asking about this site is WHY they should use it when there are so many other web sites that deal with errors and solutions: most of the solutions presented on this site have been edited it by experienced programmers so you are more likely to find the correct solution to your error on this site, than on any other similar sites!

Please don’t forget to support the site by submitting solutions or comments to the already posted solutions. With your help we hope to establish a new standard of content quality for a FREE web site.

You can go directly to the site here.

The final version of Groovy 1.6 is now available for download. For those who don't know, Groovy is a scripting language hosted on the JVM with many of the features that Java programmers may find themselves missing--optional/dynamic typing and closures to name two--but with a syntax that is still very familiar for Java programmers. It is a natural complement to Java for tasks like GUI or web application development.

Beyond the many bug fixes and improvements in 1.6, the major focus of the release was performance, which had been somewhat of an Achilles heel for the language in the past--especially when compared to the more aggressively optimized JRuby. Groovy 1.6 sports a performance improvement of somwhere between ~150% and 460% (and yes, all the usual caveats about micro-benchmarking do apply), a solid boost that should mollify some of the performance objections to using the language.

Other useful features of the release include:

• The ability to create annotations in Groovy (previously had to be done in Java)
• Multiple assignments, e.g. def (a, b) = [1,2]
• Abstract Syntax Tree (AST) tranformations, which give the developer the ability to hook into the compilation process before code is turned into bytecode--examples include @Singleton for making a class into a singleton, @Immutable for making instances immutable
• Improved support for OSGi

Sun has released version 1.1 of the JavaFX platform, which now includes JavaFX Mobile (previous releases were JavaFX Script only). Partners listed for JavaFX include Sony Ericson, LG Electronics, Orange, Sprint, Cynergy and MobiTV.

The SDK and other tools (including the dedicated version of Netbeans 6.5 with the JavaFX plugin) are available from the JavaFX site.

The official Sun press release is here.

Sun has released the newest version of the Java runtime, Java 6 u12. Earlier versions of the language, Java 5 and 1.4.2, have also been revved to 1.5.0_17 and 1.4.2_19 respectively. Most notable in this release is 64-bit support as well as support for Windows 2008. There are also a number of bug fixes and performance enhancements (especially to JavaFX) as described in the release notes here.

You can download the new JRE or JDK here.

I ran into a problem recently while programming in Java where I wanted to define an interface method that returned a generic type which was tied to the type of the implementing class. If that sounds a little long-winded, let me give an example...

Let's say we have a Thing interface that defines a method for getting a type token, public Class<T> getType(). The Thing interface has several implementers, MyThing, YourThing, HisThing, HerThing, and so on. How does one make sure that T is the right subtype in the interface, which has no "knowledge" of its implementers (the same could be said of any base class and subclass as well)? Actually, the answer was sitting right under my nose in the core java libraries themselves, in the Enum class, whose declaration looks like this:

public abstract class Enum<E extends Enum<E>>

The E generic type looks a little confusing at first, like a kind of recursive definition. But when you think about it, it makes perfect sense: E is a subclass of an Enum type that is generified with the type--what else?--E. And E must be the appropriate subtype in any implementing class. So getting back to our little example, I could now retrofit my Thing interface to look like:

public interface Thing<T extends Thing<T>> {
     public Class<T> getType();
}

Any implementer now simply references itself in the generic type declaration:

public class MyThing implements Thing<MyThing> {
     public Class<MyThing> getType() { ... }
}

Most programmers prefer to think of generics only in the context of collections. But this provides a good example of how generics can establish type relationships in ways that are not possible in more traditional OOP methodology.