techno.blog("Dion")

How long does it take to setup your Maven >dependency<’s for a project that uses a lot of open source?

You find yourself following a chain of “X needs Y…” as you keep adding your dependencies.

What would be nice is to be able to write a script that takes high level tools (e.g. Spring) and builds the dependencies for all of the sub projects.

What would be even cooler is to have maven give it a go. You could say “I want Spring version X”, and maven will download all of the items that Spring needs automagically.

No more following the breadcrumbs.

I have been talking to a lot of people about metadata annotations. Although I think they are very useful, I also worry about annotation hell (which I see in some .Net apps).

I think that some people get confused between:

• “I wish I could see that a piece of configuration affected this class/method/field”
• “I want to be able to assign some metadata on this class/method/field”

We see this a lot when people move into AOP. People get scared that they can’t SEE that a cross cutting concern module is affecting their code. Some tools help out here, and they are only getting better.

I think the key is that I want to modularize the concern in one place. I want it DRY. Then, if I need to change something, I can do so in that one place, rather than throughout the code (the whole point).

However, people tend to want to put @CrossCuttingConcern on all of the areas in the code to GET AROUND the problem that they aren’t using a tool that shows them, or allows them to configure something at that point.

I think it is going to be interesting to see us mature more, and have views in our code which come from external areas. I should be able to change a pointcut in one place, and have my source view change if it now applies to different places (ADJT in Eclipse).

So, I hope to not mistake the urge to be able to view things, with the ability to assign them in the place that makes sense.

Matt has written about Trails – like Rails, but with Tapestry, Spring and Hibernate.

I put in a cheaky comment to see what a video on setting up a simple web application would look like. Matt thinks it would be 20 minutes long. That is on a good day, with no mistakes. Compare this scenario to the Rails demo.

Matt talked about how we seem to produce so many files in Java, due to the way we architect things:

model.Person
dao.PersonDAOTest
dao.PersonDAO
dao.hibernate.PersonDAOHibernate
service.PersonManagerTest
service.PersonManager
service.impl.PersonManagerImpl
webapp.action.PersonActionTest
webapp.action.PersonAction
web/pages/personList.jsp
web/pages/personForm.jsp

The last two JSPs can be generated, but that’s still a buttload of classes (9) just to CRUD (and test!) a database table. Not too mention all the files you need to edit for Spring and i18n.

dao/hibernate/applicationContext-hibernate.xml
service/applicationContext-service.xml
test/web/web-tests.xml
web/WEB-INF/classes/ApplicationResources_en.properties
web/WEB-INF/menu-config.xml

Ouch. Matt also pointed out that he has had requests to add support in AppFuse to generate all of these files for you. This would look good in a demo, but how about maintainence?

This is an issue with code gen in general, and one that you see a lot in languages like Java. Even with tools such as great IDEs (IntelliJ/Eclipse) and and code gen, that only helps when you are writing the code. What about reading it (which you do a lot more of in a applications life time (hopefully!)).

What I like about Rails is that it isn’t about code gen. It is about smart defaults which are extension points. For simple CRUD dynamic web sites the defaults can work well, and your application is done quickly. If you need to extend the functionality then you get in there and put in the extension points (in this case, you normally just create the right methods / objects).

I have always liked the mantra of:

make simple things simple, and hard things possible

I think that a lot of frameworks don’t allow this.

I also think that there is a HUGE difference between a dynamic website, and a web application, and would choose very different tools depending on which of these I am building.

There are many great choices out there.

Joe Ottinger has got out a rant of his own (are you are St. Louis fan? jk :).

He rants about Java from all angles:

• JVM: It sucks as it isn’t on every desktop
• API: “The API sucks for a lot of reasons. It lacks real focus, often providing multiple paths to a single end; Swing or AWT? StringTokenizer or Scanner? Date or Calendar? DOM or SAX? Reader or InputStream?”
• The People: He complains about some of the requests from Java users

I have an issue with some of the issues, mainly the complaints about changes to the Java language.

JAVA IS A PLATFORM!

Embrace other languages. Embrace other ways to express your ideas. There is NO perfect language.

NOTE: Joe, I agree with your memory management issues. I think you are correct. I just singled out ONE point, that although Java the language doesn’t need to be changed for everyones whim, I wish that Sun thought of Java as more of a platform (as .NET does), and puts more behind other languages, which allow people to express themselves in a way that makes sense to them. That is all mate :)

Although some people think that having billions of Java devices is a “business opportunity”, I also think it is a worry!

I shouldn’t say Java devices. What I mean is devices that are on the network. it is tough enough to manage viruses with a few million computers, but when we get to the next step when even your toothpick is bluetooth enabled? Yowser.

Vulnerability hits Java for cell phones

Ted has discussed avoiding the EJB fate in Indigo.

He gets into lightweight containers, and how he wants a “Pay as you go” situation (sounds familiar from the debates ;).

