Sep 30

Spring 1.1.1 Released

Tech No Comments »

What was that about a new Java release?

There is a new Spring point release! :) :)

Dear Spring community,

I’m pleased to announce that Spring Framework 1.1.1 has just been released.
This is a bugfix and minor enhancement release.

Among the new features in this release are:

* “import” element for XML bean definitions
* support for non-public classes and non-public init and destroy methods
* bean factory regards bean references for correct destruction order (not requiring “depends-on”)
* bean factory detects JDK 1.4 and Commons Collections for linked/identity map creation
* factored out the “publishEvent” method into the ApplicationEventPublisher interface
* included new “test” package in mock JAR, offering superclasses for tests requiring Spring contexts

* added “applyQueryTimeout” method to the JdoDialect interface
* added “addAttribute” and “getAttribute” methods to RemoteInvocation
* explicit support for EHCache via EhCacheManagerFactoryBean and EhCacheFactoryBean
* SimpleMessageConverter102 handles BytesMessage without JMS 1.1’s “getBodyLength” method
* added JmsGatewaySupport convenience base class

* added ServletForwardingController and ServletWrappingController
* BindStatus and BindTag can be created without Errors instance in the request too
* changed MessageTag’s “arguments” attribute to Object
* added “javaScriptEscape” attribute to MessageTag
* added EscapeBodyTag aka “spring:escapeBody”

As always, have a look at the changelog for details.

Cheers,

Juergen

Sep 30

Evil Java Command Line Options

Tech 3 Comments »

I had to laugh when I read about the new openGL command line option.

There are two different options: true and True. As in:

To silently enable the OpenGL-based pipeline, specify the
following system property on the command line:

-Dsun.java2d.opengl=true

To receive verbose console output about whether the OpenGL-based pipeline is
initialized successfully for a particular screen, specify “True” (note the
uppercase T) :

-Dsun.java2d.opengl=True

In fact, I have always been a little bothered with the command line options that we get with Java commands.

I am from the GNU school that says:

There are short hand options, and long hand options.

Short hand options use one – sign. Long hand options use two –.

I don’t know HOW many times I type:

% java –version
% java -v

before I get to the correct

% java -version

I would have much prefered to have -cp and –classpath for example. I wish they followed that convention. I also want java –help to show me all of the possible options (including X options for a particular JVM?)

Oh well. Maybe it is just me!

Sep 29

JDJ 2004 Best Foreward?

Tech No Comments »

I just heard from Addison-Wesley that Effective Enterprise Java has been nominated for the JDJ Reader’s Choice Awards in the category of “Best Book Foreward“; if you enjoyed or are enjoying the foreward, you can guess what I’m going to say next…..

Sorry, couldn’t resist Ted :)

Sep 29

J2SE 5.0 final release is available for download

Tech 7 Comments »

Tiger has finally come out of its cage.

Sun has announced the General Availability of J2SE 5, which includes JDK and JRE 5.

Download it (and try not to fall for the “Damn it, they got me to download NetBeans!” trap :)

It is annoying that when I tried to install this final release it complained telling me to uninstall my RC version. Why doesn’t the installer do that! Grr.

Sep 28

A Groovy Reader: Bloglines Web Services

Tech No Comments »

Marc Hedlund has written about the new Web Services APIs that Bloglines recently announced.

This article will take a look at the new Bloglines Web Services and their effect on the RSS/Atom landscape. We’ll look at the bandwidth issues surrounding RSS/Atom aggregators, and how the Bloglines Web Services help to conserve bandwidth; then examine the APIs and what they offer; and finally, present a complete, three-pane desktop RSS/Atom reader written in just 150 lines of code, using the Groovy programming language.

It is cool to see the Bloglines new services, and how quickly Marc could whip together a 3-pane GUI using Groovy!

Sep 28

Keeping track of the new Persistence effort because you DO care

Tech 1 Comment »

I am really excited about the new persistence effort that Sun have been able to push for.

It is so obviously important to have one persistence API. I mean. Come on.

