Show me your license!

In the follow up of open-sourcing our project, I spent some time today figuring out which license would be used best. This was completely new to me so I started comparing the different kind of licenses available. Apparently there are two major kind of licenses. On the one hand you have the 'GPL based' licenses, which enfore the code that use the open-source GPL code, to also be free and to also continue under the GPL 'flag'. They even have a clause stating that you cannot add additional restrictions on the 'redistribution of either the original work or a derivative work'. The goal is to not only garantuee the 'freedom' of the open-source software, but to also encourage software that uses open-source software to do the same.

On the other hand you have a bunch of 'proprietary compatible' licenses, like the MIT/X, the BSD and the Apache license which pretty much allow everything (use, modify, redistribute, ...) without enforcing extra constraints. Chances are high that we will go with an Apache license. Somewhere in between those major kinds, there also is a more pragmatic version of the GPL, called the 'Lesser GPL' which literally is a copy of the GPL exempting the fact that the propietary software should also use GPL.

I also read a lot about copyright, copyleft, dual licensing, trademark protection, and credit enforcement, but I'm not gonna bore you with that...

eID

At work a colleague and me just finished the 1.0 version of a new eID security module. It's based on the open source framework of Fedict that uses an Applet to allow you to sign in using your digital id. This framework was brought to life due to a lot of problems (stability, configuration, ...) with the current eID Fedict middleware solution.

For now it's still implemented as a stand-alone war, but it will be integrated in our larger, existing security module very soon. This larger module copes with authentication, authorization and identity management and is really mature for some time now. It came to life several years ago to replace a product from Sun called Access Manager. Onces the integration with eID is finished, the entire module will be open sourced. Exiting stuff!

PKCS#12

PKCS#12 is a PKCS (Public Key Cryptography Standards) developed by IBM and published by RSA Security. It is designed as the Personal Information Exchange Syntax Standard. This means that it serves as a standard to exchange sensitive key information between one kind of keystore and another kind. In Java you can instantiate a Keystore in the standard way Keystore.getInstance("JKS") or with a PKCS12 SPI implementation Keystore.getInstance("PKCS12"). Both implementations store private keys and certificates in a single file. OpenSSL however, stores them in separate files. Via the 'openssl pkcs12' command you can merge them into a PKCS#12 file, bridging the cap towards a Keystore. For instance:

openssl pkcs12 -export -inkey newSignedRequest.pem -certfile myCertFile.pem -name "TEST CERTIFICATE" -out myPkcs12Cert.p12

Certificates comming from a CA are almost always delivered in pkcs12 format.

Can you fetch me this thingie? Just for me please...

Kodo is a JDO implementation that it's not widely adopted and a bit more complex than Hibernate. Neverteless I found at least feature that it already had long before Hibernate did, called 'fetch groups'. With a fetch group you can for instance eager fetch a collection that is defaulty mapped as lazy for a certain scenario.

Let's say a bunch of addresses are defaulty mapped 'lazy' to a customer. We can then define a fetch group (eg 'addressFetchGroup') to indicate that this collection should be eagerly fetched when this group id is used in the query.

Here's what this would look like:

The package.jdo (mapping) file:

    <class name="Customer">
      <extension vendor-name="kodo" key="data-cache" value="false" />
      <extension vendor-name="kodo" key="jdbc-sequence-factory" value="native" />
      <extension vendor-name="kodo" key="jdbc-sequence-name" value="MYSEQUENCE" />
      <field name="name" persistence-modifier="persistent" />

      <field name="addresses" default-fetch-group="false">
        <collection element-type="address" />
        <extension vendor-name="kodo" key="fetch-group" value="addressFetchGroup"/>
      </field>

 ...

