techno.blog("Dion")

I have a fun and busy couple of weeks coming up:

TheServerSide Symposium

This week I will be in Vegas for the 3rd TSS Symposium. It is always a pleasure to see everyone, have some good geek talk, and some drinks ;)

I am going to be presenting on AJaX technology, Groovy, and may even be on a panel ;)

Microsoft Developer Technology Summit

I am really looking forward to the Microsoft summit, with the likes of Matt Raible, Ben Galbraith, and everyone else. It will be really interesting to see what Microsoft has to say to us, how they pitch it, etc. I am going to soak up having the time to spend looking at Indigo and the like.

I was even going to see if Don would like to bring in his kids to do some Ruby, but I guess now It’s down to Scheme or Logo :)

AOSD

AOSD is in Chicago this year, which is nicely down the road. I will be chairing a panel, and spending time with great guys to discuss libraries for AspectJ 5, which I am really excited about.

All, in all, a great few weeks! I hope to see some of you there!

Erik Hatcher has published a Meet Lucene online presentation (slides + audio).

The presentation is a nice introduction to Lucene. There are still a lot of people out there who do not know about this open source gem, and if you haven’t had a chance to check it out, watch this.

One of the best reasons to watch it, is that you learn what Lucene IS and ISN’T. I still find that people assume it is a web crawler, rather than a search API.

This is great news. After the debacle of the first round of voting, today we had the revote.

Many expected that the initial vote was the death of JDO, but this have thankfully been proven to be premature and false.

There was a large outcry from those inside the JDO community, and even those that are external to it. From talking to the EC after the vote, it was apparant that the “NO” voters were not actually voting against JDO, rather against the timing (around xmas), not knowing about how it fits with the JSR 220 persistence spec, and the process in general.

Kudos to the JCP EC, who listened to the community, and then made their decision.

The different thoughts are shown in the comments:

Regarding the letter, and the JSR 220 agreement

Intel: voted Yes

An agreement between the Spec Leads of 2 Expert Groups is not binding on the Executive Committee. That said, the extra time for review has demonstrated that the JSR 243 Public Draft is consistent with the “letter” from the Spec Leads so there is no problem there in any case. In similar situations in the future, it would be better to use the usual process of initiating a new JSR rather than a letter from Spec Leads. That would provide more transparency and involvement of the community.

SAP: voted Yes

SAP thanks the JSR 220 and JSR 243 Spec Leads for the additional clarifications that were provided for this reconsideration ballot. We are satisfied with the clarifications regarding the future roadmap of EJB 3, JDO 2 and the new J2SE persistence model that is being developed as part of JSR 220 and therefore do not see an impediment for JDO 2 to proceed. Given that JSR 220 has the challenging goal to deliver an overarching persistence strategy for Java, it is important that the interests of all existing persistence communities, including JDO, are equally represented in this Expert Group.

Regarding the process

Intel: voted Yes

An agreement between the Spec Leads of 2 Expert Groups is not binding on the Executive Committee. That said, the extra time for review has demonstrated that the JSR 243 Public Draft is consistent with the “letter” from the Spec Leads so there is no problem there in any case. In similar situations in the future, it would be better to use the usual process of initiating a new JSR rather than a letter from Spec Leads. That would provide more transparency and involvement of the community.

Abstainers

Last time around, I felt that some of the EC should have voted ‘Abstain’ rather than ‘No’. This time, the abstains have come in as veiled No votes, and strongly try to put across the message of “I guess we will allow the tiny JDO community continue while we take on the world” :)

JBoss: Abstained

Since this newly proposed specification is essentially identical to the one proposed during the Public Review Ballot vote, we would see no reason to change our vote, hence our previous comment remains.

However, while this vote is fundamentally a NO vote, we cast it as an ABSTAIN to acknowledge Sun’s role in trying to clarify the situation through their FAQ, and most specifically the central role of persistence in the JSR-220 specification and in the Java platform as a whole: “The new persistence API as defined by JSR 220 will be the standard Java persistence API going forward.”.

This JSR-243/JSR-220 discussion, initiated by some JSR-243 proponents, has only brought disruption on the JSR-220 side and no sign of flexibility on the JSR-243 side. This could give the feeling of a coup to slow down the JSR-220 EG.

The J2EE/EJB specification set represents the significant part of today?s Java ecosystem. Hence, in order to remain competitive, it is critical to make sure these specifications don?t get disrupted.

Oracle: Abstained

Oracle’s primary concern has been partially addressed with the FAQ published by Sun reiterating that JSR 220 is the intended standard Java persistence API moving forward. Given the clear direction set by Sun on this issue, we will not object to the evolution of the specification to serve the existing JDO community. It is vital that the persistence work in JSR 220/EJB 3.0 for the mainstream J2EE community not be disrupted. EGB 3.0 is making excellent progress as part of the umbrella J2EE 5.0 specification and has been well received.

Favourites

Of the votes, I think my favourite has to be:

Apache Software Foundation: voted Yes

