Archive for the ‘spring’ Category

New in q4e 0.6.0

I was planning to write a “q4e 0.5.0 released” post later today, but since Carlos has already done so, I will fast forward one whole version :-)

My goal for 0.6.0 will be to abstract q4e from the JDT and make it a little smarter along the way. Smart enough to know what kind of project you are creating/importing and set up your workspace accordingly.

This includes many fronts quite probably I won’t be able to cover them all in one release, but at least the way will be paved for 3rd party plug-ins that can add support for other languages (like scala) and other plug-ins (like springide and wtp).

So… yes I’ll try to move closer to supporting wtp. I know many of you are just waiting for this… and we’re listening.

What other things would you include in your wishlist for 0.6.0?

Cover for The Mithycal Man MonthI while back, I read The Mythical Man-Month. The data in chapter 8 of the book (which is by no means recent) points out that the average productivity for a developer, measured in debugged lines of code per year is almost constant.

The interesting part here is that it is constant even when changing languages.

The data compares LOC written in low level machine code and those written in a high level language (PL/I). Because every line in PL/I was on average generating 5 low level instructions, this mean improving developper productivity by a factor of 5.

Fast forward 32 years… and now I’m here wondering if the rule still applies.

I guess the answer is yes, and that’s why everyone is so happy with languages like Ruby and concepts like convention over configuration, which allow you to write less.

But then… Spring must be a huge productivity boost, since it is quite coarse grained. You’re not avoiding code… you’re doing more with less code. Same thing for Hibernate.

Less LOC, more function.

To be fair… this is more related to component reuse (called “buy versus build” in the book) than to higher level languages.

Then there are the DSL (Domain Specific Languages) that are starting to pop up everywhere. Specific high level languages for specific problems (like configuration, business rules, etc…). Those should really cause a big impact in productivity if they can be used in a significant part of a project. I’m under the impression that DSLs are used for relatively small parts of a system (maybe BPEL would be the only one able to have a wider scope).

So why aren’t these new languages/frameworks used everywhere? Why are they not taught at computer science faculties?

It’s related to the intellectual load imposed on the developer.

Lower level languages can do any thing with a reduced set of commands (functions, operations… you name it). The developer needs to know very little thing about the language but needs to figure out how to do every little thing. Just imagine how a simple hello world program would look in assembler.

In the other hand, higher level languages require knowledge about lots of commands and features. Put in the mix a wide collection of extensions (or libraries) and integration with other high level languages, and the intellectual overhead is just barely manageable.

Maybe at this point is where we start creating standards. J2EE is not the best of the options (JSF, EJB…) but is a standard. A developer can learn it and have a pretty good grasp of everything without being overloaded with too much information.

However, most companies are using other kind of tools, like Spring or Hibernate (although Hibernate now can be used with JPA, so it can be seen as a standard). And every project/company uses a different presentation framework (we have plenty to choose from in the java world).

And then there is Eclipse RCP, Grails, Jython… and outside the java world you always need some Bash, Perl (at least Perl regexps)…All this tools make something easier and faster, but they add to the pile of knowledge a developer requires to do his job.

Under this stress, how can we remain productive and still be able to create working solutions in our jobs?

I don’t know. But we certainly do.

And from time to time, they are not only working… they are good! :-D

First contact with Spring RMI

For years, I’ve been surrounded by components using Java RMI, but never ever needed to implement anything using it. So when chance came, I went the Spring way, as I knew it had support for transparently exposing beans through RMI. And it already was a declared dependency for the project.

I read the docs. It looked easy: create a pojo, declare a bean and publish the bean.

But it is not that easy. Doing that will only expose a Spring-specific wrapper, which non-Spring clients can’t use (incidentally, the RMI clients weren’t using Spring).

What annoyed me a bit is how deep is this information is buried in the manual. It is at the end of the chapter in a section called “Considerations when choosing a technology“, in a paragraph discussing Spring HTTP invoker:

Note that HTTP invokers are not only limited to Java-to-Java remoting but also to Spring on both the client and server side. (The latter also applies to Spring’s RMI invoker for non-RMI interfaces.)

There’s no reference to this limitation in the section devoted to RMI. Of course, once you know the story, you can see this paragraph on the introduction as a warning:

Remote Method Invocation (RMI). Through the use of the RmiProxyFactoryBean and the RmiServiceExporter Spring supports both traditional RMI (with java.rmi.Remote interfaces and java.rmi.RemoteException) and transparent remoting via RMI invokers (with any Java interface).

After googling around and looking in the forums, I learned that using RMI with Spring boils down to one of two options:

  1. You can transparently expose any interface through RMI, as long as both ends use Spring to encapsulate the RMI communication.
  2. You can create a class extending java.rmi.Remote, where every method throws java.rmi.RemoteException. Doing this, your RMI service can be consumed by any RMI client, but you:
    • Explicitly depend on RMI.
    • Need to use rmic to create the stubs and distribute them with the server.

If you’re interested, because of the requirements for the clients I had to go with option 2.

Spring documentation is excellent (specially compared with other popular open source projects) and this issue is a minor one, so don’t read this post as a bash against Spring.

I’ve just learned from MaintainJ on TSS, and it looks like a cool idea.

In brief, it is able to instrument your code (using AspectJ for that, so no code modification is performed) so it writes calls to a file, which is then used to build class and state diagrams. And it does this from within Eclipse.

The cool part is that you get the real classes being used. If you model your code using interfaces (which you probably do if using any kind of IoC container like Spring), this shows the real implementation class being used. It also shows the real calls being made, so  you can test any use case and get a nice state diagram for it. Which looks great documentation-wise.

Although it is clearly cool, I’m not sure about how useful it really is. I suppose it depends on the documentation your development process requires.

Appfuse 2.0, sweet!

Appfuse vanI must admit that I had never tried Appfuse 1.0 because of my laziness. It required me to download something, install it somewhere and then run ant on it… too many things just for giving it a test ride.

But the new 2.0 version is just a piece of cake. No installation needed. Just use your Maven tool and generate a template project from scratch. There are several templates available, depending on your particular taste.

Let me clarify that, even when I call them “templates”, what you get is a working webapp (you can even run it from the command line, without installing anything else). The webapp does not do much… but is actually good looking and provides a log-in form and user management features (two things you will likely need).

By now, only milestone 2 has been released. Milestone 3 will come later and, at last, 2.0… in “late” 2007.

I expect (time permitting) to dig a little deeper on it… And you should too.





Follow

Get every new post delivered to your Inbox.