He has a feeling that the current crop of lightweight containers are already heavy and don’t allow this.

I have to disagree. If I want to start of with a minimal system I can literally create a a container (e.g. new SomePicoContainer(), setup a Spring applicationContext) and have minimal configuration for my needs (e.g. XML config, or in code).

Then, if you find yourself wanting to add functionality you grow your configuration and start to use more functionality. You don’t have to grab the full jar files if you don’t want to (if you are worried about that). You do pay as you go.

Pico/Nano may be even better in this regard. Each project has its own goals. PicoContainer is just that. It stays lean and mean and just does the one thing. Then Nano builds on top of that. It manages trees of PicoContainers, has support for services such as Hibernate, NanoWar, etc.

I am enjoying pay as you go right now!

A blog discussion has started on the subject of lightweight containers, and somehow changed to OR mappers at the end :)

Neward on Crupi

What is the state of the enterprise Java world, anyway?

I think there are some KEY differences with the recent move to lightweight containers.

The various tools that I seem to prefer these days have one thing in common:

Transparency

I think this is a huge thing. I think that so many projects have gotten away from core OO practices (and OO doesn’t mean distributed objects Ted!) because they were stuck with crappy EJBs. These applications were built using “patterns” of:

Stateless Session Bean – Entity Beans – which use DTOs

This isn’t OO. This is RPC. The entity beans often had simple mapping, and don’t allow for inheritence. DTOs are evil as they are a duplicate layer of structs that you are throwing around.

Note that I am talking about an application that isn’t a service. I am talking about building an internal application first, using good OO practices, and THEN you can lay on the service layer to allow for external stuff.

So, back to transparency.

IoC Containers

I can finally write code that is just POJO based. There are no extension points to the framework. I am not stuck extended evil EJB interfaces and classes, having to create “home” interfaces and such. This all gets in the way. Not only does it get in the way but not I am totally tied up in knots.

With a container like Spring you look at my code and would have no idea if I am using it! What if I want to move to something else like Pico or Hivemind? I can. My core business logic is in tact and I can go about my way of moving. I don’t sit around crying because I have to munge my logic from the coupling with the framework! I love it.

JDO, Hibernate, etc

I like transparent persistence (not that it is truly transparent due to the OO-DB mismatch… but it gets close). Once again, I can develop a full, rich, domain object model. The model can even have inheritence and interfaces, and maybe people will put in real business methods that do things instead of just gets and sets (gasp!).

Now with a marriage of these technologies I have a clean domain object model (transparent persistence), and clean services (lightweight container). Testing IS a lot nicer too in my experience Ted. You don’t need to run around finding or building bloody mocks for the environment.

2PC

I do agree with Ted in that EJB is good for some things, such as 2PC and Message Driven Beans. There is going to be a kick arse way to do MDB in Spring coming up soon, so that need will go away. What about 2PC?

Well, a couple of things can happen:

a) The lightweight container can support them
b) You use an EJB when you need to do 2PC! One nice thing about the lightweight containers is that they can be used WITH EJB too :) However, HOW many applications need 2PC? 2%? And then within those applications, how many of their transactions need to be 2PC?

If you can’t see that Spring isn’t nicer than EJB? Ouch. You must like eating the elephant ;)

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!

There has been a lot said about Struts. Most of what I hear is:

• It sucks! My pet framework is much better
• It is great! Although I have never used anything else
• It is good enough

I have heard the “it is good enough” a lot recently. This especially seems to come up when developers are on project where the requirement is to use Struts. “My boss told I had too”. “It is a corporate standard”.

I especially feel sorry when someone who writes a popular framework is forced to use it ;)

For a lot of people, they have grabbed this reality, and have chosen to make the most of it. This results in work such as Cobbie’s, in which has has adapters which allow him to use actions which work in WebWork 2, right in Struts. Add to this a nice testing framework, and other items (e.g. use SiteMesh rather than Tiles, using Spring, etc) and then it has you wondering. Is Struts that bad?

I think it is definitely usable. I mean people are coming up with good solid applications using Struts. However, I am not sure why I would choose it on a new project (other than for political reasons, or due to the staff [a group of Struts experts]).

I am lucky enough to be working on project where we got to choose the web framework. We can use Tapestry or WebWork and noone has cared. What a pleasure?

What is the future for Struts? I think it is destined to take a U-turn, or it will die in legacy. What is the U-turn? Make it work as that framework on top of JSF, which makes JSF usable ;)

Is the mobile industry large? massive. However it feels like a broken record when you read press releases such as: Nokia, Vodafone Collaborate on Mobile Java.

Jonathan and Sun seem to really want to talk about this stuff too.

I am not trying to say it isn’t important, but there are many other fish in the sea too. How about innovating in those areas? How about seeming like you care about the other communities (e.g. enterprise java in general, not just when accessing it via a phone :)

So much could be done.