Showing posts with label java. Show all posts
Showing posts with label java. Show all posts

2.04.2008

Chased by the statically typed ghosts

It looks like statically typed ghosts are out there again. They like to chase the Poor little dynAmiCally typed Man. Most of the time, the ghosts run faster than the little Pac-Man but their bloat makes them crawl when they turn corners or go in tunnels. Little Pac-Man goal is to clear the level in the most efficient way. Little Pac-Man has some special features to help him mind his business. For each level that he has to go through, he can use specials pills. These pills allows him to open up the ghosts and mixes in some different behaviour into the ghosts. De-routed by this ability, the ghosts turns blue. Little Pac-Man understand that this power comes at a certain price, this is why he uses it sparingly and do not abuse it to eat the ghosts (unless he knows he can eat them all in one shot as this will make him score big-time!) as they will quickly return to their static behaviour. As we can see in the picture, it takes four (4) ghosts to take on Pac-Man.

3.23.2007

Oracle acquire Tangosol

It looks like Oracle just acquired Tangosol! This must be great new to Cameron Purdy... I guess it was a long deal in the making.

I always feel kinda mixed up when I see great small Company acquired by huge companies. The vision of the Davids is often being blurred by the Goliath's. Can't wait to see Cameron's post on his blog to get some more details on this acquisition and what it'll mean to Tangosol.

3.08.2007

Running application instead of application servers


Most of the time, Java web application are deployed on their own instance of an application server. Within shops that uses server virtualization, this approach is extended to have one virtual server per application. This is done to ensure that an application will not adversely affect another one running on the same physical server.

However, application server products always assume that you may deploy many application on the same server. Configuring the application server is then a lot more complicated than what would be required to configure just one application.

If most of the time we deploy only one application per application server, why do we not bundle application server in our application instead of installing application server and then configuring our application on top of them?

Here how I would see how it would work :
  1. Develop the application as usual (deploying the application on an application server),
  2. Use some tool provided by the application server product to create an installation/update package :
    1. The tool would have a Wizard like interface (but you would also be able to run from the command-line after saving the settings from the Wizard),
    2. It would ask for which application to deploy,
    3. Based on the application deployment descriptor, it would preselect application server features that needs to be available,
    4. Provide an interface to select additional application server features to activate,
    5. Ask for default configuration parameters for the application (datasource, ...),
    6. Generate an interface (web, fat, console) to configure that application when installing/updating it,
    7. Generate the necessary installation script,
    8. Package the whole thing into a platform specific package (DEB or RPM for Linux, MSI for Windows, ...),
  3. Install/update the application on the targeted environment using the generated package.

Using this approach has the following benefits :
  1. Smaller installation footprint. If the application server does not need to be installed with all it's feature activated, then they should not be installed,
  2. Easier installation/update process for those who have to maintain the system,
  3. Easier configuration has only configuration options required for the application will be exposed.


Food for thoughts...

1.24.2007

j2ee_util.rb public release

I just released my first public version of j2ee_util.rb : Simple tool to manage your J2EE archives (war, ear, jar, zip). Not long ago, I had to make quick changes in a web.xml file contained in a WAR file contained in an EAR file. To do that, I had to extract the EAR that extract the WAR then edit the file then repackage everything.

The process is a bit cumbersome and prone to errors. Yet, I never saw a command-line utility that allows one to do that. So I decided to write my own and j2ee_util.rb was born.

With this command line tool I can now type this to edit the web.xml file :
ruby j2ee_util.rb --edit my-application.ear:webapp.war:WEB-INF/web.xml

And when I exit the editor, the file is automatically repackaged in the WAR file which will be repackaged in the EAR file. The tool also only extract the specified files instead of the whole archive.

I plan to add a few features to be able to edit stuff directly from the command-line (like replacing a value in an XML file) without having to fire-off an editor.

If you use the tool and have any comment/idea/issue with it, fell free to leave a comment on this post.

12.22.2006

2007 Predictions

Everybody doing it! Not wanting to be left in the cold, I will follow the herd and make predictions for 2007.

RoR will run flawlessly on a Java Application Server

The good people from JRuby are making incredible progress since they've been hired by Sun. We will soon be able to run RoR applications with no (or very little and trivial) modifications on Glassfish or other Web Container. Will that makes RoR application more scalable? I'm not sure. But it will increase RoR momentum in Java shops. When you talk about RoR to a java shop, the first question they have is "Will it run on Tomcat|WebLogic|WhebSphere|...?"

JRuby will take the top spot for scripting the Java platform

To the demise of Groovy, JRuby will take the spotlight. The main reason is the previous prediction. Once you can run RoR on a Java application server, nobody will need Grails. Grails is the only use of Groovy that create adoption.... Unless some other killer Groovy application, tool or framework is created.

RoR adoption continue

That's a fairly conservative prediction. RoR as a lot of momentum.

Java 6 adoption will start slowly in Q3

