Configuration for the Java Platform
Outcome from the last EC Meeting
Last week the EC meeting @Twitter HQ discussed a proposal for a new JSR for Configuration targeting application configuration. Since this topic affects not only Java EE, it was proposed as a SE JSR. Discussions were open and constructive. I try to summarize the outcome here:
- One idea was, that we should do an OSS project out of it. I do not think this makes sense, there are already a few of them, all with reasonable maturity. So it should be finally time to standardize how things are configured in the Java eco-system.
- Others said we should have a look at what was already done in the ME area. But also after having a look at JSR 36 (CDC 1.0) noch JSR 218 (CDC 1.1), I don't see anything relevant there. Perhaps someone can give me a hint here ;)
- Others thought we should create an OpenJDK project. I tend also to disagree with that due to several reasons:
- Developing a JSR that is targeting the JDK directly is much more complicated and my experience from JSR 354 shows that without having Oracle heavily pushing things it might be a high risk to go that way.
- I think community involvement is much easier to achieve doing a "normal" JSR. We can setup a GitHub repo and start working on it. The OpenJDK tool chain is not that easy to use and know how about is not as widely available. Most of all it is much more difficult to get OpenJDK commit rights, than join a OSS project.
- With Jigsaw coming hopefully in Java 9, I expect we get a module system. So it would be pretty easy to add configuration as a Java module once Jigsaw is there. This makes it much more easy again, to focus on the configuration usability aspects and realize Java integration as Jogsaw module later.
- As well waiting for Jigsaw means that no SE JSR can be done for several year. IMO this makes no sense. Nevertheless I agree that the configuration mechanisms proposed must be compatible with Jigsaw.
- Finally this JSR tries to focus on application configuration. This also includes relatively early configuration. But we definitively do not want to be part of the Java early loading code. We saw it quite good, how bad design can get and what kind of unwanted side effects can occur, when infrastructure required by low level Java boot processes is messed up with common user functionality. As an example try to load a class using Class.forName(String) during the loading process of the java.util.logging.LogManager (you have to subclass the LogManager and configure it as a system property).
- Also Redhat, SouJava, LJC, iJUG and others were not seen to be sufficient that we should file the JSR already. There is some probability that it could be voted down, especially, when Oracle is not on board. We definitively have to talk with Oracle people here during Java One!
- Finally feedback was that our JSR proposal should be more precise though no exact details were given, what should be fixed. Nevertheless have a look yourself at XXXX and help us to improve the filing.
So summarizing, adding configuration to the Java eco-system is definitively a Hercules task. OK, it was expected that it will not be easy ;) But good news is, we still we have a chance to get it on track, but we definitively need more support and work to be done. So if you are interested in the topic, write about it, tweet it, advertise it and help to improve our proposal. Communicate your interest, especially to EC members, that we have a unique chance here to improve the overall Java platform and we should not miss it. Especially support by more companies, including Oracle itself, in the EC would be important...
As always feedback is welcome and comments will not be restricted, also when you don't agree on my thoughts here.
