Skip to main content

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

The clarification that I would like to make is the Top-Level Charter for EE4J is not a replacement for the Java EE "platform specs".  I would expect the Java EE Platform spec (and Web Profile spec) to move over to EE4J as a separate Eclipse project (under the EE4J umbrella).  The evolution of this new "platform spec" could discuss additional profiles and/or modules.  We have to remember that the establishment of EE4J and the associated projects needs to be on par with Java EE 8 initially.  After these projects are established and shown to be consistent with Java EE 8, then updates can be entertained for future revisions.

Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    

ee4j-community-bounces@xxxxxxxxxxx wrote on 10/07/2017 12:56:52 PM:

> From: Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>

> To: ee4j-community@xxxxxxxxxxx
> Date: 10/07/2017 12:57 PM
> Subject: Re: [ee4j-community] Charter Feedback
> Sent by: ee4j-community-bounces@xxxxxxxxxxx
> 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.

> Thanks

> Josh Juneau
> juneau001@xxxxxxxxx

> 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

> --Ondro

> 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.

> +1

> 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.


> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=TJBuJcgXKbxG9xpap7u2fR8zKw7hhL76fqqb5q_xr0k&s=RK-
> RF2PB3TBLzVWrs4CneAH6y2tsOvo4MC0QYTjnuuE&e=

Back to the top