Let a thousand flowers bloom :)

BEA: voted Yes

After further review, BEA has concluded that there is a vibrant JDO community which needs this specification, regardless of whether we are successful in achieving an overarching persistence strategy. As a result, I see no reason to hold this community hostage to a goal that may or may not be achieved.

Vote Results

Yes (12)

• Apache
• BEA
• Borland
• Doug Lea
• Fujitsu
• Google
• HP
• IONA
• Intel
• Nortel
• SAP
• Sun

Abstain (3)

• JBoss
• IBM
• Oracle

UPDATED NOTE: Apple didn’t vote as the EC member was on vacation :)

Time to move on

Now it is time to move on. JDO 2 can continue its great work. We can work with the EJB team to help out there too, and everyone is a winner.

See the results of the vote

The last in the 1.1.X versions of Spring has been released. Now the Spring team is onto the Hibernate 3 support (good timing), and JMX.

Spring Framework 1.1.5 Announcement

Hi everybody,

I’m pleased to announce that Spring Framework 1.1.5 has just been released.
This is the last bug fix and minor enhancement release in the 1.1.x series, featuring many minor improvements such as:

* added overloaded “reject” and “rejectValue” methods without default message to Errors interface and BindException
* added “lookup(name, requiredType)” convenience method to JndiTemplate, matching the JNDI object against the given type
* added “homeInterface” property to AbstractRemoteSlsbInvokerInterceptor,
for specifying the home interface to narrow to
* introduced MailMessage interface as common interface for SimpleMailMessage and JavaMail MIME messages
* Log4jConfigurer accepts a “classpath:” URL or a “file:” URL as location too, not just a plain file path
* Log4jConfigurer accepts config files that do not reside in the file system, as long as there is no refresh interval

* added “int[] batchUpdate(String[] sql)” method to JdbcTemplate, for executing a group of SQL statements as a batch
* added C3P0NativeJdbcExtractor for C3P0 0.8.5 or later (for earlier C3P0 versions, use SimpleNativeJdbcExtractor)
* added “maxRows” bean property to JdbcTemplate, allowing to specify the maximum number of rows to be fetched
* added “fetchSize” and “maxRows” bean properties to RdbmsOperation, passing the values to the internal JdbcTemplate
* added ClobStringTypeHandler, BlobByteArrayTypeHandler and BlobSerializableTypeHandler for iBATIS SQL Maps 2.0.9
* ResourceHolderSupport throws TransactionTimedOutException if no time-to-live left (before attempting an operation)
* TransactionSynchronization objects can influence their execution order through implementing the Ordered interface
* JtaTransactionManager is able to work with a JTA TransactionManager only (i.e. without a UserTransaction handle)

* upgraded MockHttpServletRequest to Servlet API 2.4 (added getRemotePort, getLocalName, getLocalAddr, getLocalPort)
* upgraded MockPageContext to JSP API 2.0 (added getExpressionEvaluator, getVariableResolver, overloaded include)
* added “contextOverride” option to
ServletContextPropertyPlaceholderConfigurer, letting web.xml override local settings
* added “searchContextAttributes” option to ServletContextPropertyPlaceholderConfigurer, resolving context attributes
* added “clear” and “isEmpty” methods to ModelAndView, allowing to clear the view of a given ModelAndView object
* added JasperReportsMultiFormatView, allowing to specify the output format dynamically via a discriminator in the model
* JSP EL expressions in Spring’s JSP tags will be parsed with JSP 2.0 ExpressionEvaluator on JSP 2.0 (Jakarta JSTL else)
* changed “spring:transform” tag’s “value” attribute from String to Object, to allow for expressions resolved by JSP 2.0

See the changelog for details.

Our next milestone is 1.2 RC1, which we intend to release as soon as
possible: with Hibernate3 support, JMX support and further major new features. Nightly 1.2-dev snapshots with Hibernate3 support and JMX support will be available within a few days, so feel free to give 1.2 an early try
:-)

Cheers,
Juergen

Well, Matt has done his job on blood boiling :)

He has run with the comment from one person on this blog which claims slow performance of Rails.

We all know how bad random performance claims are. After all, I think we should show that a Rails PetStore app is a lot faster than “J2EE” ;)

Look at the apps that are written using Rails, and there are more and more showing up on the mailing lists. If it was so slow then they would be shouting about it.

Tadalist and co, all seem to run very nicely from my end too, and I have never experienced a problem with a Rails app.

It is also pretty easy to scale most web apps that people are building. How many are truly ‘enterprise apps’ that people like Mike Spille work on :)

Let’s stop the mud flinging a la ‘JVMs are too slow. How can you not write this in C!’ and let people make their own mind up with testing on their own apps!

My guess is that if someone gave it a try they would be very impressed with the productivity gains, and the app would surely run ‘fast enough’ ;)

All the love is for Cocoa. Why does Carbon get such a bad rap? I never looked into it much, but just last week a friend talked about how he thought Carbon was a poor mans solution, until he actually spent some time on it too. And, he found that it was actually not a bad solution, especially with the Java bindings.