Although I am excited, that doesn’t mean that I am blind. I know that many people really are ready to have a go and work together on this. However, it is as important as ever for the community to watch over this and make sure that a fair, and best solution comes out of the process.

This feels a little like the Bush administration have managed to make us feel about what they are doing. Their marketing folk have done an amazing job to make the public feel that you have to blindly follow Bush and co, else you are not patriotic.

This is evil. There is nothing un-patriotic about wanting to know the truth, and keeping on top of what is happening. In fact, it is unpatriotic to blindly follow.

So, why the hell am I spewing politics? Well, for one, I am so mad at what is going on in the world… and for two, because I don’t want the same to happen with the JCP.

Firstly, I don’t think that the JCP is as bad as the current administration :)

However, just because The Right Thing has happened, and all groups are looking in the right direction, that doesn’t mean we can switch off.

The community needs to watch what comes out of the JCP with respect to the persistence API (and everything else). What are your concerns? Are they met? If they aren’t (or are) please participate and let the expert group know.

Let’s all get together and make this process be the best that it can. I have no doubts that we can come up with great standards if we all play in the game!

Sep 28

New and improved My Yahoo!

Tech 1 Comment »

I have always liked My Yahoo! Even though the world has moved to RSS, I still pop over to my.yahoo.com from time to time. It has a really nice view of my stuff. Movies, Flights, DVDs, as well as news.

A BETA RSS module was released a few months back, but that is nothing compared to the new version of of My Yahoo! itself.

You can: Migrate to the new My Yahoo!

It is now a content framework. You can grab anything you want. I really like the UI which allows you to visualise your page and move things around with drag and drop. Very sexy :)

For RSS, I still like NewsGator though. It comes in like email. Pull vs. Push.

Rael Dornfest of O’Reilly has a good entry on it

Sep 27

Information on Java Closures from Guy Steele of Sun

Tech No Comments »

This thread gives us an insight into why full closures aren’t currently in Java:

> Actually, the prototype implementation *did* allow non-final
> variables to be referenced from within inner classes. There was
> an outcry from *users*, complaining that they did not want this!
> The reason was interesting: in order to support such variables,
> it was necessary to heap-allocate them, and (at that time, at least)
> the average Java programmer was still pretty skittish about heap
> allocation and garbage collection and all that. They disapproved
> of the language performing heap allocation “under the table” when
> there was no occurrence of the “new” keyword in sight.

I find this very ironic. It is too bad that programmers who do not use
Java *because* it doesn’t have closures were not asked about this
issue, instead of those programmers who were already willing to make
such a compromise. This decision insured that this potential new
audience’s desires will not be met.

Interesting indeed. I do hope that in the future people are polled again on their usefulness. A lot of us were C/C++ programmers when we started on the Java bandwagon and were really worried about the heap and such.

Now many of us have moved on and have gotten into languages such as Ruby/Groovy/insert your favorite and have been able to evolve our thinking.

(Of course, some of us were LISPers from way back, and this was, like, duh :)

Sep 27

Consilidating Spring Config with Groovy

Tech 2 Comments »

When working with Spring, have you noticed yourself doing a lil copy/paste in the applicationContext.xml?

I have seen a fair share on different projects.

For example, you wrap your DAO model with the transaction proxy, and the config is the same for each.

One of them looks something like this:

<bean id="UserDAO"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager">
<ref local="transactionManager"/>
</property>
<property name="target">
<ref local="userDAOTarget"/>
</property>
<property name="transactionAttributes">
<props>
<prop key="add*">PROPAGATION_REQUIRED</prop>
<prop key="set*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>

<bean id="userDAOTarget" class="com.foo.dao.UserDAOImpl">
<property name="sessionFactory">
<ref local="sessionFactory"/>
</property>
</bean>

Instead of duplicating the code for every object in the model it would be great if there was Groovy support so you could do something like this:

modelBeans = ['User', 'Auction', 'Bid', ..]
txRequiredMethods = ['add*', 'set*', 'update*']

