Hibernate Tools 3.2.0.beta6 (http://tools.hibernate.org) have been made available.
As always the tools are for both Eclipse and ANT.
It was actually released a couple of days ago, but a holiday got in the way of announcing it before now.
The big news for this release is that it is now compatible with Eclipse 3.2 and WTP 1.5,
so we have hereby joined or are least compatible with the
Eclipse 3.2 has some new interesting extension points that we have made good use of to e.g. provide HQL code completion and validation inside the java code.
See screenshots and other noteworthy news here for more information.
On a side note, JBossWorld (as always) allowed me to get in contact with alot of users of the Hibernate Tools more directly and that was tremendous fun and interesting - Thanks. I got a lot of new input for new features and enhancements that should make it into future releases.
In the spirit of
stages of grief, these are the
stages of adoption of new software development techniques:
UPDATE: Hopefully this does not look too much like a bite of Gartner's Hype Cycle.
- Stage 1, Rapture: The
shiny new toyphase, where we first discover a new idea, and realize how powerful it is. As we get confident, we start trying to use it for /everything/.
- Stage 2, Disillusion: Inevitably, as we start trying to apply this new approach to more and more complex and obscure problems, we start to run into cases where it doesn't quite fit - either because the expression of the idea (the current implementation) is still immature and imperfect, or because in our excitement, we're simply misapplying it.
- Stage 3, Insight: The shiny toy is now just another gadget in our toolbox. We finally have the experience to know when and when not to use it. We understand not only the limitations of the idea, but also /why/ the limitations exist.
The earliest release of Seam was a whole year ago, and Seam is now I guess the fastest growing framework in Java (500 downloads each day and rising). But the ideas in Seam - contextual components, state management, conversations, BPM - are still new to most people and the Seam community is still in the process of understanding exactly how and when to apply these ideas. This is actually the most exciting phase for a project like Seam. I loved the early days of Hibernate, when the community was still developing the patterns (and finding the language for describing those patterns) that are now formalized into books and examples and known to most enterprise Java developers.
Today I got an email from a user who had just hit Stage 2, Disillusion. He asked:
- If is best to use page flows or is normal JSF navigation in faces-config.xml enough?
- Is there a one sentence explanation on how to use @Begin and @End? I think most of my problems are due to misunderstood and invalid usage of conversations.
I spent more than a year thinking about conversations and optimistic transactions and designing Seam's conversation model before I actually sat down and wrote my first two Seam example applications a year ago. Even so, I got it wrong in both cases! I actually managed to screw up the conversation model on the first release of our beloved Booking demo. My lame-ass excuse is I was trying to illustrate the /idea/ of conversations, while keeping the actual conversation model extremely simple. But of course the worst way to illustrate the power of an idea is to misapply it. Mea culpa.
A year later, I think we're finally at the point where we can start to formalize a set of rules of thumb on where to use conversations, where not to use them, where to begin them, where to end them. We now have the hard-won practical experience to go with the idea and its implementation.
It's very difficult to define a correct state management model without interaction with the users. The first thing we need to understand is how the users want the application to work: what tasks should be multi-taskable, what pages need to be bookmarkable or exchanged in email, when should work become persistent, etc.
My first stab at
when should I start a conversation? is the following:
Start a new conversation if you are at page X, and:
- the user is expected to want to navigate to page Y using
open in new tabor
open in new window, and
- you want some state that is retrieved while rendering Y to remain in memory on the server, but isolated to the tab or window.
We need to supplement this with the following additional rule:
- If page X already has a conversation, and page Y needs access to the state held in X's conversation, then make it a nested conversation. Otherwise make it a whole new toplevel conversation.
Well, those rules are really just a restatement of the definition of
nested conversation. They don't really tell you anything you didn't already know (though it is perhaps a more friendly formulation). What we really need is a characterization of the kinds of things that X and Y can be. So, when I'm developing frameworks, I really need to think about the following canonical cases:
- Search/list screens: these let the user find and navigate to the entity instances they are interested in. Search screens often support sorting.
- Item detail pages: these let the user view not just an instance, but also associated objects. Sometimes these pages can be complex views driven by a treeview control and requiring lazy fetching of data possibly via AJAX.
- Edit/association management pages: these pages implement simple optimistic transactions that let the user atomically view and update an entity instance, and possibly change its association to other entities. I'll throw create and delete functionality into this bucket for now, though these should strictly have their own categories.
- Wizards: I'm not just thinking of simple linear flows here, but rather of any interactions where we guide the user through a series of steps that form a single unit of work. In fact, a
wizardcan even be something as complex as a treeview control where the user can edit data from a toplevel object and its child objects spanned over several different pages, lazily fetching data and caching edits in memory on the server, and then finally make all the changes persistent in one atomic
The answer to my Disillusioned user's first question is simple: /only use jBPM pageflows for wizards/. The stateless navigation model is much more appropriate for our other canonical cases.
But I still havn't satisfied his request for a
one sentence explanation of when to use a conversation. Instead, I'll try to sketch out a set of steps to take when designing a disciplined state management model for an application:
The first thing to consider is the search or list screens. These are extremely important, since they are the entry point to all application functionality. We need to decide where to
put the search result list. Alternatives include:
- keep their result list in a conversation - this is usually overkill
- keep the results in the session context - not good if the user needs to be able to run multiple simultaneous searches
- go stateless (use a redirect with request parameters and pull MVC) - the advantage is the results can be bookmarked; the disadvantage is that we canít easily cache the search results, which might slow performance if the user is allowed to sort and reorder the result list
- put the results in the page context (which is serialized to the client) - this can mean quite a lot of serialization overhead
On balance, my preference is for statelessness most of the time, but it depends upon the needs of your users. Session scope might be what they prefer (this is what we use in the Booking demo). Conversations don't usually have a place here.
STEP 2: When we navigate from a search screen to an item detail page, a similar choice space exists:
- keep the item in a new conversation
- stay stateless (request parameter and pull MVC)
- use the page context
Now the balance swings toward using a conversation, especially if we have some kind of complex object and need treeview-style navigation. (In this case, conversations give you transparent lazy association loading and all that good stuff.) But if bookmarkability is a requirement, statelessness is again the best choice.
Now we start getting to edit pages, association management pages, create/delete and the like. We are in the world of optimistic transactions, and so conversations rule. The main decisions revolve around conversation propagation: nested conversation? new conversation? stay in existing conversation? This depends upon how much the user wants to use
open in new tab!
Finally, wizards should always run in a conversation. In fact, it is highly likely that you want to use the
atomic conversation pattern where changes are kept transiently in memory on the server side until the conversation ends. Some wizards should use pageflows. (Remember I am using an extremely broad definition of
Hopefully this discussion helps the path from Disillusion to Insight, without scaring away the many people who have yet to experience the Rapture.
Norman Richards (super-smart/thoughtful guy doing product management stuff at JBoss) has posted a download of the Seam hands-on lab from JBoss World. This is a nice way to get started with Seam, and much more interesting than listening to me rant on about conversations and state management and unified component models for an hour and a half...
(Warning: it's a bit enormous because it bundles the appserver!)
Usually I don't like to climb into these kind of discussions - I usually keep quiet unless I have something more to add than
metoo. But forgive me for mentioning that, on balance, I agree with the many people arguing that bundling Derby in the JDK is a Bad Idea. My concern is that this decision naturally forces projects like Hibernate to have to support Derby, no matter what our better judgement as to the maturity/stability of the product at this stage. Perhaps if/when Derby has shown itself to be a truly production-ready platform, this decision could be better justified. But for now, Derby is neither usable in production, nor is it really a good choice for development (HSQL is much more usable at development time, and that is what 95% of people are using).
It would be really nice if Sun would reconsider this decision. Perhaps the solution is simply to offer two different download bundles, one with Derby, one without, and Let The People Decide :-)
UPDATE: I'm also amazed that Sun would want to risk sticking the word
Java on this product. Like the
Java Desktop, it seriously risks devaluing the brand.
Last week thousands of people downloaded Seam 1.0 and tried it out. Inevitably, they picked up on a couple of bugs of the
minorish variety. At the same time, I was getting some useful feedback from users who are already developing and/or deploying Seam applications at JBoss World. Finally, Roger Kitain from Sun reported a problem running Seam on GlassFish. So, I needed to do a 1.0.1 release:
This release has been properly tested on GlassFish.
Note that if you are using JBoss AS, Seam requires JBoss EJB 3.0 RC8. The best way to get the right versions of everything is to use the JEMS installer here:
(I know that this caused some hiccups for some people.)
Of late, the pressure on us has been to stop throwing in new features, and focus on stabilising the platform, so that people can feel confident using Seam in production. I think we are finally there now. I'm really happy with some of the applications I'm seeing built in Seam: you can really see the difference in user experience between a traditional web application and a Seam application with conversations, AJAX, business process management, etc. I was especially impressed with the workflow application built by JBoss Innovation Award winners Lexicon Genetics in just a couple of months. Doing something like that without jBPM and Seam would be a seriously much bigger undertaking. And they are pushing the limits of the environment, and helping feed me new ideas for Seam.
The Seam project is proud to announce the release of JBoss Seam 1.0 GA, an application framework for Java EE 5. Seam aims to be the most productive platform for development of enterprise and rich internet applications in any programming language.
XML hell that plagues Java frameworks designed for use with J2EE by leveraging Java 5 annotations for declarative programming.
Seam 1.0 introduces the following new features:
- Seam Remoting - an AJAX-based remoting layer for EJB 3.0 components and JMS (created by Shane Bryzak)
- Support for JSR-168 compliant portal engines such as JBoss Portal
- Elegant handling of internationalization and JSF messages via EL-based interpolation
- Helper components for JMS senders/publishers
- JSF tag library
- Redesigned XML-based configuration facility
- Support for integrating databinding architectures
- Eventing architecture for loosely-coupled components
- Seam Logging
- JBoss Cache integration for cluster-wide state replication
- Experimental Drools integration
- Compatibility with the Java EE 5 reference implementation
- Much more...
As usual, the best way to learn about Seam is to check out the example applications. Start with the registration, numberguess, booking, blog, dvdstore and chatroom examples.
Get it here:
The Web Beans JSR was approved unanimously by the JCP executive committee. You can read the proposal here:
We've already received a bunch of expert nominations from companies and individuals, and so I'm sure we'll be able to form a very talented expert group over the next few weeks. If you're interested, the nomination form is here:
This is the first time JBoss (or even Red Hat) has led a JSR, so we are very excited about this opportunity to serve the Java EE community!
Now that the dust is starting to settle from JavaOne it is time to explain what the announcement from JBoss about joining and endorsing NetBeans means in context of Hibernate Tools.
The core of Hibernate Tools have always and will always be independent of any IDE; these are available via our <hibernate-tool> Ant task.
Hibernate Tools for Eclipse will still be developed and improved. At JBossWorld we will have a release with new features and it will be compatible with Eclipse 3.2 and WTP 1.5 (Callisto), and for the brave the nightly builds should soon be the Callisto-based version.
In other words we are not moving away from Eclipse, we are simply recognizing the great work that the NetBeans community have been doing especially with respect to Java EE 5 tooling.
Thus for NetBeans and Hibernate Tools we gladly accepted a contribution from Leon Chiver which brings some of the Hibernate Tools for Eclipse features to the NetBeans platform, primarily the HQL editor (thank you Leon). We expect to also release a preview of this around JBossWorld.
Already with the initial contribution we have created a shared code set for the HQL code completion which actually resulted in merging both of best worlds and improving the functionality in both the Eclipse and NetBeans plugins.
We plan to align the feature set of the IDE tooling with help from the
community and have the plugins share as much code as feasible to allow contributions in both
camps to benefit each other. I look forward to hear from you what features you want the most.
There is more news coming and if you are curious come and hear more about them at JBossWorld Las Vegas. I and others from the Hibernate and JBoss IDE Team will be there.
No /Hibernate in Action/ anymore. It has been a while since my last update on the book status, so here is a heads up. A lot of things happened in the past three months:
- The planned Hibernate in Action /Second Edition/ was more than a second edition. There was so much new content to write and add that we could no longer call it a new
edition. It is now a new book with more than 90% new content, compared to Hibernate in Action, and with a new name, /Java Persistence with Hibernate/.
- The beast is currently at 700 pages, with the last chapter still incomplete. In printed form we expect it to be somehwere between 750 and 800 pages. This is mostly due to two factors. A) Hibernate 3.x has just so much more features than Hibernate 2.x and we wanted to have all of them in the book. B) Java Persistence described in parallel, with all annotation mappings, EntityManager and so on - they are all very similar to Hibernate native, but it needs space.
- The book will be published by Manning, we also have a book page and a cover. We will post a TOC on that page soon.
The Manning book page currently says
publishing date November 2006. I think we can do better than that, we are actually in the last stage of reviews and should go into copy edit and production in a matter of weeks. I know that a lot of you wanted to have this earlier, but there was just too much to write. Also, things like the removal of FlushMode.NEVER from the JPA specification (well done, Oracle) forced me to rewrite dozens of pages and introduce application design based on auto-commit mode. Now that the specification is final, I could commit and stabilize these sections.
I will release another alpha or beta of CaveatEmptor and a sample chapter next week. Watch this space.