Fred, Let it go!

Extended Enums usage

2011-07-05T18:43:00.002+03:00

Since the re-launch of extended enums I'm paying attention in my everyday coding (yes I still write code :) if extended enums will help me.
Here are 2 new examples:
1) I found out that most of the time the name() of the enum is not what I need. I need it to map an XML or HTML tag, an external ID, an entry name in excel or simple type name in a JSON object. So I write something like:


    public enum ConfigName {
        ALL("local-all"),
        INTERNAL("local-int"),
        OR("local-int-ext");

        private final String xmlKey;

        LdapConfig(String xmlKey) {
            this.xmlKey = xmlKey;
        }

        public String getXmlKey() {
            return xmlKey;
        }
    }

I could remove the getter, and the IDE helping a lot writing the boiler plate code but why? Here is how it should look:

    public enum ConfigName extends AlternateEnumKey {
        ALL("local-all"),
        INTERNAL("local-int"),
        OR("local-int-ext");
    }

The extra feature here is that the name() of the enum (ALL, INTERNAL, OR) is a constant that is not recognized as such by the javac compiler. So:

    @XmlTag(tag = ConfigName.ALL)

will not compile and so:

    @XmlTag(tag = ConfigName.ALL.xmlKey)

will for sure not.

But with extended enum you'll have:

    public @interface XmlTag { AlternateEnumKey tag(); }

    // The framework managing XmlTag will take the alternate key value
    @XmlTag(tag = ConfigName.ALL)

2) Since extended enums also supports generics for enums, and I just have this issue associating also a long (ID) to an enums, you can now write:

    public enum ConfigName extends EnumPairExtension<Long, String> {
        ALL(45L, "local-all"),
        INTERNAL(56L, "local-int"),
        OR(98L, "local-int-ext");
    }

    assert ConfigName.OR.a == 98L;

With this, parsing definitions are a lot cleaner to write.

A new push for extended enums!

2011-06-14T15:35:00.002+03:00

At Devoxx09, Joe Darcy presented the status and future of the Coin project, and how changes to the language are selected and implemented (or vice versa). :)
During his talk, he showed the cost classification of a language change: trivial, small, medium, big, or huge, and emphasized the fact that each change is also a benefit (hard to measure a priori) that can be estimated as big, medium, or small.
So for example, the new loop syntax introduced in Java5 was a small change with big benefits—a no "brainer", let's do it!

However, in his talk he showed how "Extended Enums" were at least medium cost with a small benefit.

I started working on "Extended Enums" (previously "abstract enum") since the release of OpenJDK and the launch of the now defunct KSL (Kitchen Sink Language) in 2006. From the amount of hits this blog is getting on "extended enums", I know this issue is of big concern for many Java developers.
I developed a working solution, but stopped pushing for it for two main reasons:

This addition to the language is a change to the Java-type system. Moreover, it cannot be a small modification; it is at least a medium change.
Looking at Scala Traits or Fantom Mixin, I had the feeling that it was pushing Java too much, and perhaps in the wrong direction.

So I talked with Joe Darcy at Devoxx09 about all the things I discovered implementing this change to the javac compiler (and other needed changes to the JDK classes). It was clear that the change is medium size, but I disagree that the benefits are small.
The benefits of "Extended enums" as implemented today:

Ability for enum declaration to extend an actual abstract class
This is the evident benefit, and it is a small benefit. Using delegation and/or in-lined anonymous classes is not too verbose and provides the same benefits. Still it is nicer and cleaner to have the normal OO inheritance.

Ability to use Generics in Enum classes
With "Extended enums" you can have code like this:


public enum ActionQuery<T extends Action> {
    ALL<Action> {
         public List<Action> getResults() {...}
    },
    EDIT_ACTION<EditAction> {
         public List<EditAction> getResults() {...}
    },
    VIEW_ACTION<ViewAction> {
         public List<ViewAction> getResults() {...}
    };
     public abstract List<T> getResults();
}

I find "Extended enums" very useful in organizing SQL queries and their results, playing with properties and their types, and so on.

The most important feature and the reason why I developed "Extended enums" was to have the ability to define annotation enum parameters without having to specify their list of values in advance. You can already see this issue in today's JPA specification. There is an enum FetchType that is fixed in the spec to LAZY and EAGER, but Hibernate also supports SUBSELECT, which is approximately between LAZY and EAGER. To support SUBSELECT, you need to use the Hibernate specific annotation in combination with the standard one. If the FetchType was an abstract enum, the JPA specification does not need to enforce a well-defined list, but could have a proposed DefaultFetchType and let JPA implementation and application developers define a new enum with their desired list of FetchType. This already works great in the "abstract enum" implementation and provides me with great benefits in many other areas: (such as BindingType in JSR-299 Context and Dependency Injection, Cache declaration using enum instead of error prone string for region, Group in JSR-303 Bean Validation using user defined enums instead of empty interfaces, and more).

From my point of view (and I think/hope I'm not alone), Joe Darcy missed the benefit point of the extended enum. It is a big benefit to the Java language.
This was and is my position for some time. What pushed me to re-launch "Vote for Extended Enums for the Coin project!", is of course Christof May from soplets.org (which setup the extended-enums site: http://www.extended-enums.org/), and the fact that I found a way to make the change a "small" one. Until now, I was sure that to implement this correctly a new flag was needed in the class byte code, and many changes to the Java type management were necessary.

So, if you are interested or want to learn more please check the extended enums web site: http://www.extended-enums.org/

No singletons allowed in a WebLogic EAR!

2009-10-29T16:53:00.009+02:00

The context

There is a big EJB3 application (835 Entities, 88 stateless, 1 MDB) that works on JBoss (Server and Embedded) in production with no problem.
We now want to support WebLogic 10.3 and WebSphere 7.0!

The problem

The application contains "of course" some framework jars to manage cross cutting services (logger, metadata, XML marshalling, ...) using immutable static maps that are initialized at bootstrap time. Nothing extraordinary in my point of view!
Still, we found out that under WebLogic 10.3 the final static maps are created multiple times!

No way!

I did not believe it!
I'm working with WebLogic since it was a company (not under BEA), and I always managed and enjoyed creating big enterprise application with it.
Putting JBoss aside (this thread is about WebLogic), in 1999-2002, every presale competition against IBM WebSphere if no politics were involved, WebLogic always won.
From my experience, I always managed to understand the logical behavior of WebLogic, and found a way to deliver the applications to my customers.
Is this crazy behavior due to the influence of Oracle buying BEA almost 2 years ago?

The small test case

To prove the point, we created a small ejb3 application that can be easily build with Maven 2. Side note: this simple app can be useful to others that wish to test their EJB3 container.
The source code is under subversion here.

The modules

This Enterprise Application has the simplest but complete set of features we need from an EJB3 container. It is made of the following modules (by order of dependency):

simple-framework
A simple framework jar that will be part of the EAR and used by the WEB and EJB classes. This module uses only 2 external jars: log4j and slf4j.
another-ejb-sample
A pure Stateless session bean used from different layer of the other modules to test EJB injection.
ejb-sample
A simple EJB3 jar with different kind of beans: a Stateful, a Stateless and an Entity. This module contains the persistence.xml that defined the connection to the DB. By default the persistence.xml is configured for a MySQL (the line for Oracle is commented) DB data source with JNDI Name "jdbc/ejb3_ds" which contain one table "customer"
web-sample
A webapp http://localhost:7001/web-sample with a servlet that can activate the different tests.
ear
A maven module that will create "sample-ejb3-ear.ear" file that can be deployed in WebLogic Server 10.3.

How to build

Use standard maven 2.0.9 or above and run "mvn install" under the root folder of the project. All needed dependencies are coming from this repository.

After a successful build the "ear/target/sample-ejb3-ear.ear" can be deployed on a correctly configured WebLogic 10.3 Server.

WebLogic and DB configuration

For MySQL:

create table customer (
 id int(10) unsigned not null auto_increment,
 name varchar(255) default null,
 primary key (id));

For Oracle:

create table customer (
 ID NUMBER(12,0) NOT NULL ENABLE,
 NAME VARCHAR2(200),
 CONSTRAINT CUSTOMER PRIMARY KEY (ID) USING INDEX COMPUTE STATISTICS);

 create sequence CORE.hibernate_sequence
 start with 1 increment by 1 nomaxvalue;

Need to create a data source with JNDI Name "jdbc/ejb3_ds" for the DB.
Deploy the "sample-ejb3-ear.ear" application in WLS 10.3.

The Results

You will see in the log that a pure and simple singleton LogServiceImpl available in the "simple-framework" module is initialized 3 times (which is 2 times too much for a singleton :). The 3 times match the 3 beans (2 stateless, 1 entity) where the standard log variables appears

private static final Log log = LogService.getLog(...);

Any solution to solve this problem will be extremely painful, since basically ALL our static members are not static anymore. Any solution will have to be based on a ThreadLocal entry hoping that one single thread is doing the code analysis :).
What's even more worrying for us, is that these classes loaded with different class loader (static stack), are not discarded after code analysis, but assembled together!

Possible Solutions?

We added a <classloader-structure> in the weblogic-application.xml file to enforce a single class loader for the whole EAR, it still in the code and did not work.
We tested with Sun JVM 1.6 and JRockit. Both gave the same results

Are we missing a flag "unified class loader for EAR"?

Who is doing what?

Here is the full stack of 3 different creations of the same singleton. It's hard to write something like this after 12 years of Java development :( :


[04-11-09 14:52:18.867] INFO  SessionFactoryImpl - building session factory
java.lang.Exception: THIS SHOULD HAPPEN ONLY ONCE
 at greenhouse.ejb3.sample.framework.LogServiceImpl.<init>(LogServiceImpl.java:54)
 at greenhouse.ejb3.sample.framework.LogServiceImpl.<clinit>(LogServiceImpl.java:51)
 at greenhouse.ejb3.sample.framework.LogService.getLog(LogService.java:23)
 at greenhouse.ejb3.sample.Customer.<clinit>(Customer.java:35)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
 at org.hibernate.engine.UnsavedValueFactory.instantiate(UnsavedValueFactory.java:22)
 at org.hibernate.engine.UnsavedValueFactory.getUnsavedIdentifierValue(UnsavedValueFactory.java:44)
 at org.hibernate.tuple.PropertyFactory.buildIdentifierProperty(PropertyFactory.java:44)
 at org.hibernate.tuple.entity.EntityMetamodel.<init>(EntityMetamodel.java:124)
 at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:434)
 at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:109)
 at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55)
 at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:226)
 at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1300)
 at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:859)
 at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:669)
 at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:132)
 at weblogic.deployment.PersistenceUnitInfoImpl.createEntityManagerFactory(PersistenceUnitInfoImpl.java:330)
 at weblogic.deployment.PersistenceUnitInfoImpl.<init>(PersistenceUnitInfoImpl.java:123)
 at weblogic.deployment.AbstractPersistenceUnitRegistry.storeDescriptors(AbstractPersistenceUnitRegistry.java:331)
 at weblogic.deployment.AbstractPersistenceUnitRegistry.loadPersistenceDescriptor(AbstractPersistenceUnitRegistry.java:245)
 at weblogic.deployment.ModulePersistenceUnitRegistry.<init>(ModulePersistenceUnitRegistry.java:63)
 at weblogic.ejb.container.deployer.EJBModule.setupPersistenceUnitRegistry(EJBModule.java:209)
 at weblogic.ejb.container.deployer.EJBModule$1.execute(EJBModule.java:310)
 at weblogic.deployment.PersistenceUnitRegistryInitializer.setupPersistenceUnitRegistries(PersistenceUnitRegistryInitializer.java:62)
 at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:376)
 at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93)
 at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:387)
 at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
 at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:58)
 at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:42)
 at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:615)
 at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
 at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:191)
 at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:16)
 at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:155)
 at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
 at weblogic.deploy.internal.targetserver.AppDeployment.prepare(AppDeployment.java:141)
 at weblogic.management.deploy.internal.DeploymentAdapter$1.doPrepare(DeploymentAdapter.java:39)
 at weblogic.management.deploy.internal.DeploymentAdapter.prepare(DeploymentAdapter.java:187)
 at weblogic.management.deploy.internal.AppTransition$1.transitionApp(AppTransition.java:21)
 at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
 at weblogic.management.deploy.internal.ConfiguredDeployments.prepare(ConfiguredDeployments.java:165)
 at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:122)
 at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
 at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
 at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