modelBeans.each { | beanName |
builder = new SpringMarkupBuilder()
markup = {
bean(id="${beanName}DAO", class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean") {
property(name: 'transactionManager') {
ref(local: 'transactionManager')
}

property(name: 'target') {
ref(local: "${beanName}DAOTarget");
}

property(name: 'transactionAttributes') {
props {
txRequiredMethods.each { | txMethod |
prop(key: txMethod, value: 'PROPAGATION_REQUIRED')
}
}
}
}

bean(id="${beanName}DAOTarget", class="com.foo.dao.${beanName}DAOImpl") {
property(name: 'sessionFactory') {
ref(local: "sessionFactory");
}
}
}
}

Of course, many other solutions would help out here.

UPDATE: And Colin has one :)

As Matt mentioned in a comment, Colin Sampaleanu has a great solution.

Sep 25

JDO and EJB join forces: The cat is out of the bag

EJB, JDO, Java, Tech 5 Comments »

The official announcement will come out of Sun on Monday, but the cat is out of the bag.

Firstly lets look at the facts:

  • A new spec/RI/TCK is being created UNDER the JSR-220 (EJB3) umbrella
  • This new spec will be based on the persistence API from the EJB 3 early draft
  • The scope is for a persistence API for BOTH J2SE and J2EE (so it will work outside of a container)
  • JDO experts have been invited to join the EJB team to grow it from here
  • The final spec will be available in the same time frame as J2EE 5
  • The JDO 2.0 spec will continue. It will now add the ability to externalize JDO-QL so it can be used from the new persistence API

I am really hopeful with this situation. A lot of the folks on the JDO camp are NOT all about JDO… they just want a transparent persistence model that isn’t stuck in a container. Now it looks like this is going to happen, and the EJB folk are on board too. If this is done right then it will be a huge win for everyone.

Although I am really excited about the potential, the proof WILL be in the pudding, and I have a couple of concerns:

Where it lives

In my mind there were three options for placing a spec which holds a persistence API for J2SE and J2EE:

  1. JDO: Since this spec kinda has that mandate already, it could have lived here. A reason for doing this would be that there are already users of this API. A reason for not doing this is that there are already users of this API.
  2. EJB 3: It seems a little strange to have a spec that covers J2SE in an EJB spec umbrella, but they have done work on this themselves. I would argue that more work has been done with JDO 2, but hey, let’s move on
  3. New JSR/Group: I know it would have taken more time to come up with a new JSR, but I would have ideally wanted this. A new group would have been formed and it would have set the tone to be a brand new collaboration. As it stands some people are skeptical that the JDO folk will be listened too. I am really hoping that everyone gets their say and that we get a great spec.

Pluggable Persistence

EJB specs have always talked about the idea of a Persistence Manager, and hinted that at some time this will be pluggable. JDO specs have had this notion from the beginning.

I *really* like the fact that JDO plays nice with the J2EE CA, so I can deploy whatever persistence manager I want by throwing a RAR at my application server. This seems like a no brainer on what it should be.

I want to be able to run WebLogic Server with IBM’s persistence manager. Well, I don’t really want that combination, but I want the flexibility.

From what I have heard on the grapevine, the new persistence API may not have the pluggable contract which really bugs me.

Why wouldn’t they define this? The only reason in my opinion is that application vendors don’t want this as they obviously want lock-in.

Please, please, please open up and allow the best persistence managers to fight it out in the market.

Finish on a positive note…

Overall I am really excited on this new bold move from Sun. Kudos to them for getting together and working out that this makes sense for the community. I really hope that in practice this works out and we get a great persistence API that everyone is happy with. My few worries above are only mentioned in the vein hope that people think about these things and we do the right thing.

Let’s get to work!

Update:

Jason has good comments:

Any idea if it’s still going to be dependent on 1.5 with annotations? And are those annotations going to be defined and jar’d in the j2ee.jar? Will I have to compile against the j2ee.jar or a vendor jar and either ship with the j2ee.jar or deploy in a container just to get the annotation classes?

I really hope that since this sub-spec is meant to target J2SE, that there is no need to ship j2ee.jar. Surely!