James Duncun Davidson has also just written that Sometimes Carbon isn’t so Bad.

Hibernate 3 has been released, with good timing around the JBossWorld conference.

It is good to see the 3.0, which has features I am interested in… mainly:

• More flexible mappings for the times in which I can’t quite get Hibernate 2 to do what I need.
• Hibernate3 filters
• Unchecked exceptions
• Hibernate Tools
• Second-level cache browser
• XML integration

Now we need to test the hell out of it, and see what version is ready for production. You can’t expect Hibernate 3.0 to be as production ready as the mature 2.x branch which is battle worn.

Many congrats to the Hibernate team.

Full Release Notes

Hibernate 3.0 is the world’s most sophisticated ORXM
(Object/Relational/XML Mapping) solution. Hibernate3 makes it easier
than ever before for Java applications to interact with persistent
data, allowing a single definition of the transformation between
various in-memory representations of the entity data and the relational
schema, even in the case of very complex legacy schemas and schemas for
historical data or data with visibility rules. Hibernate3 also provides
the most comprehensive object/relational query functionality, with
three full-featured query facilities: Hibernate Query Language, the
newly enhanced Hibernate Criteria Query API, and enhanced support for
queries expressed in the native SQL dialect of the database.

Compared to Hibernate 2.1 – the most popular object/relational mapping solution in any language – Hibernate 3.0 offers:

• Much more flexible O/R mapping: support for exotic association and
  inheritance mappings, and greater flexibility when working with legacy
  data.

• Hibernate3 filters: a unique feature for working with temporal (historical), regional or permissioned data.

• Unprecendented flexibility for mixing handwritten and generated SQL
  within a single application or even a single entity: full support for
  “derived” entities and attributes defined in the mapping document, full
  support for overriding any generated SQL statement with handwritten
  SQL, support for stored procedures.

• Object/Relational/XML mapping: query XML directly from the database
  for reporting, replicate data between databases via intermediate XML,
  externalize entity data as XML when interacting with remote systems.

• Enhanced ease of use: better defaulting, an unchecked exceptions
  model, simplified natural (and composite) key support, simplified CMT
  integration.

• Enhanced Criteria query API: with full support for projection/aggregation and subselects.

• Runtime performance monitoring: via JMX or local Java API, including a second-level cache browser.

• Brand new AST-based HQL parser: bulk update/delete enhancement, better syntax validation.

• JBoss EJB 3.0 preview: support for annotation-based O/R mappings,
  full support for EJB-QL 3.0, support for EJB 3.0 persist()/merge()
  lifecycle, JACC-based security model.

• Hibernate Tools preview: a full suite of Eclipse plugins for
  working with Hibernate 3.0, including mapping editor, interactive query
  prototyping, schema reverse engineering tool.

• Many new extension points: including a new, extensible, event-driven architecture

• Documentation enhancements.

• Brand new test suite, including many useful examples of exotic Hibernate mappings.

I really liked the XOR Linked List hack by Don Schwarz.

The sun.misc.Unsafe class is really scary, but it is interesting to know that it is there (at least on Sun JVMs).

Apart from anything else, it makes you feel happy that you don’t have to do any pointer crap anymore.

Don’t first public showing of the class was in Avoiding Checked Exceptions.

He has got a lovely twisted sense of humour! :)

I had to laugh with this from Chris Poirier:

That all said, I’ve been writing lots of Ruby over the last few years, so my ability to recognize [what is] natural for Java programmers is pretty much nil.

Later,
Chris.

P.S. Yes, “nil” was an intentional joke. :-P

Brian has written his second part article, Rails for Struts-ters, Part 2: The Views.

As the title implies, he goes into detail, comparing the view side of Struts vs. Rails. If you grok Struts, you will understand the rails side from this.

It also clears some myths such as “Rails doesn’t have SiteMesh capability” which I have heard from quite a few Java developers.

Rails Layouts

Final thing to look at in views is layouts.
The quasi-official tool for this in Struts is Tiles, but I prefer Sitemesh, so will use a sitemesh example.
Rails has Layouts, which are the same conceptually as Sitemesh decorators. Here is one

<html>
<head>
<title>Brian and Joy's Wedding</title>
<link href="/stylesheets/scaffold.css" rel="stylesheet" type="text/css" />
</head>
<body>
<%= render_menu %>
<%= @content_for_layout %>
</body>
</html>

The layout gets wrapped around any rendered output, with the output going at the <%= @content_for_layout %> point.
The easiest way to use a layout for all views is to just have a layout named application.html, and it will be used implicitely.
You can explicitely use a layout by declaring it in the controller, a la

class GiftController < ApplicationController
layout 'scaffold'
before_filter :require_logged_in

which will have it look for scaffold.rhtml to use as a layout. Sitemesh uses an external XML file to configure these, under typical usage, but it is conceptually the same.

Great stuff Brian!