Sunday, September 28, 2014

Configuration for the Java Platform

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.


  1. Having more companies support it or (if they are JCP Members) declare themselves willing to join the EG for such JSR seems like a good thing. I am not so convinced it must be only "Software vendors" like Oracle or IBM, at least not vendors of large EE servers. After all they are not always interested to reduce complexity and often weird, cryptic ways to configure their products like "java -Xmx1024k -Xmx512m -Xmx8g -Xprof -Xrs..."
    They or some Outsourcing partner companies live from such complexity, so a configuration for Servlets, a configuration for Cache and yet another for the container itself, all competing and incompatible with each other, that is what makes them happy;-)

    The new scope for such a JSR as opposed to a "Container configuration" one which Oracle seems to favor if willing to standardize this at all, means looking at the likes of Jean-Marie Dautelle or Goldman Sachs who created a "better Java Collections API" than Sun/Oracle, the latter even to be mentioned in this year's JavaOne keynote, are perfect examples for "power users" rather than IT vendors who are willing to change something they feel causes them problems in their everyday development work or to their IT systems. I analyzed the way Swing does its i18n after a similar episode of frustration trying to work around the English dominated mindset and way it was built ~1998. Not before 2000 when I presented it at a booth in Germany Sun must have seen it, because their booth was right next to mine. And even before joining the JCP, efforts like these by users helped a JDK version a few years after that finally get i18n for Swing out of the box;-)

  2. Terribly attention-grabbing, sensible job and thanks for sharing such a decent journal. Your article is thus convincing that I ne'er stop myself to mention one thing regarding it. You’re doing a good job. Keep it up

  3. Top quality blog with unique content and found valuable looking forward for next updated thank you
    Ethical Hacking Course in Bangalore

  4. Zarejestruj się i odbierz swój pierwszy bonus! online ruletka Poland

  5. Really impressed! Information shared was very helpful Your website is very valuable. Thanks for sharing..
    Business Analytics Course in Bangalore