[04-11-09 14:52:19.117] INFO  Customer - A new customer is created
[04-11-09 14:52:19.492] INFO  SessionFactoryObjectFactory - Not binding factory to JNDI, no JNDI name configured
[04-11-09 14:52:19.495] INFO  NamingHelper - JNDI InitialContext properties:{}
java.lang.Exception: THIS SHOULD HAPPEN ONLY ONCE
 at greenhouse.ejb3.sample.framework.LogServiceImpl.<init>(LogServiceImpl.java:54)
 at greenhouse.ejb3.sample.framework.LogServiceImpl.<clinit>(LogServiceImpl.java:51)
 at greenhouse.ejb3.sample.framework.LogService.getLog(LogService.java:23)
 at greenhouse.ejb3.sample.CustomerDAOBean.<clinit>(CustomerDAOBean.java:26)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:247)
 at weblogic.j2ee.dd.xml.validator.AnnotationValidatorHelper.getClass(AnnotationValidatorHelper.java:14)
 at weblogic.j2ee.dd.xml.validator.injectiontarget.BaseValidator.getClass(BaseValidator.java:38)
 at weblogic.j2ee.dd.xml.validator.AbstractAnnotationValidator.validate(AbstractAnnotationValidator.java:22)
 at weblogic.j2ee.dd.xml.validator.AnnotationValidatorVisitor.visitInjectionTargetBean(AnnotationValidatorVisitor.java:48)
 at weblogic.j2ee.dd.xml.validator.AnnotationValidatorVisitor.visit(AnnotationValidatorVisitor.java:25)
 at weblogic.descriptor.internal.AbstractDescriptorBean.accept(AbstractDescriptorBean.java:1124)
 at weblogic.descriptor.internal.AbstractDescriptorBean.accept(AbstractDescriptorBean.java:1128)
 at weblogic.descriptor.internal.AbstractDescriptorBean.accept(AbstractDescriptorBean.java:1128)
 at weblogic.descriptor.internal.AbstractDescriptorBean.accept(AbstractDescriptorBean.java:1128)
 at weblogic.descriptor.internal.AbstractDescriptorBean.accept(AbstractDescriptorBean.java:1128)
 at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.validate(BaseJ2eeAnnotationProcessor.java:143)
 at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.validate(BaseJ2eeAnnotationProcessor.java:131)
 at weblogic.ejb.container.dd.xml.EjbAnnotationProcessor.processAnnotations(EjbAnnotationProcessor.java:205)
 at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.processStandardAnnotations(EjbDescriptorReaderImpl.java:324)
 at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.createReadOnlyDescriptorFromJarFile(EjbDescriptorReaderImpl.java:190)
 at weblogic.ejb.spi.EjbDescriptorFactory.createReadOnlyDescriptorFromJarFile(EjbDescriptorFactory.java:93)
 at weblogic.ejb.container.deployer.EJBModule.loadEJBDescriptor(EJBModule.java:1198)
 at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:380)
 at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93)
 at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:387)
 at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
 at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:58)
 at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:42)
 at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:615)
 at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
 at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:191)
 at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:16)
 at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:155)
 at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
 at weblogic.deploy.internal.targetserver.AppDeployment.prepare(AppDeployment.java:141)
 at weblogic.management.deploy.internal.DeploymentAdapter$1.doPrepare(DeploymentAdapter.java:39)
 at weblogic.management.deploy.internal.DeploymentAdapter.prepare(DeploymentAdapter.java:187)
 at weblogic.management.deploy.internal.AppTransition$1.transitionApp(AppTransition.java:21)
 at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
 at weblogic.management.deploy.internal.ConfiguredDeployments.prepare(ConfiguredDeployments.java:165)
 at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:122)
 at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
 at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
 at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
java.lang.Exception: THIS SHOULD HAPPEN ONLY ONCE
 at greenhouse.ejb3.sample.framework.LogServiceImpl.<init>(LogServiceImpl.java:54)
 at greenhouse.ejb3.sample.framework.LogServiceImpl.<clinit>(LogServiceImpl.java:51)
 at greenhouse.ejb3.sample.framework.LogService.getLog(LogService.java:23)
 at greenhouse.ejb3.sample.RandomNumberGeneratorBean.<clinit>(RandomNumberGeneratorBean.java:16)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:247)
 at weblogic.ejb.container.dd.xml.EjbAnnotationProcessor.processWLSAnnotations(EjbAnnotationProcessor.java:1699)
 at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.processWLSAnnotations(EjbDescriptorReaderImpl.java:346)
 at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.createReadOnlyDescriptorFromJarFile(EjbDescriptorReaderImpl.java:192)
 at weblogic.ejb.spi.EjbDescriptorFactory.createReadOnlyDescriptorFromJarFile(EjbDescriptorFactory.java:93)
 at weblogic.ejb.container.deployer.EJBModule.loadEJBDescriptor(EJBModule.java:1198)
 at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:380)
 at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93)
 at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:387)
 at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
 at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:58)
 at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:42)
 at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:615)
 at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
 at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:191)
 at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:16)
 at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:155)
 at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
 at weblogic.deploy.internal.targetserver.AppDeployment.prepare(AppDeployment.java:141)
 at weblogic.management.deploy.internal.DeploymentAdapter$1.doPrepare(DeploymentAdapter.java:39)
 at weblogic.management.deploy.internal.DeploymentAdapter.prepare(DeploymentAdapter.java:187)
 at weblogic.management.deploy.internal.AppTransition$1.transitionApp(AppTransition.java:21)
 at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
 at weblogic.management.deploy.internal.ConfiguredDeployments.prepare(ConfiguredDeployments.java:165)
 at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:122)
 at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
 at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
 at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

Update on Nov 10th 2009

Thanks to Dror Bereznetsky for the heads up on the code analysis of "EjbDescriptorReaderImpl.createReadOnlyDescriptorFromJarFile(EjbDescriptorReaderImpl.java:192)" I managed to create a small patch to weblogic.jar that solved the problem.

The "stupid" issue is that the new class loader created for bean analysis was using the parent class loader of the EAR classloader, basically ignoring all the classes of my application that where reloaded on each analysis...

I went very strong on my patch making the parent of the bean analyzer class loader the current thread class loader, and it works. More tests coming, and a small hope that "Oracle" will solve the bug soon :(

Java6 and IntelliJ on MacOS X

2009-09-11T00:15:00.005+03:00

It's the third time now that I'm going through this, and each time I'm forgetting something...

The main problems I'm having are:

How to enforce Java6 64bit JVM as the default on MacOS?

How to make IntelliJ use it?

How to make Safari (and may be one day Firefox) use it

I know I'm loosing SWT, and many soft (like NetBeans and IntelliJ) enforce Java 5 has hard coded default on the Mac, but I'm developing in Fan and the IntelliJ Fan Plugin, and Java 6 is kind of a must :)

So, here is what I do:
On each update of Java6 from Apple

As root I go under:
cd /System/Library/Frameworks/JavaVM.framework/Versions/

There should be a symlink: CurrentJDK -> 1.5

Then I change the link:
rm CurrentJDK && ln -s 1.6 CurrentJDK

On each update of IntelliJ

Download the idea-XXX.dmg, the idea-XXX.tar.gz (64 bit not the jdk15 version), and idea-XXX-dev.zip. I hope JetBrains will start giving dmg files for the 64 bit JVM, because it's big downloads :(

Copy the "IntelliJ IDEA XXX.app" folder from DMG to Applications. I have /Applications/IntelliJ and /Applications/NetBeans with the versions I used, it helps when I'm messing up :)

Do a copy of it under "IntelliJ IDEA XXX-jdk15.app" for backup and to be able to compile IntelliJ plugin for 1.5

Extract the idea-XXX.tar.gz under /Applications/IntelliJ

Copy all the jar files from idea-XXX to "IntelliJ IDEA XXX.app". I do as root under idea-XXX:
find . -name "*.jar" -exec cp \{\} ../IntelliJ\ IDEA\ XXX.app/\{\} \;

Change the "IntelliJ IDEA XXX.app/Contents/Info.plist" with:
<key>JVMVersion</key>
<string>1.6*</string>

<key>VMOptions</key>
<string>-Xms400m -Xmx1248m -XX:MaxPermSize=192m -XX:PermSize=192m -Xbootclasspath/a:../lib/boot.jar -ea</string>

Here usually I try to run "open /Applications/IntelliJ IDEA XXX.app" and I get:
LSOpenFromURLSpec() failed with error -10810 for the file /Applications/IntelliJ/IntelliJ IDEA XXX.app

The the solution is (as root):
cp /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub64 /Applications/IntelliJ/IntelliJ\ IDEA\ XXX.app/Contents/MacOS/idea

For Safari and Firefox, I still don't manage to do it!

Hope I won't have to do this too much in the future, once everyone agrees on JDK 1.6 64 bits as Mac OS X default.

Maven and JavaFX, the story of TwitterFX POM

2009-05-11T23:09:00.002+03:00

I posted on the JFrog's mouth our story of migrating TwitterFX codebase to Maven.
We had fun, and we'll show it all at JavaOne.

Why natural selection did not kill the scientists?

2008-12-30T10:56:00.001+02:00

A new post on Nothing is Infinite seems good for software techies too :)
Why natural selection did not kill the scientists?

Obama from a 9 year old!

2008-11-22T13:32:00.000+02:00

Being a French man living in Israel, we have 3 languages at home: English, French and Hebrew.
And many of my friends around here have this trilingual environment.
Last week the 9 year old son of one of them told him:
- Dad, Obama is talking Hebrew?
- No, Why do you ask?
- Because he keep saying: Yes Oui Ken!

Note: "Yes We Can" sounds like Yes, Oui (yes in French), Ken (yes in Hebrew).

Amazing no?
I found out that it was already used in Obama's campaign.

Anyway, international triple yes from an Israeli 9 year old kid...

Lists and Contextual Menus, MMI nightmare!

2008-11-20T14:36:00.001+02:00

I'm more of a "server side" kind of developer.
When I see too much HTML, CSS and Javascript, I need pills!
Still, I like to challenge the MVC architecture of UI frameworks. I even wrote my own web framework for fun (but some poor developers, in India I think, are now suffering from it), and played with Swing developing Stellarium4Java.

So, UI is not my cup of Tea. Now, for the latest release of Artifactory, I needed to managed the communication between the UI Designer and the Web developers. I learned a lot from this interesting experience.
During this process I encountered a really basic UI design issue. It was so basic I got worried I missed something!
The point is: The way we are used to manage lists, selections, actions and contextual menus is totally incoherent.

In real UI applications (fat client and Ajax), you get a list of elements and then you can act on them. Usually, you select a line, then some Action (Buttons, Menus) become enabled and you can activate them. But to minimize the amount of clicks and mouse gestures there are also contextual menus. This is where it gets weird...
You select one line, and then can actually "right click" on another one. That way, the list of Actions on the contextual menus does not match the one in buttons and menus.
You can force select the line where you right click, but few Applications are doing it!

The other issue is that contextual menus are really not that great (i.e. I hate them!):

They are not Web Browser friendly.
They don't actually save much in terms of clicks and gestures (right click, move, left click).
They get in the middle of reading the lists of elements.
They never disappear when you want them to, and always disappear before you find the menu item you want to click on.
To remove them go away you need to click elsewhere, crossing your finger you did not actually click on "buy in one click" button.

One solution on the Web (and on the iPhone/iPod, where there is no right click :), is to add action buttons directly in the list itself as columns. That works and can be nice looking (with good icons) but this technique get very heavy (bunch of garbage icons all over). Anyway, it is not scalable: 5 icons it's already too much.

So, the UI designer came with the really cool idea: A hovering toolbox appearing on the side of the list when rollover the line element.
At first, I thought:

It may work but we'd be going against a big UI muscle memory about how to use a list.
People will hate it!
The toolbox is too far from where my mouse is, and going there will be very annoying.
We are not here to reinvent UI and Men Machine Interaction!

But, anyway I took the chance and we implemented it. To see it, you can go to Artifactory live demo, do a quick search on "log" for example, and hover above the list. It's still a beta version and the previous select/link actions are not removed, so it may be confusing. As anonymous user your action list is limited, but you can still get the feel of it.

I'm using this feature for 2 weeks now and frankly: I love it!
I hover on the list in the left side of it, I can read the line I'm on, and then activate the action with one click. Just natural moves and ONLY ONE click.

May be I'm under the influence (it's our application at the end :), and that's why I'm anxiously waiting for the feedback!
What do you think?

IT opportunities in the current financial crisis?

2008-10-30T16:19:00.001+02:00

I'm not optimistic, but here is a fact: For more than 20 years (since the 1987 crash) or in some cases since the usage of computers in companies, the IT budgets of financial institutions (banks, insurance companies, stock markets etc.) ALWAYS go up.
In the meantime, technologies went from Mainframe, to Client/Server, to Web 1.0, to Web 2.0, to SOA, to Virtualization and now Cloud Computing. But in spite of all the technological advances, IT budgets ALWAYS go up. I've given consulting services to many banks and insurance companies, and one thing got increasingly clear: If you're trying to sell a software that will reduce their IT budget... Forget it!

Of course, the financial institutions' needs from IT increased in the last 20 years. They want to setup new services and products (online banking, new policies, new mortgages :) faster than their competitors. But the increase in end user demands is an order of magnitude lower than the technological advances in hardware and software. IT budgets should have gone down, and insurance premiums and bank fees also. But no - IT budgets ALWAYS go up.

I think the main reason is Wall Street. If you are Bank of America, and someone finds out you're reducing your IT budget... Your stock will go down immediately!

A month ago after 20 years of IT budget increases all the CIO and IT department in financial companies have a huge amount of cash fat.
Where the fat goes?

Buying hard to install and unmaintainable software (you need to keep all these engineers) from BIG vendors.
Buying low performance hardware for incredible amounts of money.
Of course, a big team of developers and system engineers to oil down the cranky machines.

And now, for the first time all the CIOs have only one goal: Reduce your IT budget!
IT department in financial companies will never be the same!

From my knowledge, and experience with theses companies their IT budget is about 3 to 5 times bigger than it should be. I don't think they will go all the way and slash 80% of the IT department, but what's for sure, they'll slash the vendors, and contractors.

I think one big software/hardware company will suffer big time from this change because it's living and breathing of this fat. The saying was that a CIO choosing IBM will never get fired for his choice (even he wasted time and money on a failed project). Today that thinking changed.

So, where are the opportunities?
Well, now you can really sell and prove the advantages of modern technological advances to financial CIO. They will be sensitive to TCO, developer productivity, software quality and maintenance.

The issue is that no CIO will start a costly migration project now! So the current state of IT will be frozen for some time. But, some companies will really analyze what's going on and make a decision to go with open source, agile and distributed all the way.

