Configuration 1.0 JSR (completing the cycle)

[Kevin Sutter]

As was our goal with the MicroProfile effort since day one, we have went forward and submitted a JSR Proposal for Configuration 1.0!  This is based off of the excellent work that our MicroProfile Config team exhibited.

This JSR was submitted by the Eclipse Foundation (Mike Milinkovich) with Emily Jiang as the spec lead.  (We also wanted to submit Mark Struberg as a co-spec lead, but the input form only allowed a single name.  We will correct this omission as soon as we can.)

We understand that the work we started with Config 1.0 is not complete -- John has already submitted plans for a Config 1.1.  And, there are more parts to Application Configuration in the Java EE world than what we have proposed for MicroProfile.  But, the idea for a Configuration JSR is not new.  Oracle first talked about this as part of Java EE 8, but couldn't contain the work.  Now that we have completed our first iteration of Config 1.0, we thought it would be good timing to bring this idea full circle and formally propose the Configuration JSR in the JCP.

I'm not aware of a URL to document our Proposal until it gets recognized by the JCP.  We're working through that part of the process right now.  We are also working with the JCP to get this onto an upcoming EC agenda.  There is an EC meeting tomorrow.  If the agenda is light, we might be on it.  Otherwise, it would move to next month's agenda.  We have several EC members on the broader MicroProfile team, so hopefully there would be plenty of representation to help explain our efforts.

I have also provided our Config 1.0 Spec to the JCP organizers in prep for the next EC meeting.

This is really great news!  Thank you to everyone involved in the creation of the MicroProfile Config 1.0 release and the creation of the Configuration JSR.

--  Kevin

[Guillermo González de Agüero]

Really great news! Thanks Kevin and everyone involved on this collective effort. And congratulations Emily and Mark for the spec lead nomination.

Regards,

Guillermo González de Agüero

[Werner Keil]

Congratulation, just saw David's presentation in the EC call.

Whether Eclipse Foundation (being incorporated and a Full Member of the JCP it seems possible) would formally be the Spec Lead and Emily, Mark or others simply represent it, or the legal entities they represent (IBM, Individual) have to, that's being discussed and I'm sure a solution can be found. It does not happen a lot, but at least one active JSR (302: https://jcp.org/en/jsr/detail?id=302) is led by The Open Group, also an industry consortium with members not so different from Apache or Eclipse Foundation.

There was no immediate comment by Oracle's EC representatives, but Dmitry who was discussed to propose this a while ago is no stranger to Eclipse and one of his 2 JSRs has the RI under Eclipse, so if he was allowed to get involved and Oracle wanted to participate in the EG, I assume they can and will. Having a large number of JSRs led by Oracle it is a welcome relief and diversity, not to mention, Eclipse is a vendor-neutral organization with a long history of Open Source projects being used both commercially and for other Open source efforts.

Regards,

Werner

[Kevin Sutter]

Thanks for the EC update, Werner!  I've been waiting for some news on how David's presentation went.  Getting Dmitry involved would be a great way to get Oracle's involvement with MicroProfile...

Thanks again,

Kevin

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/rmGrb3kCrJQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b2ffa797-dce5-4622-869b-1e991179002d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Kenji Kazumura]

Congratulation!

But I have a question about the policy how soon we should propose the draft to JCP.

I think MicroServices are evolving and the demands to MP will be likely changed in a near future.

Even if it happens, it is OK. We can update Config API, 1.1, 1.2, and so on.

But once the JSR is finalized, we need to be more careful for the backward compatibility.

Thanks,

-Kenji Kazumura

[Emily Jiang]

Werner, good suggestion! Agreed with Kevin. It will be great to get Dmitry from Oracle involved.

+1 on Kenji's comments. We iterate quickly in MP. Once the spec is made to JCP, we need to ensure the backward compatibility.

Emily

[Werner Keil]

That's a good point. Maybe Kenji or someone else could also represent Fujitsu in an EG for the JSR once it got started.

About other items that were discussed with the EC was OpenJDK by Brian Goetz. And while not every JSR might be small enough to finish as fast as 330 did, Oracle aims for a similar pace and lifecycle of Java SE as e.g. Eclipse does with its annual release train.

A significant reform of the SI system (the biggest such change since 1960!) triggers a plan for upgrades with a new JSR number to Units of Measurement, too: http://unitsofmeasurement.github.io/2017/taste_of_indriya.html

This is driven by the roadmap of the SI between late 2017 and 2018 so that also brings a 1 year goal to finalize a new JSR (with fewer new features)

Should other features like Metrics be mature enough to consider standardizing, they have strong use for UoM. For configuration some formats do, e.g. Typesafe HOCON, but that's more an implementation or extension, nothing related to a JSR or API itself.

Emily is also a welcome addition to fewer Female Spec Leads or Spec Lead reps in the JCP ;-)

Werner

[Emily Jiang]

Thank you Werner for the useful info and encouragement!

Emily

[Ondro Mihályi]

My view is that we don't aim to target a JSR with any MicroProfile feature but want to innovate along with our vision to optimize for modern trends and architectures, including microservices and cloud deployments. Although we still come from a Java EE background, the MicroProfile effort isn't coupled with Java EE and lives on its own, while building on chosen Java EE technologies. Some features devoloped within MicroProfile may be stable and widely accepted enough to justify submitting them as a JSR. But some are clearly more experimental, without any proven wide adoption and real world deployments. Those can mature later, but many of them will never be ready for a JSR. So any submission of a MicroProfile feature as a JSR is not planned in advance. Rather, after a MicroProfile feature is delivered, it will be evaluated whether it's convenient to submit it as a JSR. I believe that most people share this view with me according to previous discussions.

