Java EE8 Survey

[Balder VC]

Hi there.

Have you seen the results on the Java EE8 survey ( if not https://twitter.com/Java_EE/status/450726021361188864 )

Java Config JSR came out quite huge. 

Which does make me wonder a bit, why it's very silent here?

Are there other places we should follow if we are interested? Even if it is to be a critical voice.

/me Just saying that, given that I wrote the RebelRant @ http://zeroturnaround.com/rebellabs/rebelrant-dont-create-a-new-jsr-just-because-you-can/ and since I can partially understand the comment of Nicolas De Loof at his own blog http://blog.loof.fr/2013/10/configuration-management-jsr.html

But that aside.

It is my sincere believe that this intent is a good thing. However just as Nicolas states in his blog post and I did in mine somehow, we should be very wary of imposing rules that lay outside of the real application scope. 

We have application servers providing all sorts of configuration to an application, but we have no thing that defines how different environments should provide configurational stuff to an application. Which is in my humble opinion not something we need.

In every place I worked, which have been a couple in the last 10 years as consultant (7 to be exactly, on different projects, all as consultant), they have different means to have different kind of environmental dependent parameters. I found this to be so specific for every project and company that it's hard to find 'one method to rule them all'. That's why also believe that it's a bad idea to put much effort in this. However I'm open to convincing and hope you can let me see the light and purpose of it 

In my humble opinion it would however perhaps be a better idea to invest in something that can reload properties on the fly from a given resource ( property file or .... ) A bit inspired by Springs @Value and JRebel live reloading. If you're JVM would then be smart enough to know where the property came from. Meaning an SPI for this would be available or even an implementation that would be a great addition to Java. 

Auto reloading of configuration values. Anywhere.. now that is a thing that would benefit most of applications I know. And I consider more a config thing then defining when and how a file should be named/reloaded

I know many applications where we have wrapped this kind of things to achieve on the fly reloading for values. As a matter of facts, lately, I tend to do this for any thing that can be configured programmatic, either by property config or JMX. A cumbersome thing, always the same. Would be great to have a standard.

But perhaps the above is not really a config-jsr thing.. 

Kind Regards

Balder

[Arjan Tijms]

Hi,

On Tuesday, April 1, 2014 1:08:53 AM UTC+2, Balder VC wrote:

Have you seen the results on the Java EE8 survey ( if not https://twitter.com/Java_EE/status/450726021361188864 )

Java Config JSR came out quite huge. 

Which does make me wonder a bit, why it's very silent here?

My personal feeling and that of a couple of people I spoke to about this JSR, is that this particular JSR radiates the feeling that it's mainly about Java SE, with Java EE more as an optional part. The survey you mentioned is about Java EE. If others indeed share this feeling then it's maybe no surprise that it's a little silent here even though Java EE config was quite huge in the survey. People are still looking for the "real" Java EE stuff and they don't find it here (this is of course speculation on my side).

Anatole did mention though that this JSR would also focus on Java EE here: https://java.net/jira/browse/JAVAEE_SPEC-19

I created that issue specifically having the configuration of deployment descriptors in mind (it's the title of the issue after all). Until now, unless I missed something, it looks like the discussion is almost exclusively about retrieving "values" (strings, ints, ...) from some source (.property files, xml files, ...) and making those available to the application. While this is absolutely important too, it's not what I specifically had in mind for JAVAEE_SPEC-19, and it's also not what's mostly being talked about in the comments.

Yet, Anatole did eventually say:

"[...] it should define, in collaboration with the other EE specs, how descriptors can be provided/extended/overriden using the new capabilities available(or descriptor parameters, and also other resources). There are different possibilities how to achieve this and I assume we will have some discussions how this should be done best."

So I guess there's still some hope ;)


 

[Anatole Tresch]

Hi all,

I added a blog post on possible integration with Java EE at:

http://javaeeconfig.blogspot.ch/2014/04/integrating-se-configuration-with-java.html

Regards,

Anatole