Things will change in banks and insurance companies IT departments, let's hope WebsFear does not blackmail their customers again...

Originally posted on dzone

All new?

2008-09-10T11:41:00.000+03:00

The amount of new Web adventures going on around me starts to make a big pile. So, instead of twittering them with 144 characters, here they are:

A very good content Podcast about Java on server side from AlphaCSP consultants: The Alpha Pub. I really enjoyed the show, and the latest interview with Alef Arendsen has very good content. Thanks, Ophir for setting up this!
The JavaEdge 2008 is on the way, and it's going to be even better than last year!
JFrog.org just released the version 1.3.0-beta-3 of Artifactory with the integration of Jersey, which was a lot of fun to do.
I sarted a new blog to release in the wild my toughts around Space, Physics and the bad taste left by the failure of Super String Theory!

That's a lot of good stuff coming, and I'm really missing Stellarium4Java and OpenJDK, but that's life... Need to set priorities, and be happy about what you did not do!

Using Jersey for exposing REST services

2008-07-30T11:21:00.006+03:00

I just started integrating Jersey in Artifactory and I have to say: I'm impressed!
Like the XFire (still crying on its death :( ) I really like the process of: Write a simple annotated POJO, compile and run, that's it.

Anyway, since I encountered a couple of issues, and implemented some nice extra (XStream adapter and Spring beans injection) here are my findings.
First thanks to getting started entry and getting started with jersey that convinced me Jersey is the way to go.

Getting started

I'm using Maven and Jetty and so running the HelloWorld example got this bug 70. Setting up the Annotation scanner per Java packages solves the problem, and anyway sounds a lot more manageable to me. So here is my web.xml (for 0.8):

<servlet>
    <servlet-name>Jersey Web Application</servlet-name>
    <servlet-class>org.artifactory.rest.servlet.ArtifactoryRestServlet</servlet-class>
    <init-param>
        <param-name>com.sun.jersey.config.property.resourceConfigClass</param-name>
        <param-value>com.sun.jersey.api.core.PackagesResourceConfig</param-value>
    </init-param>
    <init-param>
        <param-name>com.sun.jersey.config.property.packages</param-name>
        <param-value>org.artifactory.rest</param-value>
    </init-param>
    <!-- Usable only in 0.9 version of Jersey
    <init-param>
        <param-name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name>
        <param-value>org.artifactory.rest.common.AuthorizationContainerRequestFilter</param-value>
    </init-param>
    -->
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>Jersey Web Application</servlet-name>
    <url-pattern>/api/*</url-pattern>
</servlet-mapping>

So now the annotations scanner reads correctly my classes, and I needed only 2 dependencies in my pom.xml:

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>servlet-api</artifactId>
    <version>2.5</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>com.sun.jersey</groupId>
    <artifactId>jersey</artifactId>
    <version>${jersey.version}</version>
</dependency>

XStream Message Reader and Writer

Most of my object model classes are using XStream, so I wanted Jersey to marshall/unmarshall automatically any XStream class. It was amazingly easy, here is my XStream message reader provider class:

@ProduceMime({"application/xml", "text/xml", "*/*"})
@ConsumeMime({"application/xml", "text/xml", "*/*"})
@Provider
public class XStreamAliasProvider extends AbstractMessageReaderWriterProvider<Object> {
    private static final Set<Class> processed = new HashSet<Class>();
    private static final XStream xstream = new XStream();
    private static final String DEFAULT_ENCODING = "utf-8";

    public boolean isReadable(Class<?> type, Type genericType, Annotation annotations[]) {
        return type.getAnnotation(XStreamAlias.class) != null;
    }

    public boolean isWriteable(Class<?> type, Type genericType, Annotation annotations[]) {
        return type.getAnnotation(XStreamAlias.class) != null;
    }

    protected static String getCharsetAsString(MediaType m) {
        if (m == null) {
            return DEFAULT_ENCODING;
        }
        String result = m.getParameters().get("charset");
        return (result == null) ? DEFAULT_ENCODING : result;
    }

    protected XStream getXStream(Class type) {
        synchronized (processed) {
            if (!processed.contains(type)) {
                xstream.processAnnotations(type);
                processed.add(type);
            }
        }
        return xstream;
    }

    public Object readFrom(Class<Object> aClass, Type genericType, Annotation[] annotations,
            MediaType mediaType, MultivaluedMap<String, String> map, InputStream stream)
            throws IOException, WebApplicationException {
        String encoding = getCharsetAsString(mediaType);
        XStream xStream = getXStream(aClass);
        return xStream.fromXML(new InputStreamReader(stream, encoding));
    }

    public void writeTo(Object o, Class<?> aClass, Type type, Annotation[] annotations,
            MediaType mediaType, MultivaluedMap<String, Object> map, OutputStream stream)
            throws IOException, WebApplicationException {
        String encoding = getCharsetAsString(mediaType);
        XStream xStream = getXStream(o.getClass());
        xStream.toXML(o, new OutputStreamWriter(stream, encoding));
    }
}

Spring integration

All my backend objects are Spring service bean, so I wanted autowired injection of Spring beans. Here again it was really nice. I defined my own annotation @SpringAutowired, and created a SpringBeanInjector for it that was fetching my context for a bean of the type of the injected field. Here I'm adding manually the list of "injectable" interfaces, because: I don't have an annotation to identify them :) With EJB3 it should be a lot cleaner to use @Stateless.
Here is my annotation:

@Target({ElementType.PARAMETER, ElementType.METHOD, ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface SpringAutowired {
}

And here the bean injector class as inner class of my Servlet:

public class ArtifactoryRestServlet extends ServletContainer {
    @Override
    protected void configure(ServletConfig config, ResourceConfig rc,
            WebApplication application) {
        super.configure(config, rc, application);

        Set<Object> pi = rc.getProviderInstances();
        pi.add(getSpringBeanInjector(AuthorizationService.class));
        pi.add(getSpringBeanInjector(CentralConfigService.class));
        pi.add(getSpringBeanInjector(UserGroupService.class));
        pi.add(getSpringBeanInjector(AclService.class));
        pi.add(getSpringBeanInjector(RepositoryService.class));
        pi.add(getSpringBeanInjector(ArtifactoryContext.class));
        pi.add(getSpringBeanInjector(SecurityService.class));
    }

    public static <T> SpringBeanInjector<T> getSpringBeanInjector(Class<T> beanInterface) {
        return new SpringBeanInjector<T>(beanInterface);
    }

    public static class SpringBeanInjector<T>
            implements InjectableProvider<SpringAutowired, Type>, Injectable<T> {
        private Class<T> type;

        public SpringBeanInjector(Class<T> t) {
            this.type = t;
        }

        public ComponentProvider.Scope getScope() {
            return ComponentProvider.Scope.PerRequest;
        }

        public Injectable getInjectable(ComponentContext ic,
                SpringAutowired autowired, Type type) {
            if (type.equals(this.type)) {
                return this;
            } else {
                return null;
            }
        }

        public T getValue(HttpContext context) {
            /*
            (ArtifactoryContext) context
                    .getAttribute("org.springframework.web.context.ROOT");
            */
            ArtifactoryContext springContext = ContextHelper.get();
            if (springContext == null) {
                return null;
            }
            return springContext.beanForType(type);
        }
    }
}

Conclusion

I really liked the WebBeans consept and the Guice injection, but actually working with these nice modern Framework architecture on a real case proved that's the way to go.
Morale: "Chapeau bas for Paul Sandoz at Sun"

Stellarium For Java Alpha release!

2008-02-29T21:11:00.001+02:00

After a lot of ups and downs, we (Jerome Beau and myself) are really happy to release an alpha version of Stellarium For Java (S4J in short).
This project is a migration of the very successful C++ project Stellarium created by Fabien Chereau.
For the record, I really like this C++ version but I am missing a lot of features:

Ability to add stars catalogs like in Celestia
Loading data on demand from the web instead of the resources in the installation
Resizable window (I have a Widescreen and need to play with config file)

So, as a open source minded guy, I looked inside the code... And I got flashbacks! I found myself, back in time, when I was doing C++ for Video servers, and MFC applications.
I laughed, and then tried to find a Java version of any Astronomy software. I found Stellarium4Java.
The project had started a year before with Jerome and Arnaud Barre. At the time, it was in the middle of the pure code migration from Stellarium C++ to Java.
It looked like a small decision at the time, so I joined the project! Today I can say: It took time and energy to get were we are today.
But, thanks to the great work of the JOGL team in Sun, and all the Java open source projects, here or here is the alpha version loading with Web Start. I'm still working on the web distribution of resources, so for the moment you will have to wait for 13Mo of download :(
There is a Wiki page on jfrog with the jnlp links (they are still a moving target ;-) and the bug report access (be nice it's still alpha:-).
The most interesting part is that we got selected for a presentation at JavaOne this year to present this application. We will show how Java and the open source projects really helped us doing this, and what features we got for free from Java!

Side note: This project makes me love Java, every time I'm freeing myself for it.

Closure Campaign 2008

2008-02-18T12:19:00.000+02:00

After many discussion, it is election time (year) for closure.
I voted for the readable, easy to grasp, and "almost" complete implementation of closure: FCM.
The posts of Stephen on the differences are very instructive:

Closures - Comparing the core of BGGA, CICE and FCM

Closures - Comparing control structures of BGGA, ARM and JCA

Closures - Comparing closure type inference

I hope this vote will have an influence on the JCP...

Wild Java Properties, The Wild Part

2008-01-28T21:54:00.000+02:00

Following my previous blog entry, I tried to use Remi's property implementation for JPA or WebBeans. These 2 recent (WebBeans being still in diapers) frameworks really represent what I need from the property proposal. Generally I'd like to be able to do things like:

JPA (Hibernate)

@Id
public property long id get;

@Column("FIRST_NAME")
public property String firstName;

new Criteria(Person#firstName, value);

Validations

protected <B,T> void propertyChanged(
java.lang.Property<B,T> property,
Object oldValue,Object newValue) {
    // Activate validation rules and so stop setting the value
}

WebBeans (JSR-299) or Guice

@Log
private static property Logger log;

Wicket or Swing

new TextField(Person#firstName);
new DynamicPanel().addAll(Person.properties());

I'd like to say that Remi's work is truly amazing and is a good first draft. It is open source for us to analyze and contribute to. The benefits of properties in the cases above are:

No issue of annotations on either a field and/or getter/setter methods. All is centralized on one property declaration.
No reflection. All method calls from and to the framework are compiled and wired without using reflection. This is a great boost for UI and Dependency Injection framework.
Introspection without reflection.

Trying to write the properties for the logger example (in fact any DI/IoC framework) and validations framework, I found that this implementation is not helping, and even worse - It's stopping me from doing what I need. Here are the limitations:

The first problem I encountered is that writing get and set blocks inline looks really good but breaks Object Orientation. I cannot do inheritance or use polymorphisms in these blocks. I ended up having more boilerplate code than without the usage of properties.
The second is that the private field exists only if there is no get/set block. So, if you wish to write getter/setter that uses a field, you need to declare this field. Suddenly, a lot of the generated syntactic sugar disappears and you find yourself writing almost as much as before.
The third issue is that encapsulation is asymmetric. What I mean by that is System.out.println(firstName) will use directly the field, but this.firstName = "toto" will become this.setFirstName("toto");

So, I tried to see how I can solve these limitations. Since modularity is the most important feature for me, a clean solution for the DI framework property issue is critical. This can really turn Java into a true Component based platform at its root. So as for the Logger issue I actually want to write:

private static property Logger log
init {log = Logger.getLogger(Person.class.getName());};

I added here some init block in the same line as the get/set block, since this is really what I want - to declare how the field is initialized. But, I'd like to write this once and reuse it. Furthermore, I want the init to be executed when the field (either static or instance) is declared, or on demand (lazy init). The only good way to do it is to have a class wrapping the Type2 property. It would look something like:

public class Person {
    public final static Property<Logger> log = new LazyInitProperty() {
        protected void init() {
            value = Logger.getLogger(Person.class.getName());
        }
    };
    public final Property<String> lastName = new Property<String>();
}

public class Property<T> implements BaseProperty<T> {
    private T value;
    public T get() {return value;}
    public void set(T value) {this.value = value;}
}

public abstract class LazyInitProperty<T> implements ReadOnlyProperty<T> {
    protected T value;
    public T get() {
        if (value == null)
            init();
        return value;
    }
    protected abstract void init();
}

Of course it is missing a lot of good (or not) synchronized, but the idea is here. Basically I ended up with the Joda Beans or java.net bean properties concept, and also Yardena's idea.
This is an old idea about the notion that properties don't need to be a language feature. Take a look at What Makes Bean-Properties Special, and 2 discussions on The Java Posse Google group: Wonder what Joe thinks of this properties solution, Still hope for first-class properties.

Conclusion

The solution to all of my problems: Properties should not be a language feature!
When I got there for the first time I thought: WTF! But that's a logical step, isn't it? Properties are field level encapsulation with accessors and events. You can do this in any OO language with a class wrapping your field. So why are we suffering?

The main problem with open source properties projects is that all the classes and interfaces of PropertyType2<T> and PropertyType1<B,T> belong in the JDK. They need to be made a standard so that all framework and component will use them. To be useful, the bean-properties project needs to be in a JSR and included in Java 7. Why didn't any open source property project became a de-facto standard? It's amazing how many Property classes already exists out there!

Joda does binding with no boilerplate but changes the getter/setter style.
Bean-properties does the binding boilerplate code (and even setter/getter) with bytecode generation. Personally I prefer good syntactic sugar.
Annotations on these specific "Property" fields are not understood by 3rd party framework like JPA.
You need to declare public final fields.
Even if the amount of code is quite low, you still repeat yourself in the field declaration.
Bean introspection and Property object access are done using Strings and reflection.
The amount of features (Read, Write, initialized, Lazy, bind), types (Simple, Array, Set, Map,...), Modifiers (private, public, synchronized, volatile, for field/getter/setter), are generating a combinator which is impossible to implement with a Property<T> class hierarchy.

Personally, I don't find items 1 and 4 to be a problem. The getter/setter style is related to encapsulation. It's the OO convention for dealing with properties. For me, automatically transforming person.firstName="toto"; to person.setFirstName("toto"); in Java today is very confusing. With Joda style, the type of person.firstName is Property<String>, so when "toto" is assigned to it, something needs to box the value! Transforming person.firstName="toto"; to person.firstName.set("toto"); looks very close to the boxing/unboxing feature, doesn't it? Basically I feel comfortable with the idea that if you want to encapsulate a field in a Property, you should use a class for the encapsulation, not getXXX() and setXXX() methods. And if it's a class, make it clear, don't hide it. So, as for point 4 - a property may be visible or not. Here, I have a strong issue with visibility control around the field, getter, setter trio. Today, I do use different modifiers for each of them. Is it really useful?

So what!

Well, my final wild idea is:

I want a unique Type1 interface in the JDK (like Remi's Property<B,T>) called PropertyAdaptor<B,T> to be separated from bean-properties class. This can (and will in my kijaro branch) be implemented with an abstract enum.
I want Person#firstName to return the above Type1 enum instance, and then use it to remove the need to change the class format (similar to what needs to be done in Remi's implementation today).
I want a nice, small and simple Type2 property interfaces and classes hierarchy, that are making a heavy usage of Annotations and the above unique Type1 enum entry for initialization. Basically this means making some "kind of" bean-properties project part of the Kijaro JDK (KDK ;-).
The Type1 methods "T get(B)" and "void set(B,T)" should delegate (by the javac phase) to "T get()" and "set(T)" of the Type2 instance. This would remove the need for reflection.
There should be no restrictions on extending classes or interfaces in the JDK based Property<T> (Type2) hierarchy and on using them. This way, WebBeans and JPA can provide state-of-the-art properties implementations tuned for their needs. This would provide the loose coupling and transparent state management at a language level without reflection.
The property keyword should be replaced by the above annotation. This Annotation will activate all the syntactic sugar that would remove the standard properties boilerplate code. But, most of the actual Type2 implementation will come from the super class and extra annotations.

Each time I apply the concept of Type2 property class provided and implemented by frameworks, I find a new way to clean and optimize my code:

Dependency Injection (OSGi), dynamic object allocation and redirection - can be done by calling set on the required properties, by having a smart get or by setting a dirty flag. Whatever the solution be, it is totally transparent to the business code declaring the property field.
Persistence framework providing validations (from DB type, data and annotations) and listening to property changes.
Swing bindings of course, but used by higher level framework that can manage full business objects and all their properties.

What I'm gonna' do!

Independently of the wild crazy idea of properties by annotation as a language feature, the property list introspection will be done using a unique abstract enum java.property.PropertyDefinition<B,T>:

public abstract enum PropertyDefinition<B, T>
implements PropertyAdaptor<B, T> {
    public abstract T get(B bean);
    public abstract void set(B bean, T newValue);
    public abstract Property<T> getProperty(B bean);
    public String propertyName() {
        return name();
    }
    public Class<B> getBeanClass() {...}
    public Class<T> getPropertyType() {...}
    public Annotation[] getAnnotations() {...}
    public boolean isReadable() {...}
    public boolean isWritable() {...}
    public int getFieldModifiers() {...}
    public int getGetterModifiers() {...}
    public int getSetterModifiers() {...}
}

And the javac generated code will look like:

public class Person {
[...]
    public static enum properties<T> extends PropertyDefinition<Person,T> {
        <String> firstName,
        <String> lastName,
        <Integer> age
    }
}

The above work is a simple merge of Remi's implementation and the abstract enum. On top of that, I'll implement the generic Type2 thing. First an annotation needs to be associated with a Property<T> (Type2) abstract class. I'll use a meta-annotation PropertyClass, so anyone can declare a future @Property annotation.

The meta annotation:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.ANNOTATION_TYPE)
public @interface PropertyClass {
    Class value();
}

The specific annotation for a basic property:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
@PropertyClass(BasePropertyImpl.class)
public @interface BasicProperty {
    PropertyAccess value();
}

The specific annotation for a property that can be bound:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
@PropertyClass(ObservablePropertyImpl.class)
public @interface ObservableProperty {
    // Using FCM
    #void(PropertyStateEvent) onSet default null;
}

Then, the bean class:

public class Person {
    @BasicProperty(PropertyAccess.READ_WRITE)
    private String firstName;
    @ObservableProperty(Person#firstNameChanged)
    private String lastName;
    @BasicProperty(PropertyAccess.READ_ONLY)
    private int age;

    private void firstNameChanged(PropertyStateEvent se) {
        System.out.println("property changed "+se);
    }
}

And so the boilerplate code generated by javac will look like:

public class Person {
    @BasicProperty(PropertyAccess.READ_WRITE)
    private final BasePropertyImpl<String> firstName =
            new BasePropertyImpl<String>(properties.firstName);
    @ObservableProperty(Person#firstNameChanged)
    private final ObservablePropertyImpl<String> lastName =
            new ObservablePropertyImpl<String>(properties.lastName);
    @BasicProperty(PropertyAccess.READ_ONLY)
    private final BasePropertyImpl<Integer> age =
            new BasePropertyImpl<Integer>(properties.age);

    private void firstNameChanged(PropertyStateEvent se) {
        System.out.println("property changed "+se);
    }

    public static enum properties<T> extends PropertyDefinition<Person,T> {
        <String> firstName,
        <String> lastName,
        <Integer> age
    }
}

And all accessors to person.firstName will be wrapped in javac with person.firstName.set() and person.firstName.get().

This proposition respects Object Orientation, it is very flexible and open for future extension. It removes a lot of boilerplate code and makes Java ready for easy-to-use components. For example, by applying this solution IoC frameworks can really be "inverted". What I mean by that is that instead of trying to invoke setXXX() on the components at the right time (object life cycle and/or component state), they can simply provide a state-of-the-art getter in the property type2 class that will fetch the right object at the right time, all the time. This is transparent decoupling, keeping type safety and without using reflection.

So it solves some (but not all) of the issues like:

Yardena's need for flexible property behavior and generics issue with properties,
Eric Burke's ability to have more flexible binding
My need for using FCM pointer in properties declaration. Which methods init, bind, listen, and so on.

The only thing that property as a language feature will have a hard time providing is dynamic creation of properties, but that's another story.

A few more white nights are ahead of me so I can put all this in kijaro, I guess ;-) Unless someone finds a good reason to stop me in my wild Java experience!

Wild Java Properties, The Road So Far

2008-01-28T12:51:00.000+02:00

First I'd like to thank Alex Miller for keeping good track of links regarding properties in Java 7,
I don't have to repeat them!

I'll just add a few links:

The kijaro project has the first version of Remi Forax's Property implementation.
The google doc by Remi that documents this first usage of property as a language feature (as far as I know it's the only one).
The usage of this implementation with Beans Binding in Remi's blog entry.

After integrating my work on Abstract Enum in the kijaro project (abstract enum branch, to access it you need to be a kijaro reader), I started merging Remi Forax's branch with one simple goal: Having the list of properties of any class automatically generated (syntactic sugar) as an enum! One of Remi's comments about using enum for property enumeration complained on the inability to use Generics with enums. With Abstract Enum it is possible, and I'll show how here.

The benefits of using abstract enum to enumerate properties are:

Easy and type-safe properties introspection: MyClass.Property.values() returns the collection of MyClass.Property<MyClass,?>;
Easy and type safe conversion from a string to a property object: MyClass.Property.valueOf("firstName") returns MyClass.Property<MyClass,String> MyClass#firstName;
I can switch (aProperty) {case firstName:...};
MyClass#myProperty is an instance of MyClass.Property and so I can use == comparator with no risk.
I can use MyClass#myProperty in annotations that accept the abstract Enum PropertyAdaptor as parameter. Things like @LinkTo(Person#firstName).

Before I started coding I played, reviewed and analyzed the current implementation, and I will try to describe how it works. Here is the basic example using property keyword ("property" is not really a keyword since it can be used only before the type declaration of a member, but anyway):

public class Person {
    public property String firstName;
    public property String lastName;
    public property int age;
}

Analyzing the syntactic sugar generated by Remi's implementation, I needed to clarify where are the Type1 (Bean-independent property: aka per-class, property-proxy, property adaptor) and Type2 (Bean-attached property: aka per-instance) properties classes and instances. These types are nicely defined in Stephen Colebourne's blog Java 7 - Properties terminology. Remi calls the Type1 a "Property Literal" and it is implemented with an anonymous class inheriting from a new class in the JDK: java.lang.Property.

For Type2 there is no need for a class since the basic property boilerplate code generated is:

private String firstName;
public String getFirstName() {return firstName;}
public void setFirstName(String param) {firstName = param;}

The above code is the syntactic sugar created by javac, and so not editable in any way. For the Type1 the generated code is:

public static Property<Person, String> firstName() {
    return new Property<Person, String>(
            "firstName",
            String.class,
            Person.class) {
        public String get(Person person) {return person.getFirstName();}
        public void set(Person person, String s) {person.setFirstName(s);}
    };
}

And for Bean introspection (getting the list of properties) another piece is generated:

public static Property<Person,?>[] properties() {return $PROPERTIES;};
private static Property<Person,?>[] $PROPERTIES = new Property[]{firstName(),lastName(),age()};

This is the code for a basic property, but there are more features implemented like:

Generating a getter method only or a setter method only
Implementing getter and setter inline of the property declaration
And the very powerful 'bound' which allows automatic events on setXXX() without boilerplate code.

For example if lastName is read only with a provided block and age is bound, the Person class will be:

public class Person {
    public property String firstName;
    public property String lastName get { return "XXX"; };
    public property int age bound;

    protected <B,T> void propertyChanged(java.lang.Property<B,T> property,Object oldValue,Object newValue) {
        System.out.println("property changed "+property+" "+oldValue+" "+newValue);
    }
}

Here is the generated code:

public String getLastName() {return "XXX";}

public static Property<Person, String> lastName() {
    return new Property<Person, String>(
            "lastName",
            String.class,
            Person.class) {
        public String get(Person person) {return person.getLastName();}
        public void set(Person person, String s) {throw new UnsupportedOperationException();}
    };
}

private int age;
public int getAge() {return age;}
public void setAge(int param) {
     int oldValue = age;
     age = param;
     this.<Person,Integer>propertyChanged(age(),oldValue,param);
}

public static Property<Person, Integer> age() {
    return new Property<Person, Integer>(
            "age",
            int.class,
            Person.class) {
        public Integer get(Person person) {return person.getAge();}
        public void set(Person person, Integer s) {person.setAge(s);}
    };
}

That's a lot of syntactic sugar, but that's the point of properties, isn't it: Value objects WTF!!?!!2!. This property implementation works very well for Swing and Beans Binding implementation like Remi's demo shows. You can also write very quickly generic equals and hashcode methods based on the properties list. But, as a backend developer I also need properties.

Property as language feature is not just syntactic sugar generation it's really solving a problem that just CANNOT be solved in Java today: How can I safely (which means maintaining type safety) pass a field or method (which are the elements that represent a property today - getter/setter) to a framework like JPA, WebBeans, Validations framework, Wicket, Swing Bindings, and all the others developed out there? Today, you NEED to pass a String (EL) and do reflection. That does not make sense. When I know a UI component is bound to Person.firstName, why do I need to write bind(Person.class, "firstName") and loose type safety, compiler existence check (whether or not firstName property exists), and so refactoring ability.

Next post, I'll expose how I wish to have properties for all ;-)

The Java Wild series!

2008-01-28T12:21:00.000+02:00

This blog has been silent for more than 2 months now... And this just after I started some good work on the great kijaro project. I'm really happy to say that it was for a great trip to Guatemala where we picked up our newly adopted child.

This is the first time ever since I discovered coding (1985) that I did not write one line of code for 2 months in a row ;-) Very relaxing, and I still have a very hard time going back ;-)

Anyway, even without coding I've spent a lot of time reading blogs and article about The End of Java and other worrying thoughts. All this ended up in this Java Wild entries. Playing with Kijaro and the different patches that can change the Java language clarified what I really want from Java and the platform.

The conclusion is that the most critical feature needed for Java 7 (and maybe even for 6 update N) is: Modularity. The JDK needs to be built out of nice dependent modules with superpackages and JSR-277 (or OSGi) packaging. This is critical for the future of Java. And Stephen's blog entry about the JCP inefficiency and OSGi vs. JSR-277 war is, for me, the darkest cloud above Java.

Mostly my thinking about the topics covered in my Java Wild series goes: "If it helps write to modules: good". But beside this I really went wild, and it was fun.

The first entry is about properties that really got bad publicity lately. One entry was too much, so there is: "Wild Java Properties, the Road so Far" and "Wild Java Properties, The Wild Part".
The second entry is about extension methods and how Modules and API can really benefits from them.
And the third is, again, about checked exceptions.

I wanted to publish all these in one go, because I hate suspense ;-), but time is running out. So, I'll do it in steps.

Anyway, the "sad" conclusion of all this work and thinking is that I bought the Scala book, and starting today, will start playing on the grass of Java neighbors. May be, it is really greener?

The Ugly Duckling of Java!

2007-11-12T20:14:00.000+02:00

It took me time to find a good title. It could have been things like:

What's so ugly about explicit type parameters?
Done with inference!
Let's pave the way for reification and promote explicit type parameters!

Chaotic java already made a similar point: Can someone please explain type inference to me?.

But all these compiler language terms, are showing off for no reason. The problem is not so complicated, but the stakes are high. Like Eric Burke says in his blog A Syntax Trick I Was Not Aware Of, there is a syntax in Java that very few people use and encounter: Explicit type arguments or parameters. One of the rare places where you may have encountered it, is in the JLS and javac code and test code. So, it looks like:

List<String> empty = Collections.<String>emptyList();

The first reaction, for most Java developers, is: WTF?!

But I remember the first time I started converting some 1.4 code to use generics and wrote:

Map<Integer, Map<String,Thing>> messages;

Wow, that's a lot of <>! And when I saw the amount of bugs the compiler gave me (wrong casting and objects in put()), I really thanked the <>, and asked for more ;-)

Why, the Java compiler wants to hide <> of explicit type parameter?
On IntelliJ the <String> before the emptyList method, is underlined with the remark: Explicit type arguments can be inferred. Basically, it means the compiler can be smart enough to replace the content of <> with the correct type. Great, at first. But wait?
Like Stephan says in Explicit Static Types are not for the Compiler, but for the Developer - Duh, the compiler knows a lot more stuff. He can remove a lot of all this types we are writing.
I love strongly type Java, and all the types repetition. I love the types in the code because it's more readable.

Question: Why explicit type parameters are an exception?
Answer: It got the Ugly Duckling stamp for some reason! Some said that it was dangerous for kittens!

Personally, I think there are 2 reasons:
- When Java 5 came out it looked like too much <> all over and Sun tried to remove some unneeded ones.
- It lacks consistency. I would really like to know, why explicit type parameters are declared BEFORE the method name? When, in constructor and type declaration, they are declared AFTER. In the later, they are enforced, and everybody is using them!

Another worrying inconsistency that may appear in Java 7 is around the "Short instance creation" issue. For example the nicest proposal so far is Neal's constructor type inference. I really like this proposal because it enables inference to work, but you SEE it working. It's not hidden woodoo compiler stuff. According to this proposal instead of:

List<String> list = new ArrayList<String>();

you'd write:

List<String> list = new ArrayList<>();

Again, a strange sense of peculiarity for the method emptyList. In the type inference block of Alex Miller Java 7 page, you see the peculiar treatment of methods compare to types.
Why nobody wants:

List<String> empty = Collections.<>emptyList();

It's the same, no? Let's be consistent!

Now, the main big issue that I have with this inference vs. explicit issue, is that it's moving Java away from reification of generics. It's going in the wrong direction. I just refactored some JPA code from:

// The Class of the bean implementaion provided by
// the framework and unknown to the client
Class implClass = ...;
MyBeanInterface b = (MyBeanInterface) em.find(implClass,pk);

MyBeanInterface b = em.<MyBeanInterface>find(implClass,pk);

It may be just changing casting to generics. But that's the point of generics being way nicer and more powerful.

The other point is, when generics will be reified I'd be closer to the perfect methods:

MyBeanInterface b = em.<MyBeanInterface>find(pk);
or with VISIBLE type inference
MyBeanInterface b = em.<>find(pk);

These methods will find the implementation from the interface. Exactly what I need, the client code doesn't know about the implementation class, and the code is very clean and readable.

Today, because of erasure, in most methods (80%) that use generic types, you end up having Class<T> or Collection<T> as a parameter. So, inference works most of the time, and it's saving us from having to visualize the Ugly Duckling. For sure, it worked.

Now, for the 20% that still resist the roman empire of javac guru inference power, a new wave is coming. They want to write a "smarter" javac, that will make inference work (Check Kevin Bourrillion and Bob Lee comments here).

Here, there is a shift in the javac thinking, and it's going against readability, since: The "smarter" (or magical) the compiler is, the less "readable" your code is. Furthermore, inference will never be (by definition) 100% sure. So, why bother? The final code is more readable anyway...

IMHO: The kittens are safe, and reifying generics is more important than inference.

Is JSF following EJB road?

2007-11-08T19:00:00.000+02:00

First I have to be clear: I don't like JSF!

But, I did not like EJB 1.0 when it came out. And still, I did bet on it's success.

When EJB 1.0 came out I just finished my personal implementation of a CORBA Application Server, so this new Specification was "way below" my stuff. I was young, but still you cannot stop the machine coming from Sun, BEA and after quite some time IBM.
EJB came in a world were crazy techies (like me) thought they can build great servers which can handle enormous load. So, this specification really calm down crazy development and provided a good base for containers (usage and implementation).
But, it was flawed, right from the beginning.
All the API, interfaces and design concentrated on showing off the "great" power of the Application Server. Look how I can passivate/activate, look I can do security and transaction, and look I even save in DB for you. And for every "look" as a poor developer you needed to answer (implement, declare) something.
There was no escape, your code was full of unwanted pollution.
EJB 2.0 did not solve the problem and actually added more "look" at my beautiful AS: Messaging and CMP.

We had to wait for JBoss guys to take over EJB specification for 3.0, to finally end the developer nightmare.

And now, the funny trick. Please replace in the above EJB with JSF...
Amazing, it fits.

JSF came when Web UI was a total mess (All Struts usage override most configuration and basic classes) and everyone had his own "best/better" implementation.
So, JSF did some clean up in Web UI design and implementation.
But, JSF is really "showing off": Look my nice lifecycle in 42 steps, Look my nice big list of jsp tags/attributes, Look my nice EL, Look my nice XML configuration, and so on.
By "showing off" I mean that you need to fill all this with a lot of unreadable and incomprehensible repetition. And the worst of it you need to master all this in order to:
- debug correctly,
- integrate external stuff (Ajax4JSF and so on),
- create just one JSF UI component (Does someone sells T-shirt with: I wrote my JSF component! without breaking the lifecycle?),
- write stupid HTML pages.

A really good description of all JSF flaws are listed in Gavin blog: EE6 Wichlist
In this blog entries, the first one on EJB the second on JSF, looking quickly at the code examples you understand the gap. EJB is full of nice Annotations and Meta Annotations (the future for sure), and JSF full of ugly XML and Expression Language (scheduled to die).

The biggest conceptual flaw of JSF is the usage of EL.
EL is breaking encapsulation, in term of IoC: it's on the wrong side of the road. Ophir pointed me to a nice essay from Terence Parr "Enforcing Strict Model-View Separation in Template Engines ", that really nicely proves my point.
A UI definition (Web page, Swing panel, ...) should not know about the object graph. If I am a UI designer, I'm not a business modeler.
The answer is in architecture like Wicket and JSR-295 (The EL in this Beans Binding is due to the lack of property support).
In these good architecture: The UI components have an ID related to the page/panel, and the Java developers bind data to these components and receive events from these components. This is the good way to do UI, integrate UI design and manage UI logic. From experience, it works great.

All the other flaws are due to the age of JSF and the fact that it was written for ugly request/response Web UI behavior.

So JSF is today at the stage of EJB 1.0, I can see JSF 2.0 pushing more in the wrong direction, and so having finally a JSF 3.0 were developers will stop having nervous shake when they hear: JSF!

Playing with the full abstract enum!

2007-11-02T16:43:00.001+02:00

Since Neal Gafter released the closure prototype, Ricky Clarkson has been having a lot of fun. He wrote 2 nice blogs:

Both have "Java 7 Example" in their titles - So closures is going in Java 7: Got that!

The Java code is a little scary at first, but after a while it works, you can read it. IMHO: all the inlining of closure syntax can get very confusing. I know they supposed to be, but I played with the code and when you create variables for the closures it helps increased readability.

Anyway, I really like the fact that you can now really test, today, closures and their impact on your code.
All this, gave me the idea to do the same for abstract enum.

The reasons for abstract enum (and there are more I'm sure) are:

I wanted abstract enum for solving the property binding issue in a type safe way.
I found out that you cannot use String Enum.name() and int Enum.ordinal() methods as annotations parameters.
I know there are way too many strings in annotations (methods, fields, scopes, states, package, groups, ...). I don't like strings describing my code.
While I was at it, Steven Coco asked for generics in enums, so it's there also. That happens to be quite an interesting feature, that was already there from Neal (but buggy ;-).

For all those reasons I know abstract enum is a good thing. Changing the javac to implement this feature is at least 2 orders of magnitude easier than implementing closures, so it was within my reach ;-)

I have exposed some mercurial repositories for langtools and for the jdk. You need to have a mercurial working copy of openJDK, then inside langtools run:
hg pull http://www.jfrog.org/hg/openJDK/MASTER/langtools

You can "hg log" to see what's going on, then do:
hg up

The patch for the JDK is very small, and actually (in my view), it is just another valid way (in a Java 5 environment) to do Class.isEnum() and Annotations parsing. The new JDK is needed for the tests to pass because abstract enum are not considered enum by java.lang.Class otherwise :-(.

Type safe reflection

The solution for field binding is straight forward. The abstract enum looks like:

public abstract enum FieldDefinition {
    private Field reflectField;

    public Field getField() {
        if (reflectField == null) {
            Class modelClass = null;
            try {
                modelClass = this.getClass().getEnclosingClass();
                reflectField = modelClass.getDeclaredField(name());
            } catch (NoSuchFieldException e) {
                throw new ObjectMappingException("Field " + this +
                        " does not exists in " + modelClass, e);
            }
        }
        return reflectField;
    }
}

And to use it in my Value Object it looks like:

public class ModelMock {
    private String firstName;
    private String lastName;
    private int age;

    public static enum fields extends FieldDefinition {
        firstName, lastName, age;
    }
}

Of course is not as good as properties as a language support, but it solves my problem. From the above, I extended to property using generics. So, the PropertyDefinition takes the property type as generic parameter, so the generic getter/setter methods are generic typed. I took (type 1 and 2) from Stephen Colebourne's Weblog Java 7 - Properties terminology, and converted it.

Before abstract enum there was:

public class MyBeanBefore {
    private String firstName;
    private String lastName;
    private BigDecimal height;
    private Date dob;

    public PropertyDefinition<MyBeanBefore, String> firstNameProperty() {
      return ReflectionAttachedProperty.create(this, "firstName");
    }
    public PropertyDefinition<MyBeanBefore, String> lastNameProperty() {
      return ReflectionAttachedProperty.create(this, "lastName");
    }
    public PropertyDefinition<MyBeanBefore, BigDecimal> heightProperty() {
      return ReflectionAttachedProperty.create(this, "height");
    }
    public PropertyDefinition<MyBeanBefore, Date> dobProperty() {
      return ReflectionAttachedProperty.create(this, "dob");
    }
}

always using strings :-( And now:

@FieldPrefix("_")
public class MyBean {
    private String _firstName;
    private String _lastName;
    private BigDecimal _height;
    private Date _dob;

    public static enum properties<V> extends PropertyDefinition<MyBean,V> {
        <String> firstName,
        <String> lastName,
        <BigDecimal> height,
        <Date> dob
    }
}

This code actually compile and run (with the strange _ prefix ;-). Cool, no. The full code is under subversion here.
Now, with this, I can find usages, refactor, and get compilation errors for every binding using a field that does not exist. Like in here:

MyBean bean = new MyBean();
PropertyAdaptor<MyBean, Date> dobProperty = MyBean.properties.dob;
PropertyInstance<Date> dobPropertyInstance = dobProperty.getPropertyInstance(bean);

The type safety is not entirely true, since in my own Model class I get Runtime error for mismatching fields in the "fields" enumeration. This can be solve in 2 ways: make fields a keyword in Java and generate it automatically ;-), and/or test your model class and fields enumeration correctly.

abstract enum in Annotations

Like with closures, today when I encounter a problem in some projects, I often end up with: That will have been a lot faster and nicer with closures, and that will be solved perfectly with abstract enum. Now, I know it's the standard disease of being too much into it ;) But still I think it's true.

And abstract enum in Annotations is, for me, a really powerful feature.

So, one problem I had was with JPA schema names, cache names, and fields associations. All those information need to be provided as strings inside annotations. And of course they are repeating themselves a lot, they get misspelled, and basically you loose the strong typing.
So, I wanted to use enum (Schemas, Caches, Fields) to control the strings. But I would hit a dead end: Enum.name() is not a string literal, so you cannot use it in Annotations.
Now, with abstract enum, I have way more flexibility and type safety.
For the caches for example I can have Hibernate declaring something like:

public abstract enum CacheDefinition {
    private CacheConcurrencyStrategy defaultUsage;
    private String defaultInclude;

    CacheDefinition(CacheConcurrencyStrategy defaultUsage, String defaultInclude) {
        this.defaultUsage = defaultUsage;
        this.defaultInclude = defaultInclude;
    }

    public CacheConcurrencyStrategy getDefaultUsage() {
        return defaultUsage;
    }

    public String getDefaultInclude() {
        return defaultInclude;
    }
}

and then in my application:

public enum MyCaches extends CacheDefinition {
    references(CacheConcurrencyStrategy.READ_ONLY,"all"),
    business(CacheConcurrencyStrategy.TRANSACTIONAL,"non-lazy");
}

to use in:

@Cache(MyCaches.business)
class Action {
    ...
}

I wrote a blog (JPA NamedQueries and JDBC 4.0) about how to solve the string association issue in JPA named queries. Frank Cornelis answered with an addition that enables the reuse of query methods. The main problem with this addition is it adds more strings in annotations.
This case can also be solved with abstract enum.

So, if you reached there and you like the language feature of abstract enum: Vote for the RFE: 6570766.

Web Beans and Modules!

2007-10-28T14:42:00.000+02:00

After some good work, the JSR-299 group released an early draft, first published on Gavin King's blog, and now on the JCP site.

The spirit of Web Beans is really good, and the way the annotations came out is very promising. I have nothing to say but compliment the Component Types, Component Bindings, Scopes, Injection, and Interceptors. The Event has the good approach (Event type filter), but looks young at the moment.

Web Beans is really the state of the art "Educational Framework". The technical base is already explored (Guice, Spring, Seam) and is not so complex, but the impact on the developer thinking is really significant. Like every good "Educational Framework" (Struts, Spring, Seam), it makes it harder to do the "bad thing" (hacking, ugly coupling) than the right one (framework driven injection and loose coupling).
I know that if developers start to use these Annotations their code will get cleaner, more readable and manageable.

But, reading through the specs and especially, "4.4.2 Interceptors bindings" and "8. Packaging and configuration", I felt like something was wrong: Where are my Web Beans modules?
I don't want to get into the argument of OSGi or JSR-277, but I was expecting a more modular approach of Web Beans Injection.
What I mean, is that I would like to see a Web Beans "core" defining all the above Annotations for a pure J2SE environment. This would be the specification of how to use Dependency Injection Annotations. On top of that, another specification on how to provide "Components Provider/Injectors" for JEE, JSF, EJB, MDB and so on.
For example, I want to be able to do:

@Log
private Logger log;

just by adding log4j-web-beans.jar in my classpath. In this jar Log4J will provide the Web Beans Component for my class and my environment.
So, with this approach all the EJB, JSF & JEE stuff that really don't have to be there, can be specified separately as: jee5-web-beans.jar, ejb-web-beans.jar, mdb-web-beans.jar, etc.
I think it will make the specifications easier to read and a lot more flexible for all the great future components ;-)

Since I don't like people that complain without proposing something of their own, I tried to see how to do this with the current specification. And, basically it's not missing much.
Today in EJB3 environment, the first thing I do is creating an Interceptor that can inject components from Spring or other sources in my Session Beans. The injection is based on my project level Annotations and it bridges Spring and EJB3 nicely.
So a first solution (not good but...) is to use javax.interceptor.InvocationContext. If the Web Beans container is adding some entry in getContextData(), I can find out the Component Type, the Scope, and other information and decide how to populate all the @Log fields.

A nicer solution will be to have Annotations specified by JSR-299, that will allow me to write something like:

@ComponentProvider
public class Jee5ComponentProvider {

    @Provides(EJB.class)
    public Object getEJB(WebBeansContext wbc) {
        try {
            return new InitialContext().lookup(
                wbc.getDestinationField().getType().getName());
        } catch (NamingException e) {
            e.printStackTrace();
            throw new RuntimeException(e);
        }
    }
}

Here I really did not investigate enough, but I know I'm missing @ComponentProvider and WebBeansContext in the current specification.
What do you think?

JSR-299 or Web Beans

2007-10-17T20:34:00.000+02:00

After postponing for too long, I finally decided to look at Web Beans or JSR-299.

The story is that for our seminar JavaEdge 2007 we invited Gavin King. He accepted to come and to talk about his new JSR, and this was the first time I encountered "Web Beans".
And to tell the truth: The name gave me a cold shower ;-)
What? Gavin started as a backend guru for O/R Mapping, then decided to target the issue of Web development with Seam, and now is "may be" going even higher in the stack with some UI components spec!
It really sounded like Gavin was leading the new spec for some JSF UI widgets :-(

This name really put me off, and so I postponed reading about "Web Beans".
That was a mistake, and a really bad move.

When I saw in Gavin blog, that he was excited about exposing the work done in JSR-299 group, I decided to get into it.

And the conclusion is:

From my personal technical glossary, "Web Beans" has nothing to do with Web, and Beans are not UI JavaBeans.
Gavin did it again.

Before Hibernate the O/R Mapping tools concentrated more on showing off their feature list than helping developer having a persistent model. For Gavin what's important is how the user (poor developer) will communicate with the framework. Powerful features should not show off and complicate the API or the tool. Once the usage is clear, the framework follows.
So after Seam and easy @Conversation, he's leading this great JSR.

"Web Beans" is basically a good (meaning pushing forward) standardization of IoC and DI concepts using Annotations. The overview from Gavin slides of the Silicon Valley JUG, is a really good start to understand what JSR-299 is about.

"Web Beans" really uses the good Guice framework, removes the issue of static scopes in Seam, and helps you create your own meaningful project Annotations. And all this is done true to the Java spirit: in a readable way.
JSR-299 answers some of my needs I had in AADA and I hope it will help projects moving towards creation of more custom Annotations.

So, please, change the name...

First, for once the JSR number is very easy to remember ( 300 - 1 easy to find an association).
Second I always associated Beans with JavaBeans Swing UI or Struts, and I never felt it was connected with the concept of Components used in Spring, Guice, Seam or JSR-299. By the way, in "Web Beans" there is no @Bean but only @Component.
Third, I found the term API (Application Programming Interface) does not match today's specification code and technique. EJB3, JAXWS and so on don't export a DLL API. They help you code. For example, In JPA (Java Persistence API) more than 90% of the code are Annotations not Interfaces. It should be Java Persistence Annotations, no? You can argue that Annotations are indeed interfaces in Java, and that it will not change the acronym ;-)

Anyway here are 2 possible names:
- Dependency Injection API (or Annotations)
- Components Injection API (or Java Components Injection Annotations ;-)

Finally, JSR-299 DIA also generalizes the concept of Injector injected by injection from the Dependency Injection framework, and I'm really happy about it ;-)

JPA NamedQueries and JDBC 4.0

2007-08-01T00:26:00.001+03:00

In one project doing a migration from EJB 2.0 to EJB 3, I found this:

@Entity(name = "Action")
@NamedQueries({
@NamedQuery(name = "Action.findAll", query = "SELECT o FROM Action o"),
@NamedQuery(name = "Action.findByExtCode", query = "SELECT o FROM Action o WHERE o.externalCode = ?1"),
@NamedQuery(name = "Action.findByDescription", query = "SELECT o FROM Action o WHERE o.description = ?1"),
@NamedQuery(name = "Action.findManualActions", query = "SELECT o FROM Action o WHERE o.manual=?1"),
@NamedQuery(name = "Action.findSelectedActions", query = "SELECT o FROM Action o WHERE o.actionType.id <> 3"),
@NamedQuery(name = "Action.findFlowActions", query = "SELECT o FROM Action o WHERE o.actionType.id=3"),
@NamedQuery(name = "Action.findByActionFlowId", query = "SELECT o FROM Action o JOIN o.actionFlows af WHERE af.id = ?1")
})

The code looks like this, because when doing named queries in JPA the name need to be unique for the WHOLE persistence unit. So, we agreed about the naming convention "[entity name].[finder name]" for the name of the query.
It is actually quite nicer an more manageable than EJBQL in xml files, but still there is quite a bunch of copy/paste, String that are not constants, and the usage of named queries is here more problematic than EJB 2.0 home interfaces.
The usage looks like:

Query namedQuery = em.createNamedQuery("Action.findByExtCode");
namedQuery.setParameter(1, "001");
ActionBean actionBean = (ActionBean) namedQuery.getSingleResult();

And this is for only one parameter...

The possible code errors (due to lack of static typing) we get here are:

Errors on the string name for the namedQuery
Errors on the parameter position (the named queries annotation is in the model not close to the business logic executing queries)
Errors in Casting

So, when looking at this, I thought about JDBC 4.0 (jsr 221 chapter 20 of the spec) and finally managed to create a nice dynamic proxy doing the work for JPA.
It is quite clear looking at the code above, a JPA named query can be defined as an interface method. It has:

a name (entityName + methodName),
a list of parameters (ordered or named),
and a result (list or single).

So, with the dynamic proxy the usage code looks like:

ActionQuery actionQuery = NamedQueriesFactory.getQueryProxy(ActionQuery.class, em);
ActionBean action = actionQuery.findByExtCode("001");

And the Queries interface:

@JpaQueriesInterface(prefix = "Action")
public interface ActionQuery {
public Collection<ActionBean> findAll();
public ActionBean findByExtCode(String extCode);
@JpaQueryUseParamNames
public ActionBean findByDescription(@JpaParamName("description")String description);
public Collection<ActionBean> findManualActions(boolean manual);
public Collection<ActionBean> findSelectedActions();
public Collection<ActionBean> findFlowActions();
public Collection<ActionBean> findByFlowActionId(long flowActionId);
}

Which gets all the advantage of strong Java typing.
So, the code of my small running example is here:
http://subversion.jfrog.org/jfrog/greenhouse/jpa/trunk/ and it's using maven of course...
Now, the next step is to use the Annotated Query Interface has NamedQuery provider so it will really look like JDBC 4.0.

The need for RAE

2007-07-14T09:56:00.000+03:00

With all the discussions around language changes in Java7, there is a need for democratic vote on what should be included or not.
But in today's Bug Database of Sun you can only vote for a RFE (Request For Enhancements), you cannot vote against. And when you look inside the Top 25 RFEs you can see that there is big controversy on most of them, and that Sun act as a final "benevolent dictator".
For example here is an extract of the top 25 RFEs that may have an impact on Java7/OpenJDK and the language:

Votes	Bug ID	Synopsis
580	4449383	Support For 'Design by Contract', beyond "a simple assertion facility"
341	4820062	Provide "struct" syntax in the Java language
303	4267080	break up rt.jar into downloadable-on-demand components to reduce jre size
197	4093687	Extension of 'Interface' definition to include class (static) methods.
172	4905919	RFE: Operator overloading
171	4801527	Support Repository in Java Web Start
152	4727550	Advanced & Raw Socket Support (ICMP, ICMPv6, ping, traceroute, ...)
125	4313887	New I/O: Improved filesystem interface
122	4129445	An API to incrementally update ZIP files
122	4650689	RFE: Java needs public API for FTP
113	4648386	Simplify deployment and versioning by embedding JAR files within each other

From this list, I'm personally for "java kernel: 4267080", "New IO: 4313887", against "Operator overloading: 4905919", "Design By Contract: 4449383", and still undecided on "struct: 4820062".
So, how can we compile all the votes?
Sun needs to create RAE (Request Against Enhancements) in parallel of each controversial RFE.
To compile the votes, we will need better access to the Bug Database, since listing all RFEs and RAEs by importance is impossible from the current Web Interface.
The need for RAE came from the big controversy around checked exceptions and I was really missing a nice compilation result of for/against.

Today, Java is Open Source and the full activation of the OpenJDK Governance Board is in progress. I will really like to know what to expect in the language. Having a compilation of popular RFE/RAE will help.
But until the process of the Governance Board is not clarified, Sun position will be the decisive one. And here the current position of Danny Coward, JavaSE Platform lead, is very confusing: "Seeking a small number of changes for Java SE 7 platform" (from Java One presentation).

Voting for Good Exception Handling

2007-07-10T21:05:00.000+03:00

When getting ready for a conference I gave for Sun (Java 7 - A lot to be waiting for !), I came across this blog: Voting for Checked Exceptions. It was in response of Neal Gafter's blog: Removing Language Features?.
The list of comments is very long, and I never found the time to read them, until now. I really liked what went on there (except the personal attacks), and I want to try to summarize the arguments, as I view them. The arguments are also exposed in Neal's blog comments but there was a lot less arguments...
I'm not trying to be impartial, since for me it's clear: Checked Exceptions should go.
Page 49 of the presentation has the bullets that summarize my view on Checked Exceptions.

So here are the valid arguments I saw in the blog comments:

Checked Exceptions avoid the digging of what can go wrong

Description:

In other languages that does not have checked exceptions, it takes a good amount of time, thinking, QA cycles, and production crashes before you know which exception types can be thrown by a specific method.
Basically, since the API does not declare what it can throws, as a caller you need to "guess" what can happen or catch everything and try to re-throw what should not have been catch.

Validity:

The point is totally valid, but for me it does not make the balance tip on either side of the checked/unchecked issue.
Good API should declare a good throws clause list of what can happen. This is good design and OO practice. And a caller that knows what to do in case of an exception should catch them and handle them correctly. This is valid for Exceptions in general, checked or unchecked. The issue is that in Java nobody declares unchecked exceptions in the throws clause, it looks stupid. I don't know why, I think it's just a stupid habit.

Still there is a point against checked exceptions here. As an API writer, you are "forcing" the caller to catch ALL of the "checked" exceptions declared in your throws clause. This simple fact, breaks OO, forces some design concept on the caller (where to put the exception handler and method throws clauses), and generate all the "bloat".

Checked Exceptions helps you remember that you need to handle them

Description:

During coding you encounter methods throwing exceptions and so you need to handle them at some point. So, with checked exceptions, for a certain class or module, the list of exceptions to handle is well define.
This point was made especially when some lazy developers will ignore unchecked exceptions all together. If the compiler will not bother, exceptions are ignore.

Validity:
Here the point fails on multiple accounts:

1) Forcing the catching of an exception on a lazy developer is worse than let him go along. You end up with things like:

try {
o = getObject(id);
} catch (PersistenceException e) {
// Should not happen I just saved it before
}

Which is my personal nightmare on many projects. When the code is full of these it's totally impossible to debug, understand the behavior, or move forward. It's desperate. Simply put:

"Empty catch block are worse than no catch at all"

2) Listing and catching all checked exceptions does not cover your needs in exception handling. Even in Java there are unchecked exceptions, and in today's framework you have more and more of them. So exceptions will slip through anyway.

3) Putting the error handling in the middle of the logical code is a very bad practice. You end up copy/pasting catch block all over, and if you need a small change in error handling, well... forget it.
The error handling is a layer of your module/component/architecture, that should be transparent and decoupled from your code.
This is the only way to make sure you are handling correctly ALL exceptions. This is the power and design in modern framework using AOP Interceptors. So, like in Spring, JBossMC, EJB3, Hibernate, you need a framework layer to catch Throwable and find out which exception handler should take care of what at which layer. Perfect, unbeatable, robust, user friendly, HA, and more.

