I would even go as far as saying that there was no object orientation before programming crosscutting concerns and using dependency injection became established mechanisms.
Think about it: The original goal of OO is not to use inheritance, encapsulation, identity and polymorphism, but to express the real world of things – our reality – using an abstract world of things, while preserving most of the properties and relationships we observe in reality.

Before AOP, before being able to separate the description of things from creating, configurating and connecting concrete instances through dependency injection frameworks, this goal was hard to achieve.

Modules larger than classes with OSGI

Now however, we are about to reach a new stage in development of object orientation in JAVA: Developing modules that are larger than classes, modules which can, once properly identified, be developed independently using all the wonderful technology described beforehand. The technology used to achieve this has a name: OSGI. This technology has quite a long history of development, but a certain lack of elegance and light-weightiness barred this component model from becoming a real hit in the worldwide development community. This is about to change.

Impact of OSGI on the development process

Let me stress out here how important it is to be able to develop, manage and deploy such modules. The larger your system, the more developers your project involves, the longer you maintain it – you will always face the same problem: Developers concurrently working with party of the system that are directly or transitively connected will run into conflicts. You will have different parts of your system requiring different versions of the same library on the same class path. Changing one part of the system will always affect other parts of the system, most of the times in an unplanned fashion.

Test driven developments helps a lot along the way, but you still have a responsibility problem if there’s one team changing something and this causes a problem in a different part of the system, and dependency issues can be a real mess.

This is where OSGI can play out it’s strengths. Not only does it offer you complete, classloader-based module isolation. I believe the greatest benefit lies in the development process: Concurrent development is a lot easier with OSGI bundles than with a huge pile of tightly interconnected classes. You can have a lot of changes in the bundle, while exposing a relatively stable interface through which other components access your bundle’s services. Separation into OSGI bundles can bring the power of the SOA-Idea into “stand-alone” applications, without the massive overhead of connecting systems or components through, for example web services.

Of course, this concept has quite an impact on your way of thinking, since you will start to add a new level of decomposition: Which classes form tightly coupled components that could be isolated from other components and used as a service through a well-defined, slim and easy-to-use interface?

OSGI about to “break through”

Now, why am i so convinced that OSGI is about to finally become as common as using AOP or dependency injection? Because all the popular technologies are just about to embrace OSGI:

• Craig walls (Spring framework) has just finished his book an modular JAVA with the spring framework, featuring OSGI and Spring, a very powerful combination.
• Doug Clarke and Shaun Smith will hold a presentation on persistence and OSGI with eclipselink (the reference implementation of the JAVA persistence API (JPA)), thus suitable persistence mechanisms for this level of modularization are likely to be close at hand.

And if you look at the schedule for the JAX, Europe’s most important software & development conference, there have never been more OSGI topics featured – at least I would doubt that.

In other words: OSGI will soon be so smoothly integrated with you favorite frameworks, IDE’s and API’s that using it will be a breeze – and a must, if you want to take the quality of your development process and software to the next level.

The resulting exceptions look like this:


[EL Warning]: 2008.08.12 11:01:13.134--ServerSession(28607378)--Exception [EclipseLink-4002] (Eclipse Persistence Services - 1.0 (Build 1.0 - 20080707)): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: Unexpected token: UNIQUE in statement [CREATE TABLE ... (ID INTEGER UNIQUE]
Error Code: -11


Jason Drake, who reported the issue for toplink, suggests modifying the FieldDefinition and DefaultTableGenerator. (The error migrated from toplink into eclipselink)

As a simpler alternative, one might just subclass the HSQLPlatform class and override the supportsUniqueConstraint and printFieldUnique methods. This has worked for my testsuite, which i migrated from hibernate to eclipselink.

Here is my subclassed HSQLPlatform implementation:

package my.somepackage
/**
 * This is a workaround HSQL DB platform implementation which omits unique constraints
 * since they are not supported in the syntax that eclipselink is using.<br />
 * See: <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=240618">issue 240618</a>.
 *
 * @author Olaf Otto
 * @see org.eclipse.persistence.platform.database.HSQLPlatform
 */
public class HsqlDbPlatform extends HSQLPlatform {
    /**
     * Workaround for  https://bugs.eclipse.org/bugs/show_bug.cgi?id=240618.
     *
     * @return <code>false</code>.
     */
    @Override
    public boolean supportsUniqueKeyConstraints() {
        return false;
    }

    /**
     * Workaround for  https://bugs.eclipse.org/bugs/show_bug.cgi?id=240618.
     * <br />
     * Does nothing.
     */
    @Override
    public void printFieldUnique(Writer writer, boolean shouldPrintFieldIdentityClause) throws IOException {
        // Do nothing.
    }
}

BTW: Eclipselink is already supported in Spring 2.5.2. If you use spring, providing the customized database platform is a simple property change in the jpa vendor adapter:

    <bean id="jpaVendorAdapter" class="org.springframework.orm.jpa.vendor.EclipseLinkJpaVendorAdapter">
        <property name="generateDdl" value="true"/>
        <property name="showSql" value="false"/>
        <property name="databasePlatform" value="my.somepackage.HsqlDbPlatform"/>
    </bean>

@Configurable(value = "myBean")
public class MyBean {
   ...
}

Where myBean is the bean id in the spring context.

This approach can be somewhat problematic, though, when used in conjunction with aspect-oriented features.
Say, for example, you also want to use JPA and require a transactional behavior.

You would usually do the following:

@Configurable(value = "myBean")
public class MyBean {
   @Transactional
    public void foo() {
    ...
    }
}

This will not work, but lead to an exception like this:


java.lang.IllegalStateException: Post-processor tried to replace bean instance of type [my.package.MyBean] with (proxy) object of type [my.package.MyBean$$EnhancerByCGLIB$$c029ddbf] - not supported for aspect-configured classes!


The reason is that @Configurable will ask spring to configure the current bean during constructor invokation. During configuration, a number of bean post processors will be invoked on the bean, and one of them, namely the InfrastructureAdvisorAutoProxyCreator will find the @Transactional annotation – which advices the post processor to proxy the bean in order to manage the required transaction’s context.

But you cannot override the expected outcome of a class instanciation with new with a proxy object – since it is not of the same type as the expected object!

Thus, @Configurable and @Transactional – together with any other advice that leads to a proxy object – cannot coexist in your class.


...
Caused by: javax.persistence.RollbackException: Error while commiting the transaction
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:71)
at org.springframework.orm.jpa.JpaTransactionManager.doCommit(
JpaTransactionManager.java:438)
... 55 more
Caused by: java.lang.ClassCastException: java.util.HashSet
cannot be cast to org.hibernate.collection.PersistentCollection
at org.hibernate.event.def.FlushVisitor.processCollection(FlushVisitor.java:34)
...


Das tritt dann auf, wenn man wohlmeinend die Exposition der internen Repräsentation vermeiden wollte und beispielsweise so etwas hier auf einer persistenten Collection macht:

 @Entity
 public  class foo {
       private Set<AnotherEntity> _relatedEntites = new HashSet<AnotherEntity>();

     @OneToMany(cascade = {CascadeType.ALL }, fetch = FetchType.LAZY)
     @Column(name = "RELATED_ENTITIES")
      public Set<AnotherEntity> getRelatedEntities() {
            return new HashSet<AnotherEntity>(_relatedEntites)
     }
 }

Das: new HashSet(…) ist ein Fehler, da es aus der vorher erzeugten persistenten Collection wieder eine HashMap macht, die nicht persistiertbar ist.

Um die Manipulierbarkeit der Klasse zu vermeiden kann man stattdessen die @Immutable-Annotation verwenden:

 @Entity
 public  class foo {
       private Set<AnotherEntity> _relatedEntites = new HashSet<AnotherEntity>();

     @OneToMany(cascade = {CascadeType.ALL }, fetch = FetchType.LAZY)
     @Column(name = "RELATED_ENTITIES")
     @Immutable
      public Set<AnotherEntity> getRelatedEntities() {
            return _relatedEntites;
     }
 }

Dann klappt’s auch mit Hibernate.