Following the initial release of the niceideas-commons package here : niceideas-commons 1.0-alpha-0.7, The niceideas-commons 1.1-beta-0.1 is released today.

Major changes are :

• Basic relation mapping support added to the DAO framework
• More helper and utilities related to resource finding and loading
• More utilities of various kinds
• Various bug fixes

[Read More]

I remember the introduction of the brand new enum type in Java 5 (1.5) was a very exciting announce. However, when I finally switched from 1.4 to 1.5 and actually tried Java's flavoured enum types, I was a bit disappointed.

Before that, I was using Josh Bloch's "Typesafe enum" pattern (effective java) for quite a long time and I didn't really see what was so much better with the new Java native enum construction. Ok, fine, there was the ability to use enum instances in switch - case statements which seemed fine, but what else ?

Besides, what I used to find great with the "typesafe enum" pattern is that it could be tricked and changed the way I wanted, for instance to be able to dynamically (at runtime) add enum instances to a specific typesafe enum class. I found it very disappointing not to be able to do the very same thing easily with the native Java enum construction.

And now you might wonder "Why the hell could one ever need to dynamically add enum values ?!?". You do, right ? Well, let's imagine this scenario:

You have a specific column in a DB table which contains various codes as values. There are more than hundred different codes actually in use in this column. Related to this, you have a business logic which performs different operations on the rows coming from this table, the actual kind of operation applied on the row depends on the value of this code. So there are chance you end up with a lot of if - elseif statements checking the actual value of the code.
I myself am allergic to using string comparison in conditions so I want to be able to map the values from this column to an enum type in Java. This way I can compare enum values instead of strings in my conditions and reduce my dependency on the format of the string value.

Now when there are more than a hundred different possible codes in the DB I really don't have any intent to define them all manually in my enum type. I want to define only the few I am actually using the Java code and let the system add the other ones dynamically, at runtime, when it (the ORM system or whatever I am using for reading the DB rows) encounters a new value from the DB.

Hence my need for dynamically added enum values.

So recently I faced this need once again and took a few hours to build a little solution which enables one to dynamically add values to a Java enum type. The solution is the following :

[Read More]

I've been facing an interesting problem with string manipulation in Java lately at work. The requirement was the following :

We have a field on some screen where the user can type in a comment. The comment can have any length the user wants, absolutely any. Should he want to type in a comment of a million characters, he should be able to do so.

Now the right way to store this comment in a database is using a CLOB, a BLOB or a LONGVARCHAR or whatever feature the database natively provides to do so. Unfortunately that's not the way it was designed. Due to legacy integration needs, all these advance DB types are prohibited within our application. So the way we have to store the comment consists of using several rows with a single comment field of a maximum length of 500 characters. That means the long comment has to be split in several sub-strings of 500 characters and each of them is stored in a separate row in the DB table. The table has a counter as part of the primary key which is incremented for each new row belonging to the same comment. This way we can easily spot every row part of the same comment.

Now another problem we have is that under DB2 a field defined as VARCHAR(500) can contain 500 bytes max even though the strings are encoded in UTF-8 in the database. That means we might not be able to store 500 characters if the string contains one or more 2 bytes UTF-8 characters. Working in a french environment, this happens a lot.
So we had to write a little algorithm taking care of the splitting of the string in 500 bytes sub-strings.

The very first version of our algorithm was quite stupid and ended up in splitting the string in a quite naive way: we converted the string to a byte array following an UTF-8 encoding and split the byte array instead of the string. Then each of the 500 bytes arrays was converted back to a string before being inserted in the database.
Happily, we figured out quite soon that this doesn't work as it ends up quite often splitting the string right in the middle of a 2 bytes character. The byte arrays being then converted back to strings, the split 2 bytes character was corrupted and could not be corrected any more.

Before writing as smarter version of the algorithm which would manually test the byte length of the character right at the position of the split, we took a leap backward and wondered : "Can it be that Java doesn't offer natively a simple way to do just that ?"

And the answer is yes of course.

[Read More]

CommunityBoard is a sample multi-module maven / glassfish / eclipse Java EE project.

It realizes is a little Forum / Note publishing application. Its main purpose it to act as an introducing laboratory to Java EE programming. As such the functionalities are rather limited. Yet it covers the most fundamental aspects or issues with Java EE programing in the way it show hows to :

• write entity beans with bi-directional relationship;
• use these Entity beans in EJBs (Statless session beans);
• use other EJBs in EJBs;
• use EJBs in a servlet or a JSP located in a WAR (i.e. no processing of the @EJB annotation);
• build a multi-module Java EE maven project with jars, wars, ears;
• how to write JSPs with the JSTL (Ok I am not very proud of these JSPs yet they do the job) and
• deploy a multi-module ear within Glassfish and use a container defined datasource

[Read More]

Wow ... This is and will most likely be the most pompous title for a post on this blog usually focused on much more concrete stuff.

Ok let's get into this :

First what is DWR ?

DWR stands for Direct Web Remoting - Easy Ajax for Java.

DWR is a Java library that enables Java on the server and JavaScript in a browser to interact and call each other as simply as possible.

Quoting the official website :

"DWR is a RPC library which makes it easy to call Java functions from JavaScript and to call JavaScript functions from Java (a.k.a Reverse Ajax)."
Read this : http://directwebremoting.org/dwr/introduction/index.html.

[Read More]

The company for which I am working currently is the fourth for which I am a Java developer / architect. I am mostly programming in the Java language for quite a long time now, and I have to admit that I have my way of doing things and my little habits. I know a large amount of java libraries and use almost always the same sets for the same needs, with little variations.

But even with the very large set of java libraries available out there, there are a few classes or utilities that I keep re-developing myself again and again each time I start a new job. Not that most of these utilities are not already available somewhere but I dislike the implementations, or want something simple, or anything else. A few of these classes though are really unique by nature.

Well, lately I found myself tired of re-writing the same sets of classes again and again so I wrote them once more ... once and for all. I made from them an open-source and freely available project released under GNU LGPL license so that I can freely use them in my current company as well as for any future employer I might be working for.
Having done this I thought I could share them here.

[Read More]

I'm working on a java application which makes an extensive usage of hibernate's relation mapping system. The later offers several ways to define association mapping. We mostly use many-to-one relation declarations. The problem comes from the database. It's a pre-relational, pre-transactional, legacy database running on a prehistorical IBM zSeries host. The data on this database is very often dumb or corrupted. The lack of a proper referential integrity support and the foolish design make us end up quite often following non-existent relations.

Happily, hibernate provides a semantic which allow the application not to bother when a relation is missing, just as the legacy app does. This semantic is the not-found="ignore" parameter on the relation definition.

However, the usage of this semantic resumes to open very wide the doors to oblivion.

[Read More]