You don't have to handle checked exception just pass them on

Description:

If inside a method you are calling a method with checked exceptions and you don't know how to handle it, just add it to your (big) list of throws clause, someone up the call stack will take care of it.

Validity:

This is the most non valid argument for checked exceptions, and the main reason why Java should have only unchecked exceptions.
I don't know many projects where any developer can just add a checked exception to the signature without blinking (the same for removing one). Checked Exceptions makes API throws clause fixed for eternity. If you add, you suffer, if you remove, you're lynched...

So, the only way is to create non meaningful generic Super Exception class (like IOException) that every methods throws.
Basically, this argument contradict the 2 previous ones which are a lot more valid.
On the other hand this feature is mandatory for normal coding. Everybody agree:

"If you don't know what to do with an exception, don't handle it"

This is critical, for "robust" application, so you need to find a way to answer this argument. Here is the proof that checked exceptions are contradicting their own benefits.

Checked Exceptions are recoverable, Unchecked are bugs

Description:

The principle of separation between checked/unchecked is well defined by ELH:
"as in section 8 of Effective Java. [...] checked exceptions are for unpredictable environmental conditions such as I/O errors and and XML well-formedness violations while unchecked exceptions are for program failures that should be caught during testing, such as array index out of bounds or null pointers."

Validity:

Classifying, and understanding what the error IS, is a critical step in good error handling. You need to send a good type of exception, for the good type of error, with the maximum amount of information (which file, to read, to write, which DB, which XML tag, ...).
Forcing yourself to create meaningful Exception is a difficult step, but one that always pays off. Add all the parameters you can, create meaningful messages, and use the good exception class.
But, the separation "unpredictable environmental conditions" vs. "program failures" is highly subjective, and always false once you climb one layer in your architecture. The kind of comment "Should not happen I just saved it before" proves my point.
Typing is good (IOException, NPE), but to enforce the global decision for all Java software ever written that IOException is an "unpredictable environmental conditions" does not make any sense.
Furthermore, the "forcing" of handling of "unpredictable environmental conditions" generates a lot of "development by exceptions". Basically, if you know that the file may not be there, I really prefer if the developer just create a File() object and test file.exists() instead of waiting for IOException.

Experiences with Checked Exceptions

1) In my experience to handle correctly an exception you need a lot of infrastructure information: How to display errors to the user (Web or Fat client), How to log, How to translate (code, language), How to trap, Severity detector, transaction access, ...
And to provide all this information to the inner logical code that need to wrap checked exceptions is a big burden for the application. Just pass the exception, my exception handler will handle it correctly.
Since, creating an exception handler with IOC and/or AOP that has access to all the above managers, is quite easy and clean.

