Semmle, an original idea

lee esto en español

Semmle is a tool to make queries to our code similar to SQL. The following query:

from Class c 
where c.declaresMethod("equals") 
      and not(c.declaresMethod("hashCode")) 
select c.getPackage(),c

returns the results:

from the "framework" working space of my eclipse workspace (All classes that define an equals method but not hashCode).
".QL", an object-oriented query language, allows us to build our own classes to extend the query capabilities.
With a Metrics Library such as Lack of Cohesion of Methods and Afferent Coupling/Efferent Coupling, I only miss an ant task to add this tool to the continuos integration server.
Now, here's an original idea!

Yoda an the evil premature optimization

Please read this article from Ted's blog.

New annotation-based configuration for Spring

lee esto en español

As you know, there is a new option for configuring Spring. XML is the most widely used configuration option for Spring, but with this new configuration type, based on annotations, we could change some "xml hell". We'll leave in peace the Groovy configuration, at least for now.
The developers for example, could use this for some form of "inner" application wiring, leaving the xml configuration for infrastructure.
You may take a look at the project site for news, but imagine a xml like this:

<beans>
    <bean id="myCompany" class="package.Company"/>
    <bean id="employee" class="Employee" scope="prototype">
        <property name="company" ref="myCompany"/>
    </bean>
</beans>

you could do it this way:

@Configuration
public class AppConfiguration {
    @Bean
    public Company myCompany() {
        return new Company();
    }
     
    @Bean(scope = Scope.PROTOTYPE)
    public Employee employee() {
        Employee employee = new Employee();
        employee.setCompany(myCompany());
        return employee;
    }
}

later initiating an ApplicationContext with a ConfigurationPostProcessor bean, even mixing beans from both methods:

<beans>
    <bean class="package.AppConfiguration"/>
    <bean class="org.springframework.beans.factory.java.ConfigurationPostProcessor"/>
    <bean class="package.OtherClass">
        <property name="employee" ref="employee"/>
    </bean>
</beans>

Rod also shows us a new application context (by Costin Leau):

ApplicationContext oneConfig = new  AnnotationApplicationContext(SimpleConfiguration.class.getName());

and

ApplicationContext aBunchOfConfigs = new AnnotationApplicationContext("**/configuration/*Configuration.class");

We will leave to our imagination a even more dynamic configuration, mixing loops and if/thens in the configuration bean!
The code could be found here. Enjoy it!

New Spring 2.0 namespace

lee esto en español

A bit unusual way for configuring the Spring beans seems to be the one Rod Johnson reminds us in this entry of his blog.
Basically a new "p" namespace allows us to use XML attributes instead of nested properties to configure the beans.
What we usually do in this way:

<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans.xsd">

   <bean id="employee" class="package.Employee">
     <property name="company" ref="Company" />
     <property name="weeklyHours" value="35" />
   </bean>

   <bean id="company" class="package.Company" />

</beans>

We could do it like this:

<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:p="http://www.springframework.org/schema/p"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans.xsd">

   <bean id="employee" class="package.Employee"
       p:direccion-ref="company"
       p:weeklyHours="35" />

   <bean id="company" class="package.Company" />

</beans>

A small change that could make our XMLs more compact, although I don't know if more readable.

More examples here.

Sharing URLs

lee esto en español

Since is Monday today (I want to complain about something) and since I already read about it, I'd like to support an idea: it would be time that somebody put order to the hell of sharing URLs. What appears normally in blogs () is not sustainable. That each Web to share links have its own form to do it is so last century. I'm not saying to start a JSR for it, but some order would not be a bad idea.

Java web frameworks - Which one to choose?

lee esto en español

There is something impossible to do these days: choose a Java web framework. Is more a taste question than a technology question. And that's annoying. It makes the competence (read .NET) more easy to adopt. Which one of them must we follow for changes? In my opinion:

• Shale JavaServer Faces based.
• Wicket Web modelling... in java.
• Stripes Classic MVC, but with almost zero configuration.
• Seam EJB 3.0 based and a little too much JBOSS based.

Update: With the new Seam 1.1 it's possible to use POJOs outside an EJB 5.0 server. Even with Tomcat.

Technologies I would like to work with (I)

lee esto en español

One technology which I would like to use to do something productive (read: find a client who pays me to write an application) is JCR (Java Content Repository).
The JSR-170 specifies the way which we would use to communicate with the content repositories. The content repositories or "Content Management Systems" (CMS) like Documentum or Vignette, allows us to save binary or textual information without worrying about where it happens, might be a relational database or XML files.
But every vendor has his own product and his own way of access that information, that's why JSR-170 tries to fix the problem of standardization.
In the open source world, Apache JackRabbit is the reference implementation.
The information is organized as a tree of nodes, with each node having "attributes" or "properties" where to save the data. For example, to save information we do as following (example taken from here):

   Session session = JackrabbitPlugin.getSession();
               Node rootNode = session.getRootNode();
   Node blogEntry = rootNode.addNode("blogEntry");
   blogEntry.addMixin("mix:versionable");
   blogEntry.setProperty(PROP_TITLE, blogEntryDTO.getTitle());
   blogEntry.setProperty(PROP_BLOGCONTENT, blogEntryDTO.getBlogContent());
   blogEntry.setProperty(PROP_CREATIONTIME, blogEntryDTO.getCreationTime());
   blogEntry.setProperty(PROP_BLOGAUTHOR, blogEntryDTO.getUserName());
   session.save();

With this code we would manage to create a node, make it versionable (one of the JSR services), fill it with our information and save it.

You never know, in the near future I may convince somebody to use Jackrabbit. Wish me luck!

Pico and Spring

lee esto en español

PicoContainer, does somebody remember it? It's a components container that uses dependency injection. But it was left in the dust by the hurricane Spring, although it continues having their unconditional followers.
And so unconditional that sometimes it's used (as other technologies) simply because it's "what I know", leaving aside those "I don't know" but gives us many more features to our architecture.
But because nothing in this life is permanent (not even if you use hibernate), and because everything comes (even Java as open source), my friend Ale could finally "refactorize" an application changing Pico with... Spring (the post is in Spanish).