Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Charter Feedback

Josh, Reza,

I think everyone can agree that profiles are a powerful concept, and that not only do we want to continue to use them, we want to make it easier to add more.

That said, I can explain why profiles were omitted from the Eclipse EE4J charter. Profiles are a standardization thought, not an open source project concept. So the thinking is that if some group wants to specify a profile they would do that via the to-be-determined specification process, not via EE4J.

Happy to be told that it is a dumb reason though :)

P.S. A modular platform is a great idea, and I hope that is the direction this goes in. But that would ultimately be a technical decision made by the PMC. I don't think we're in a position to mandate that at this point.

On 2017-10-07 12:29 PM, reza_rahman wrote:
I too agree profiles are a very valuable concept and goes extremely well with the notion of ground-up modularity. Perhaps there is a way to mention both concepts together in the charter?

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Josh Juneau <juneau001@xxxxxxxxx>
Date: 10/7/17 10:25 AM (GMT-05:00)
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Charter Feedback

I agree with all comments made in this discussion...+1.  

I am a little surprised that the project charter does not reference the development and/or support of multiple EE4J profiles, such as Java EE has today.  At this time, one has the opportunity to choose between using the Java EE web profile or the full umbrella for a project.  Vendors and cloud/microservices implementations also can be Java EE compliant with one or both of these profiles.  I hope that EE4J will adopt similar profile model, carrying forward what is available in Java EE and even building upon it.  I had always hoped that Java EE would branch out into even more profiles, specifically having one that was geared towards cloud/microservices, such as MicroProfile.  Maybe the idea of profiles goes away and EE4J just becomes a modular platform, allowing one to utilize any specifications that are required for their application?  

Just thought it may be helpful to have a bullet point around multiple profiles somewhere in the charter.


On Sat, Oct 7, 2017 at 7:14 AM, Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:
Good points, Reza and John.

Most important points I agree with:

 - using application runtimes instead of application servers
                    - it's a more flexible term and many Java EE implementations aren't traditional servers anymore
 - cloud-native or cloud-ready instead of just microservices
                    - at some point we'll need to address serverless and FAAS and I believe Java EE has a potential to be used there too
 - target on both standalone, in-container and later possibly FAAS environments
                    - CDI 2.0 already does that, with a core spec and additions for Java SE and EE and it's brilliant and easy to follow
                    - Java SE version shouldn't, however, contain anything that can be provided by another API from the umbrella, for example, it shouldn't provide its own DI mechanism if it's provided by CDI, or at most a very simplistic one based on Java SE or EE standards


2017-10-07 7:24 GMT+02:00 John Clingan <jclingan@xxxxxxxxxx>:
Reza, good points. Comments below.

On Oct 3, 2017, at 6:19 PM, Martijn Verburg <martijnverburg@xxxxxxxxx> wrote:

Hi Reza,

My 2c on this

On 3 October 2017 at 18:04, <reza_rahman@xxxxxxxxx> wrote:

As promised, I went through the charter in detail and have the feedback below. Items are roughly in priority order. I will try to encourage others to also provide feedback. Please let me know if it is best to split up into separate threads. Please also let me know if anything needs further clarification. I really hope this helps.

* The charter fairly clearly targets application servers. Personally I certainly value the application server model. However, I think at this point it is clear developers also value being able to utilize the Java EE programming model in embeddable, modular, compose-able run-times (aka fat jars). I think it is best to remove references to application servers and simply say something like run-times for server-side Java applications. I think the reality is that most EE4J implementations will support both models. I can even see implementations that provide no support for the application server deployment model.

Completely agree, there are perhaps even APIs / Specs that we develop which would run serverless so to speak. 

Thanks for bringing this up in the “Opening Up Java EE” panel as well. Everyone agreed with this during the session.

* I think it is important to point out that most of the time (of not all of the time) APIs and technologies under the EE4J umbrella are expected to run standalone in Java SE environments. This is one of the continuing source of criticism for the current Java EE model. While most Java EE APIs are essentially standalone, the platform specification text says nothing about this. In the same vein, I think it is wise to make some reference to modularity even in integrated run-times.

 I do like “standalone on Java SE" as a "guiding principle”. It will facilitate broad adoption of EE4J technologies, not to mention other pragmatic reasons (easier testing, etc).

* I see references to micro-services, which is good. I think we should also make a point to reference the cloud. While it is implicitly understood that server-side can mean the cloud, I think specifically mentioning the cloud in the charter has value. I can envision run-times that are completely cloud native (e.g. Functions as a Service) that do not support the on-premises model at all. It may actually be handy to have cloud native in the text somewhere.

I prefer we simply replace “microservices” with “cloud native”, which is a broader, more abstract conceptual description that encompasses both FaaS and microservices. Oddly, “server side” is more broad that “cloud native”, and encompasses both traditional on-premise and cloud native architectures :-) However, I agree that referring to the cloud is a good balance.

Good call - the ecosystem at large needs to know that Java can be a cloud native platform, EE4J could make a strong statement here. 

* I think its smart to say *modern* server-side Java applications instead of just server-side Java applications.


The definition of “Modern" changes on a monthly basis - by definition. Adding this future-proofs EE4J! :-) I actually think that using “cloud native” as discussed above covers this point.


Back to the top