2) We are doing lately a lot of migration to JPA, and more than 50% of our headaches are on checked exceptions. We found out that checked exceptions promotes indirectly the bad habit of development by exceptions:

try {
o = getObject(id);
} catch (PersistenceException e) {
// Object not found create it
    o = create();
}

And changing the API signatures, removing FinderException from EJB 2.0, or the annoying CloneableException is a true nightmare.

3) Good coding with checked exceptions is sometimes very very tedious. For example the correct management of FileInputStream.close() and it's IOException is getting out of hand:

FileInputStream is = null;
try {
is = new FileInputStream(fileName);

// Some work...
    int n = is.read();

// Need to close here so caller will know file in unstable state
    is.close();
// Need to set null to avoid double close
    is = null;
} catch (IOException e) {
throw new PersistenceException("Error reading file "+fileName, e);
} finally {
if (is != null) {
  try {
      is.close();
  } catch (IOException ignore) {
      // Well I try to close, but it does not close
            // SO may be I should close ;-)
            log.debug("Ignoring on close of ", ignore);
  }
}
}

Conclusion

Independently, of the discussion on closures, I really hope that the compiler enforcement of catching checked exceptions will be removed in the openJDK very soon...

PATCH Abstract Enum with OpenJDK

2007-06-23T21:18:00.000+03:00

The full solution in OpenJDK

Applying from KSL to OpenJDK

First, there are no issues (except a diff of 2 lines in the GPL license block ;-) to apply a patch from KSL to the OpenJDK project trunk checkout.

So I applied my KSL patch and I started modifying "sun/reflect/annotation/AnnotationParser.java" to retrieve the Enum.valueOf() from the parameter class type and not from the type definition. It means that in:

@AnnoAETest(ae2 = E21.one)
private String first;

where:

public @interface AnnoAETest {
  AbstractE2 ae2();
}

the AnnotationParser was doing Enum.valueOf(AbstractE2.class,"one"), but it had actually the class E21 defined, so I changed it to the good Enum.valueOf(E21.class,"one").
So the patch is:

 Index: j2se/src/share/classes/sun/reflect/annotation/AnnotationParser.java
===================================================================
--- j2se/src/share/classes/sun/reflect/annotation/AnnotationParser.java (revision 237)
+++ j2se/src/share/classes/sun/reflect/annotation/AnnotationParser.java (working copy)
@@ -422,9 +422,12 @@
             if (!enumType.getName().equals(typeName))
             return new AnnotationTypeMismatchExceptionProxy(
                 typeName + "." + constName);
-        } else if (enumType != parseSig(typeName, container)) {
-            return new AnnotationTypeMismatchExceptionProxy(
-                typeName + "." + constName);
+        } else {
+            Class paramEnumType = parseSig(typeName, container);
+            if (!enumType.isAssignableFrom(paramEnumType))
+                return new AnnotationTypeMismatchExceptionProxy(
+                    typeName + "." + constName);
+            enumType = paramEnumType;
         }

         try {

Now, another issue appears, is that the complicated test to know if a class is an enum with member or an abstract enum or anonymous class is complicated and the Class.isEnum() implementation was wrong.
After changing to the following implementation to remove specialized enum (anonymous):

 Index: j2se/src/share/classes/java/lang/Class.java
===================================================================
--- j2se/src/share/classes/java/lang/Class.java (revision 237)
+++ j2se/src/share/classes/java/lang/Class.java (working copy)
@@ -2877,8 +2877,7 @@
        // An enum must both directly extend java.lang.Enum and have
        // the ENUM bit set; classes for specialized enum constants
        // don't do the former.
-       return (this.getModifiers() & ENUM) != 0 &&
-       this.getSuperclass() == java.lang.Enum.class;
+       return ((this.getModifiers() & ENUM) != 0 && !isAnonymousClass());
     }

     // Fetches the factory for reflective objects

I'm getting for my following last failed test:

public class AnnoAEUsage {
  @AnnoAETest(ae2 = E21.one)
   private String first;

  public static void main(String[] args) throws Exception {
      System.out.println("Is enum "+E21.class.isEnum());
      E21 e21 = Enum.valueOf(E21.class, "one");
      switch (e21) {
          case one:
               System.out.println("Got 1");
              break;
          default:
              System.err.println("No got 1");
      }
      Field field = AnnoAEUsage.class.getDeclaredField("first");
      AnnoAETest anno = field.getAnnotation(AnnoAETest.class);
      AbstractE2 ae2 = anno.ae2();
      System.out.println("Youpi again "+ae2.full());
  }
}

enum E21 extends AbstractE2 {
  one, two;
}

The following output:


JDK Build:/work/java.net/ksl.trunk$/work/java.net/openjdk.trunk/control/build/linux-amd64/j2sdk-image/bin/java -cp build/test-classes abstractEnum.annotation.AnnoAEUsage
Is enum true
Got 1
Exception in thread "main" java.lang.IllegalAccessError: tried to access class abstractEnum.annotation.AbstractE2 from class $Proxy3
       at $Proxy3.ae2(Unknown Source)
       at abstractEnum.annotation.AnnoAEUsage.main(AnnoAEUsage.java:32)

Some more work...

Stupid isn't it
Well it turn out this one is logical...
It's related to an open bug: 6256803 which is not really a bug in my view. You just need to expose public your interfaces, since the dynamic proxy implementing annotation interface is not part of the package. So my AbstractE2 abstract enum, and the E22, E21 real enums were package protected, so: IllegalAccessError.
After making all the test classes public, it works...

The final OpenJDK Patch
For the b14 of openJDK I needed to apply for my platform: 6567018
The above patch file is for "hotspot/src/share/vm/gc_implementation/"

The root project for my patches (KSL and OpenJDK) and all tests files is here.

For the OpenJDK all patches were executed under:
URL: https://openjdk.dev.java.net/svn/openjdk/jdk/trunk
Repository Root: https://openjdk.dev.java.net/svn/openjdk
Revision: 239
And they can be downloaded here.

What's next

So, now what's left to do is to remove the "extends Enum" and make the generics declarations ">" generated by synthetic sugar.

I think that during the work on generics I will try to see the difficulty of having generics for Enum also?

But before all that I think I will start to apply this internal JDK to the fields-enum and other projects, to really judge the improvements...

The "reopened" RFE was accepted

Thank you for taking the time to suggest this enhancement to the Java Standard Edition.

We have determined that this report is an RFE and has been entered into our internal RFE tracking system under Bug Id: 6570766

1. Voting for the RFE
Click http://bugs.sun.com/bugdatabase/addVote.do?bug_id=6570766

2. Adding the report to your Bug Watch list.
You will receive an email notification when this RFE is updated. Click http://bugs.sun.com/bugdatabase/addBugWatch.do?bug_id=6570766

Abstract Enum on KSL

2007-06-18T21:10:00.000+03:00

The reasons in few lines

Give the ability to create abstract classes between the final enum declaration containing the static enumerated values, and the abstract superclass for all enum java.lang.Enum.

So an AbstractColumn.java file can contain:


public abstract enum AbstractColumn {
  String columnName;
  int precision;
   AbstractColumn() {
      columnName = name();
      precision = 0;
  }
 AbstractColumn(String c, int p) {
  ....
  }
  public String getColumnName() {return columnName();}
}

And inside an O/R Mapping framework an annotation can be:
public interface @Column {AbstractColumn definition();}

And then the application users have the level of indirection they need to provide logic to the framework using the static annotations. For example:


public enum CustomerColumn extends AbstractColumn {
  firstName, lastName, age;
   public String getColumnName() {
      return StringUtils.capitalizeWithUnderscore(name());
   }
}

@Entity
public class Customer {
  @Column(definition = CustomerColumn.firstName)
  private String firstName;
}

Then all the problems of hardcoded schema names in JPA entities (quite annoying), copy/paste, string based errors (no type safety), and so on disappear.
From my experience, the limitations of Annotations are really pushing developers away, and this feature can unlock the issue.

The KSL or OpenJDK patch
Please check A dive into the KSL A big dive (more like drowning) into the Kitchen Sink Language!, for how this patch was made and the references.

So, I finally manage to write a patch for abstract enum with the following limitations:

Abstract enum cannot extends other abstract enums (the extends close needs to be empty)
You need to declare the constructors you are using in the final enum extending the abstract enum and use super() calls if needed
You can declare the generics signature > in the abstract Enum, and use enum MyEnum for the final one. It does not mean generics are allowed for enum,
but for the moment I did not find synthetic sugar for generating generics that I could based my work on?
I had the following problem: '''The enum containing anonymous classes does not work anymore with this patch'''. The main problem is that after Check an implicit abstract flag is set on the enum and don't find a way to distinguish between the implicit and explicit abstract flag :-( I solved it using tree.mods and check for protected constructors in the second version of the patch.
So the only problem left is the usage of Abstract Enum in Annotations. It works at compile time but failed at runtime. So I need to work on the OpenJDK now. I'm getting:

java.lang.annotation.AnnotationTypeMismatchException: Incorrectly typed data found for annotation element public abstract abstractEnum.annotation.AbstractE2 abstractEnum.annotation.AnnoAETest.ae2() (Found data of type LabstractEnum/annotation/E21;.one)
       at sun.reflect.annotation.AnnotationTypeMismatchExceptionProxy.generateException(AnnotationTypeMismatchExceptionProxy.java:56)
       at sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:74)
       at $Proxy3.ae2(Unknown Source)
       at abstractEnum.annotation.AnnoAEUsage.main(AnnoAEUsage.java:21)

The patch is here Abstract_Enum_in_KSL_second_version.patch which is based on "compiler-1.7.0-ea-b05". I applied the patch to "openjdk/jdk7/b13" in the folder "j2se" and it matches. I did not test the rebuild, yet.

The test code is based on a closed bug number about abstract enum (Bug ID: 6507006) is here here JtregTests.jar, and only the test of abstract enum in annotations fails.

The draft for JSL modifications
8.1.1.1 abstract Classes
Enum types (§8.9) can be declared abstract.

8.1.4 Superclasses and Subclasses
The optional extends clause in a normal class declaration specifies the direct
superclass of the current class.


   Super:
       extends ClassType

The following is repeated from §4.3 to make the presentation here clearer:


   ClassType:
       TypeDeclSpecifier TypeArgumentsopt