The code:

    public Customer lookUpCustomerWithAddresses(String customerId) {

        Collection fetchGroups = new ArrayList();
        fetchGroups.add("addressFetchGroup");
        fetchGroups.add("otherFetchGroup");
        ...
        return retrieveWithFetchGroups(fetchGroups, customerId);
    }

    @SuppressWarnings("unchecked")
    public <S> Collection<S> retrieveWithFetchGroups(Collection<String> fetchGroups, Object... parameters) {
    KodoQuery query = (KodoQuery) persistenceManager.newJDOQuery();
        try {
            query.getFetchConfiguration().addFetchGroups(fetchGroups);
            return (Collection) query.executeWithArray(parameters);
        } catch (Exception ex) {
  ...
        }
    }

When used correctly (and more importantly, measured correctly with a profiler), this can greatly improve performance of a specific use case, without affecting other use cases. As of hibernate 3.5 this feature is also included and known as 'fetch profiles'.

Thou shall respect the carriage return

As usual it was fairly late notice when we as the development team heard our certificates were only still valid a day and a half before expiring. Luckily the procedure to prolong them was already executed. We had sent them to our CA, Fedict, which had extented their validity and send them all back in one big zip.

Beside the complete lack of naming convention of the cert file names, a few things suprised me in the renewal process. We had at least 16 or more certificates to import for different environments and customers and had to chain each of them with an intermediate and root level certificate, also provided by the CA. Although this is a trivial task, it made me wonder why they couldn't have done this for us, you know, being a customer of their services. Second of all it was in pem format, which was nice, but it looked something like this:

Ulv6GtdFbjzLeqlkelqwewlq822OrEPdH+zxKUkKGX/eN
...
...
9801asds3BCfu52dm7JHzPAOqWKaEwIgymlk=

Importing them in our jks was impossible unless we added the begin and end phrase to make it look like this:

-----BEGIN CERTIFICATE-----
Ulv6GtdFbjzLeqlkelqwewlq822OrEPdH+zxKUkKGX/eN
...
...
9801asds3BCfu52dm7JHzPAOqWKaEwIgymlk=
----END CERTIFICATE-----

Although this is also a known practice and was quickly done, it was again something they could have done for us, you know, being a customer of their services. Lastly while doing all this, I noticed another subtlety, this time about the jks. It only allows the import if there is a carriage return after the last phrase. So you had to explicitly say '----END CERTIFICATE-----CR' before the import succeeded. I wonder if this also is a security feature.

The eagerness of JPA

JPA came to life as a result of JSR 220. This request originated to provide a uniform API and way of working across different ORM solutions such as Hibernate, Toplink and JDO. One member of the expert group leading JSR 220 was righteously Gavin King, the main inventor of Hibernate. Since Hibernate is the most widely used implementation, I thougth they would follow most of its important design decisions. For instance in hibernate the default fetching strategy is 'lazy'. Although this can sometimes lead to difficulties with casts and object equality (if you received a proxy in stead of the real object), it has as advantage that you only fetch dependencies in memory when you need them. I was suprised to see that in JPA the default fetch of a @manyToOne for instance is 'eager'?!

This lead to the fact that someone in my team unwillingly dragged half the DB in memory :) If anybody knows why they decided to change this, please let me know. Thx

There can be only one

Before Java release 1.5 you had to do the following to create a Singleton:

public class ImASingleton {

 private static final ImASingleton INSTANCE = new ImASingleton();

 private ImASingleton() {
 }

 public static ImASingleton getInstance() {
  return INSTANCE;
 }
}

And to be able to serialize this singleton, you had to do 3 things:
1. Implement the Serializable interface.
2. Mark the instance fields transient if you didn't want them to be serialized.
3. Define a readResolve() method to return the single instance. This is a hook method called in the deserialization process. If you don't provide this method, the default implementation will always create a new instance in stead of your unique instance!

public class ImASingleton implements Serializable {

 private static final ImASingleton INSTANCE = new ImASingleton();
 private final transient Object nonSerializableField;

 private ImASingleton() {
 }

 public static ImASingleton getInstance() {
          return INSTANCE;
 }

 private Object readResolve() {
   return INSTANCE; 
 }
}

As of Java 1.5 the preferred way to create a singleton is simply by using an enum. This get's you the Serialization for free.

public enum MySingleton() {
 INSTANCE;
}