MicroProfile Config feature was designed for both using in plain Java SE and also in a CDI container, with no other dependencies. It's very general and doesn't specifically target MicroServices arcitecture. A config JSR was already considered by Oracle for Java EE 9, following the demand from Java EE users. Moreover, it's a very simple API, leaving a support of Microservices architecture with convenient configuration sources up to implementations. That clearly justifies standardizing the API within the JCP.

One thing to consider though is that the new JSR will use different package names starting with "java." and "javax." and thus a different API than MP Config API. We will need to come up with a strategy to support any future Configuration JSR within MicroProfile, without too many breaking changes and leave space for further enhancements within MP on top of any future JSR. One way to do this is to support both sets of APIs and define a bridge/mapping between them (in a similar way as Hibernate provides additional functionality on top of JPA). A similar strategy should be used with any other JSRs coming from MicroProfile if there are more in the future.

--Ondro

[Emily Jiang]

Ondro,
I agree with you for the first 2 paragraphs. For the 3rd paragraph, about the MP Config and Config JSR bridging, I would rather they are separate. End users are free to choose which one they use. MP Config can keep evolving and the mature bits will go to Config JSR. Thoughts?

Emily

[Werner Keil]

Nothing was done here, that doesn't reflect one or more Microservice Patterns: http://microservices.io/

The Config module/feature tries to help with http://microservices.io/patterns/externalized-configuration.html

The first idea by Mike Keith to standardize that was via some special archive (e.g. "car" for Configuration Archive, similar to e.g. the format for Resource Adapters or other common types of Java and Java EE archives) This did not find enought support inside Oracle. And even the more  recent effort by Dmitry (after Anatole proposing something similar to the EC a few years ago, but the echo then was not as positive, nor was he backed by Oracle, Red Hat or others then) he has not heard anything about being considered for a Spec Lead of this in Java EE 9.

Nor was there any "But Oracle will do this in EE 9" feedback by Don Deutsch or other EC members when David spoke about it this week. 

I feel, Oracle is a bit relieved that others run as Spec Leads. They handed MVC over to Ivar and Christian, so having Eclipse or member companies propose a standard in this area seems welcome. As fewer Spec Leads are fully supported there now. Several even with the EE 8 specs are not able to present their JSRs at JavaOne this year, that alone says quite a bit.

Having 2 or more parallel APIs, we did face a triple challenge with JSR 363 after 275 had been stopped by the EC. Our "MicroProfile equivalent" org.unitsofmeasurement is being used e.g. by Eclipse and other projects. 275 until now has massive demand, because even in its EDR it offered all the necessary features and was used by several projects. Where they don't touch or change existing code, it probably will for quite a while. Others like Parfait or SmartHome use JSR 363 now. At least with one parallel stream Config will have to deal as well.

It will be interesting to find a proper place for the standard because https://github.com/eclipse/microprofile-config side-by-side with a 1.x stream of the existing org.eclipse.microprofile.config might only work if e.g. the dozens of branches were cleaned up into a microprofile_1.x vs. jsr or jcp branch.

Otherwise both may better get separate repositories.

Werner

[Mark Struberg]

+1 Emily

When we started Microprofile we had a lot discussions regarding the direction.

The outcome was that Microprofile doesn't aim to be a standards body.
Means we can play around with features more agressively and are also not bound to remain backward compatible.

Let's see how fast we can move with the config JSR.
Once it is released and if it's fairly easy to migrate over to the JSR impl then I think we might even deprecate mp-config in a n+1 version.

Does that sound ok?

LieGrue,
Strub

[Mark Struberg]

Werner, note that the notion of portable container configuration (Mikes car) and application configuration is different.
Sure there are overlaps, but the Config JSR and mp-config focus on the later. So we are not limited by any container constraints.

LieGrue,
Strub

[Werner Keil]

Yes, it was part of the reason why e.g. Anatole did not get enough support back then either, because those involved or asked were not sure, if they wanted a rather general config solution or one that works only inside particular containers.

Werner

[csaa...@redhat.com]

Wonderful news! Quick question.  What's the official date of our submission of the JSR to the JCP?

The following article says it was August 8, 2017 (although your post is from Aug 14):

https://adtmag.com/articles/2017/08/23/eclipse-microprofile.aspx

And the official JCP site doesn't list our Configuration submission:

https://www.jcp.org/en/jsr/all

Thanks,

Cesar

[Werner Keil]

I guess it'll take some time to sort our, if and how Eclipse Foundation could be a Spec Lead, or if not, which other corporate or Individual JCP members might.

I asked the question when David mentioned it in the JCP EC call (minutes should be out maybe a week from now https://jcp.org/en/resources/EC_summaries) and knowing how long it took between a JSR and Eclipse IP team, this could be a while. 

Hopefully before JavaOne but I would not bet on a creation review much sooner.

Werner

[Kevin Sutter]

The JSR was "introduced" at the August JCP EC meeting.  But, it was not formally proposed.  As you know, David gave a quick introductory presentation just to set the stage for the next JCP EC meeting.  At the Sept meeting, Mike Milinkovich (Eclipse) will be formally proposed the Configuration JSR for discussion and vote.

Thanks,

Kevin

--

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/rmGrb3kCrJQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f7560283-1e9f-44b1-a76a-dd75fcc5a56a%40googlegroups.com.