A class is said to be a direct subclass of its direct superclass. The direct super-class is the class from whose implementation the implementation of the current class is derived. The direct superclass of an enum type E is Enum, unless a SuperEnum is declared.

8.9 Enums
An enum declaration has the form:
EnumDeclaration:
ClassModifiers ''opt'' enum Identifier SuperEnum''opt'' Interfaces''opt'' EnumBody
SuperEnum:
extends EnumType
EnumType:
TypeDeclSpecifier
EnumBody:
{ EnumConstants''opt'' ,''opt'' EnumBodyDeclarations''opt'' }

The body of an enum type may contain enum constants, if the enum is not declared abstract. An enum constant defines an instance of the enum type. A non abstract enum type has no instances other than those defined by its enum constants.
The superclass of an enum can only be another enum declared abstract.
Generics declaration enum are not allowed, and will result in a compile-time error.

14.11 The switch Statement

The type of the Expression must be char, byte, short, int, Character,
Byte, Short, Integer, or a non abstract enum type (§8.9), or a compile-time error occurs.

A Dive in KSL

2007-06-17T01:48:00.000+03:00

WOW, what an experience

The Dive

I just finally emerged from the deep ocean of the KSL (Kitchen Sink Language). That was one of my most challenging coding experience, ever.

The code is very complex (A compiler after all), very clean, using OO completely to the 3rd level, and having this strange results:

"100% code coverage, gives you 10% usage coverage"

My dive was guided by the Compiler group:

Joseph D. Darcy's Sun Weblog So You Want To Change,
Alexander Hristov Hacking the OpenJDK compiler
and Matthias Ernst's Weblog Cascading First Patch which gave me the energy to try.

First, I wanted to use the OpenJDK project but the I did not manage to execute the Ant atsk for building and testing just the javac compiler. Furthermore, I'm an IntelliJ user (hard to change my habits) and reconfiguring the source paths to exclude all except the classes needed by javac was not on my agenda ;-)

Building the KSL javac
So I went for the Kitchen Sink Language project.
The README.html page after subversion checkout is quite helpful, and the build/test environment is good. You need to configure the "build.properties" like:


build.jdk.version = 1.7.0
build.release = ${build.jdk.version}-opensource
build.number = b00
build.user.release.suffix = ${user.name}_${build.fullversion.time}
build.full.version = ${build.release}-${build.user.release.suffix}-${build.number}

# Set jtreg.home to jtreg installation directory
jtreg.home=/work/java.net/jtreg

# Set test.jdk.home to baseline JDK used to run the tests
#test.jdk.home=jdk
test.jdk.home=/opt/java/1.7.0

compiler.source.level = 1.5

The /opt/java/1.7.0 is pointing to a previously build OpenJDK trunk (rev 237).

I did not manage to execute the jtreg test from ant. It seems that the jtreg Ant task lost the basedir?

So I modified it to run jtreg directly (for linux), with my personal filter for abstractEnum:

 <fail unless="jtreg.home" message="Property 'jtreg.home' needs to be set to the jtreg installation directory."/>
 <fail unless="test.jdk.home" message="Property 'test.jdk.home' needs to be set to the baseline JDK to be used to run the tests"/>
 <exec command="${jtreg.home}/linux/bin/jtreg">
    <arg value="-jdk:${test.jdk.home}"/>
    <arg value="-Xbootclasspath/p:${dist.javac}/lib/javac.jar"/>
    <arg value="-verbose"/>
    <arg value="-dir:test"/>
    <arg value="-r:${build.jtreg}/work"/>
    <arg value="-w:${build.jtreg}/report"/>
    <arg value="tools/javac/abstractEnum"/>
  </exec>

I also configured an IntelliJ project, containing the sources, the test sources and the Ant build.xml file.

Then I found out that I could not debug the compiler because it uses debuglevel="source,lines" when IntelliJ needs debuglevel="source,lines,vars", so I changed the build.xml.

Creating test cases

So, like every good Test Driven developer I started the work by writting the java code I wanted the compiler to accept. To integrate into the test suite you need jtreg. It is very easy to understand and use, and I really like the simple tags. I mainly developed by example looking at other tests definitions.

So my first test was:

public abstract enum AE1 {
    int i;
    AE1() {i=2;}
   AE1(int pi) {i=pi;}
    public int getI() {return i;}
}

To compile it, the parser needed to be changed and the clean code of the Parser class makes it easy. I used to work with javacc, and I really think direct java coding of a grammar is a lot more readable, "easier" to debug and to extend.

So, after the parser, I created another test:

public enum E1 extends AE1 {
    one(1),two;
    E1() {
   }
   E1(int pi) {
        super(pi);
   }
}

Here I got bad class file all the time when the resolving of AE1 took place. Wanting to move forward I created one java file with all the classes inside, to ease the loadClass():

public class AE2 {
    AbstractE2 ae2;

    public static void main(String[] args) {
        System.out.println("Before");
        AE2 t = new AE2();
        t.ae2 = E21.one;
        System.out.println("Youpi "+t.ae2.f()+"  "+t.ae2.full());
        t.ae2 = E22.twenty2;
        System.out.println("Youpi "+t.ae2.full());
        System.out.println("After");
        E21 e21 = E21.one;
        switch (e21) {
           case one:
               System.out.println("Got 1");
           break;
           case two:
               System.out.println("Got 2");
           break;
       }
   }
}

abstract enum AbstractE2<E> {
    public int f() {
        return ordinal();
   }
    public String full() {
        return name() + ":" + ordinal();
   }
}

enum E21 extends AbstractE2 {
   one, two;
}

enum E22 extends AbstractE2 {
   twenty2, twenty3;
}

This removed the loadClass issue and gave me all the errors related to actual compiler work. Here it took me some time to understand who is really doing what, and to control a step by step approach.

Customizing the environment

First, the compiler needs to be compiled with himself. So, the Ant does it in 2 steps, compile the bootstrap compiler then the javac compiler with the bootstrap. The problem is that if you destroyed the code, there is no way to move. To protect against this problem, you need to make sure you have a good set of if (...) that identify the special case you are working on and not anything else. For the "abstract enum" it took me too much time to identify this good tests (enum like before, enum with abstract declaration).

Second, There are a lot of steps in the compilation, and to control it found this in RecognizedOptions :

/* This is a back door to the compiler's option table.
* -XDx=y sets the option x to the value y.
* -XDx sets the option x to the value x.
*/
 new HiddenOption(XD) {
     String s;
     public boolean matches(String s) {
         this.s = s;
         return s.startsWith(name.optionName);
    }
     public boolean process(Options options, String option) {
         s = s.substring(name.optionName.length());
         int eq = s.indexOf('=');
         String key = (eq < 0) ? s : s.substring(0, eq);
         String value = (eq < 0) ? s : s.substring(eq+1);
         options.put(key, value);
         return false;
    }
},

And this in the JavaCompiler :

compilePolicy = CompilePolicy.decode(options.get("compilePolicy"));

static CompilePolicy decode(String option) {
if (option == null)
    return DEFAULT_COMPILE_POLICY;
else if (option.equals("attr"))
    return ATTR_ONLY;
else if (option.equals("check"))
    return CHECK_ONLY;
else if (option.equals("simple"))
    return SIMPLE;
else if (option.equals("byfile"))
    return BY_FILE;
else if (option.equals("bytodo"))
    return BY_TODO;
else
     return DEFAULT_COMPILE_POLICY;
}

There is also a lot of good assertions inside the compiler code that better be activated. So, I create a small java class playing with the options and activating Javac main directly.

And here is list of options I used:
For the JVM level options:

-ea -esa This one is at the JVM level of the activation of the test code.
-Xbootclasspath/p:dist/lib/javac.jar becareful you need jdk 1.7.0 to run it

For the javac options:

-XDcompilePolicy=attr for attribute only pass
-XDcompilePolicy=simple do the job in a very linear way, which makes the visitor on the code happens in a very different order than normal compile. I found it a very important check to verify that the code respect the visitor pattern and code of the compiler.
-printsource is generating XXX.java files instead of XXX.class and do also a different visitor activation. Very important step to check the Parser/MemberEnter steps.
-XDverboseCompilePolicy for showing what the compiler is doing. Very important.
-verbose standard and sometimes annoying (I removed it after a while)
-XDdev activate dev verbose (Don't know exactly what it means)
-Xlint:unchecked verify when you messed up with generics ;-)
-XDstdout very helpful to have compile error in standard out and compiler crashes and exception in error.

So here is my small test class that helped me a lot (Short cycle compile/test/debug).

The going down

This was really, really tough times for me. The issue is that java.lang.Enum does not have a default constructor but harcoded (String name, int ordinal) params. So Attr, TransTypes and even Lower, keep adding/removing this arguments types from the list of type parameters. The ''enum XXX'' and ''abstract enum YYY'' have the name and ordinal parameter added during the "synthetic sugar" phase of the Lower visitor. So, it does not match. I finally solved the issues the following ways:

Make some nice good test isDeclaredEnum() and isAbstractEnum() on the Symbol class
Allow enum to call super of an abstract enum
Found out that only the erasure_field method type has the 2 extra parameters, allowing a nice test (sugar already done or not)

When I finally manage to compile all the classes in one file "AE2.java", I went on the bad class file issue.

The final
I found out that a bad compiled class is a bad class. Logical no!

So, after solving all the issues above, my class was good. The last problem was the signature of abstract enum classes loaded from a XXX.class file. Here again the issue was with the erasure_field is null by default on class load, and in enum he is the only one to contain name and ordinal...

So, I just initialized it on ClassReader with the first well defined type.
Perfect, ''abstract enum'' at last...

Links
The patch and the tests are available here AbstractEnumOnKSL.tgz
Starting to work on the annotations now...

State Machine with abstract enum

2007-06-01T01:34:00.000+03:00

Previous blogs

Writing this blog I found out that the subject of state machine with annotations was already covered in:

I will talk about my experience and personal design, but mainly add the point on why "abstract enum" will help a lot.

state machine and code

First of all, since I wrote AADA I'm convince that UML helps you visualize and conceptualize your code and that's were it should stop. Trying to extract to annotate the UML meta-model so that some nice Java code will be generated, is a proof that the target language and framework are missing features.

For all static UML diagrams, it takes less energy to write a Java class in modern IDE than using any UML tool. But for dynamic diagram and especially '''State Diagrams''', UML beats Java (and big time if you use the good GOF pattern).

Most modern Java framework are solving this issue with XML files:

In Spring Web Flow the flow definition file is an XML that points to fields and methods of your java code (like everything in Spring)
All vendor workflow
JBoss JBPM
Struts, JSF, ...

So with JDK 5, I tried in 2005 to write an event driven state machine with annotations. In general I really prefer to design by events are they are a lot easier to grasp for everyone (business analysist, designers and developers).

So my design is basically based on the fact that each event is typed, and activate a specific object in the model. The '''state machine''' design question was: ''Which method should be activated?''

It is very similar to the previous blogs on the subject.

abstract enum will save all

One of the comment on Gabriele Carcassi blog was: "Actually, BeanFlow uses strings (due to depending on enum fields rather than interfaces) to declare transitions. That's not refactorable. I like this design better." So, the conflict between generic framework (using string) and clean design (using annotations and enum), appeared immediatly.

So, I tried to write with my design the Seminar State Diagram from Agile Modeling, and it looks really good:

public class Seminar {
private SeminarState state;

    private int maxStudents = 10;
private int nbStudents = 0;
private int nbWaitingStudents = 0;

@ActifFromState({null})
public void create() {
    state = SeminarState.proposed;
    }

@ActifFromState({/*all states*/})
public void cancel(CancelEvent e) {
    maxStudents = 10;
    nbStudents = 0;
    nbWaitingStudents = 0;
    state = null;
}

@ActifFromState({SeminarState.proposed})
public void schedule() {
    state = SeminarState.scheduled;
    }

@ActifFromState({SeminarState.scheduled})
public void open() {
    state = SeminarState.openForEnrollement;
    }

@ActifFromState({SeminarState.openForEnrollement})
public void add(NewStudentEvent e) {
    nbStudents++;
    if (nbStudents >= maxStudents) {
        state = SeminarState.full;
        }
}

@ActifFromState({SeminarState.full})
public void addWaiting(NewStudentEvent e) {
    nbWaitingStudents++;
}

@ActifFromState({SeminarState.openForEnrollement})
public void remove(DropStudentEvent e) {
    nbStudents--;
}

@ActifFromState({SeminarState.full})
public void removeWaiting(DropStudentEvent e) {
    nbWaitingStudents--;
    if (nbWaitingStudents == 0) {
        state = SeminarState.openForEnrollement;
        }
}

@ActifFromState({SeminarState.full, SeminarState.openForEnrollement})
public void close() {
    state = SeminarState.closedForEnrolement;
    }

public SeminarState getState() {
    return state;
    }
}

It looks like I can express the state in a more concise way than UML. Of course UML is still graphically more powerful.

The only issue above is that I need the enum SeminarState to extends abstract enum StateDefinition

public abstract enum StateDefinition {
 public Class getModelClass() {...};
 public StateDefinition getSuperState() {...};
 // And many more needed by the framework
}

public enum SeminarState implements StateDefinition {
 proposed, scheduled, openForEnrollement, full, closedForEnrolement;
}

and define in the State manager framework an annotation

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
public @interface ActifFromState {
  StateDefinition[] value();
}

Conclusion
It seems to me like most of the XML coding (writing java code in XML) issues, we are seeing today, can be removed if Annotations can have an abstract enum attribute.
I like it...