While Java 6 is out. It's adoption will grow slowly and will mainly be driven the scripting language support. Java 5 had many compelling reason to get adopted by many shops, but many many many application are still running on Java 1.4. Beside scripting support, there is nothing compelling enough in Java 6 to make it's adoption within the enterprise faster that Java 5.

Something will happen in Java build tool space

A lot of people are tired of Ant . Maven is cool, but lacks flexibility. Scripting language is getting more attention... We have Gant, Raven, JRake and many other existing or yet to be created build tool that use scripting language. By the end of the year, one of them will start getting a lot of traction. My best guess for now is Raven.

Java Specification Requests will become less and less relevant

The JCP is not working very well. It's too lengthy. Design by comity does not work well. Many JSR do not stand the sand of time. Today JSR mostly reflect some existing API with less feature (JPA vs Hibernate for example). They do not offer innovation, they just tend to seal mature innovative technology in the platform. New language features takes too long to traverse the JCP and with the open sourcing of Java, it will become easier for one group to add new feature to the language and to make a Java distribution of it's own. And with JSR like JSR-277 that create more turmoil than solve any problem, more and more people loose interest and faith in the process. Sun is not even interested in really supporting existing JSRs. We have a JSR for Groovy, but Sun hire the JRuby developers without giving any resource to Groovy. That's it! I made my prediction for 2007. This is probably my last post of the year, I will try to post a bit more often next year! In the mean time, have a Great Christmas and a really Happy New Year!

11.28.2006

DB2 JDBC Driver hate my Date!

It's been a long time since I worked on a project that uses DB2 for the database. I always preferred DB2 to Oracle because it consume less resources (and it's much easier to install) on a developer machine.

But today I hit a strange issue...

I need to create a query that has a condition on a DATE column in some database. So my Java method that needs to do the query, I receive a java.util.Date argument. This method uses Spring-Framework Hibernate templates to do the query. Basically my query looks like this :

getHibernateTemplate().find("from Stuff s where s.effectiveDate <= ?", today)

I run a unit test that uses HSQLDB and every thing is fine.

But when I ran the same query in the application running on top of DB2, I got a nice SQLException from the DB2 JDBC Driver. The cause of the exception is :

com.ibm.db2.jcc.a.SqlException: DB2 SQL error: SQLCODE: -301, SQLSTATE: 07006, SQLERRMC: 3

The specified SQLSTATE says that this has something to do with data conversion. Huh! I have a DATE column and I pass a Date object! That should be fine (actually it is fine with MySQL, Oracle, HSQLDB and probably many other).

After a googling a bit, I found out that DB2 (the JDBC Driver) expect to receive either a java.sql.Date or a java.sql.Timestamp (depending on the type of the column). So in my case, I had to pass a java.sql.Date.

The fix is simple, I just have to create a java.sql.Date when doing the request :

getHibernateTemplate().find("from Stuff s where s.effectiveDate <= ?", new java.sql.Date(today.getTime()))

In my opinion, this is insane! It is the JDBC driver job to convert the passed data-type to something the database can handle.


10.25.2006

added: Emmanuel's Development References search engine

I've just created a new search engine using Google Coop. You can start using it on by entering search terms on the search box on the right.

You may also add it to your browser's (Firefox 2.0 or IE 7) search engines.

This search engine is customized to search Java, Ruby, Rails, Hibernate and Spring Framework API and reference documentation. More API and reference documentation for things that are in my area of interest will be added in the future.

10.19.2006

JSR-277: At last... a module system for Java!

The early draft for JSR-277 has been made available. This is good news! We will have a module system for Java. Its a bit late in the game... Ruby has a module system (GEM), Perl has CPAN, Linux has many... Why did it take so long to have one for Java? Maybe it did not itch that many people. But then why would the Maven team choose to create a repository for dependencies management, it must have itch!

I did a quick read of the specification... And here are my first reaction :
  1. Great! A module system for Java... At last, Java application will be easier to install and we will have a dependable versioning system,
  2. Why do I need to specify in the module definition all the classes that are present in the module? Maybe I did not understand the value of the "members" definition, but I guess that everything inside a module should be a module member. I see no reason to duplicate that information,
  3. I could say the same thin about the "class-exports". Why does the module system need this? It could use class visibility modifiers to do the same thing. I can see a bit of value if it was there to suggest the main entry points and/or API of the module. It should be optional,
  4. There is no use cases on how to install and manage existing module using tools. The specification says that it does not specify any tools. I believe that local repository management tools are a must and should be provided and made standard. At least a command-line tool should be specified. Just like we have a standard specification for using the "java" command even if it has implementation specific options.
Overall, I think this is great news. It does come a bit late and will not be available unto Java 7. But this will still be a great improvement over the current situation.

10.18.2006

Ant without the XML

Yet Another Build Framework was announced today on The Server Side. Gosling is much like Ant (according to the website, it's a fork of Ant) but without the XML. For a start, this is good news. Instead of using XML, you use Java to code your build script.

Do we really need another build framework? Sure writing build script in XML is not very convenient and has its limitations. But we have Maven2. Maven2 is still XML, but it is not build script that you write in XML, it's just your project configuration. Maven2 is the perfect implementation of DRY for your build script. After more than 10 years of Java existence, why would one still have to write in is build script the steps required to produce a JAR file?

Does this mean that Gosling has no future? No! I think it's very nice to have an alternative to Ant to create build script (for those who don't like Maven2 very much). I also think that this would be a nice framework to create build task for Maven2. Because you are using code to create your build script, you can use a debugger to debug them. In that respect, it's much better than Ant and Maven2. I imagine, it would also possible to write libraries of tasks that could be downloaded on the fly (using dependency management) to be able to actually not repeat yourself.

Right now, this framework requires Java6. This is not a very good idea to drive adoption, Java5 and even Java 1.5 should be supported.

But the feature I would want the most for this project would be to be able to write my build script in a scripting language. Be it Ruby (with the help of JRuby) and/or Groovy! That would be much better than XML :-)



9.22.2006

The simplest thing to do...

I have been living in the Java world for a long time now. In this world full of patterns, complicated API and well intentionend flexible frameworks, we do not always follow the simplest path to a solution.

I'm currently working on adding some functionnality to an application that we wrote for a client last year. This application written in Java using JSF/Facelets/Spring/Hibernate and running on Tomcat.

For the new functionnality, I wish to move information from page to page but I don't want them to stay in the session for long. I also don't want to explicitely have to remove explicitely these object from the session. Now I could use request scope attributes to do that, but then if I choose to do a redirect instead of a forward, I will loose the information. I could also go with a more complicated option of using Spring WebFlow (or something similar). But I don't want to another layer and more configuration files.

In the weeks before starting this new project, I wrote some application using Ruby on Rails. The philosophy behind this framework is very different than the philosophy behind most Java frameworks. Here the DRY (Don't Repeat Yourself) principle is king. This contrast a lot with the stack I'm using as I have to define information about my controller, pages, beans in multiple places.

One of the concept I found useful in Rails is the Flash. The Flash is a hash structure like the session but it retains objects up to the end of the next request. It's a bit like the request scope with the added benefit of surving redirects.

So I thought, why not implement this in Java. For my Java implementation, I choose not to implement the "now" operation that is present in Rails as I did not really needed it. I also use a filter to do the management of the Flash.

This simple solution allow me to pass objects from page to page without having to polute the session to much. It has the benefit of allowing request-like scope to survive redirects. The current implementation may not work well with Ajax requests (I use Ajax4JSF and I have yet to find a way to differenciate Ajax request from normal requests, so the objects will be purge when doing an Ajax request unless I explicitely retain them when processing the Ajax request).

So here is the code (the two classes must be in the same package). Note that you can customize the Filter mapping to suits your particular needs.

Flash.java
import java.io.Serializable;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;

public class Flash extends HashMap<String, Object> implements Serializable {
    private Map<String, Integer> time2live= new HashMap<String,    Integer>();
   
    @Override
    public Object put(String key, Object value) {
        time2live.put (key, 1);
        return super.put(key, value);
    }
   
    public Flash keep(String key) {
        if (containsKey(key)) {
            time2live.put(key, 1);
        }
        return this;
    }
   
    public Flash keep() {
        for (Map.Entry<String, Integer> entry : time2live.entrySet()) {
            entry.setValue(1);
        }
        return this;
    }
   
    public Flash discard(String key) {
        if (containsKey(key)) {
            time2live.put(key, 0);
        }
        return this;
    }
   
    public Flash discard() {
        for (Map.Entry<String, Integer> entry : time2live.entrySet()) {
            entry.setValue(0);
        }
        return this;
    }
   
    void manageFlash()  {
        for (Iterator<Map.Entry<String, Integer>> entries= time2live.entrySet().iterator(); entries.hasNext();) {
            Map.Entry<String, Integer> entry= entries.next();
            if (entry.getValue() == 0) {
                entries.remove();
                remove(entry.getKey ());
            } else {
                entry.setValue(entry.getValue()-1);
            }
        }
    }
}

FlashFilter.java
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest ;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;

/**
 * @web.filter name="FlashFilter" display-name="Flash Filter"
 * @web.filter-mapping url-pattern="*.html"
*/
public class FlashFilter implements Filter {
    public void destroy() {
    }

    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {
        HttpServletRequest httpRequest= (HttpServletRequest)request;
       
        Flash flash= (Flash) httpRequest.getSession(true).getAttribute("flash");
        if (flash == null) {
            flash= new Flash();
            httpRequest.getSession().setAttribute("flash", flash);
        }
        flash.manageFlash();
       
        chain.doFilter(request, response);
    }

    public void init(FilterConfig filterConfig) throws ServletException {
    }
}


AdSense Links