Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] ee4j-community Digest, Vol 2, Issue 13
Werner,
You bring up some valid discussion points, but can you please start a new thread or add to an existing thread so that the train of thought can be semi-consistent?  Most people will see the "Digest" subject line and probably discard it.  Thanks.

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:        <werner.keil@xxxxxxxxx>
To:        "ee4j-community@xxxxxxxxxxx" <ee4j-community@xxxxxxxxxxx>
Date:        10/03/2017 10:09 AM
Subject:        Re: [ee4j-community] ee4j-community Digest, Vol 2, Issue 13
Sent by:        ee4j-community-bounces@xxxxxxxxxxx



Well the JDK since Java SE 8 started by introducing a new top Level package „jdk“.
 
I talked to attendees at the JavaOne Eclipse booth yesterday when showing them what MicroProfile was about. And JSR 382 is a good example where the javax prefix should be preserved and actually used by a new JSR that is just due for approval next week.
 
If either the umbrella or individual Features became standardized by the JCP there is no reason against using the javax prefix. Should they use something else like Oasis, W3C, etc. then this would look a bit different.
 
Following the „jdk“ example with something like „eej“ or „ee4j“ (honestly not that much difference to me) it would also be an Option. VertX is among Eclipse Projects that have a package Namespace like „io.vertx“. I personally would prefer something more distinct than „io.something“ at least for the API.
 
Werner
 
From: ee4j-community-request@xxxxxxxxxxx
Sent: Tuesday, October 3, 2017 09:12
To: ee4j-community@xxxxxxxxxxx
Subject: ee4j-community Digest, Vol 2, Issue 13
 
Send ee4j-community mailing list submissions to
        ee4j-community@xxxxxxxxxxx
 
To subscribe or unsubscribe via the World Wide Web, visit
        https://dev.eclipse.org/mailman/listinfo/ee4j-community
or, via email, send a message with subject or body 'help' to
        ee4j-community-request@xxxxxxxxxxx
 
You can reach the person managing the list at
        ee4j-community-owner@xxxxxxxxxxx
 
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."
 
 
Today's Topics:
 
   1. Re: Glassfish 5.0 compatibility (Ondrej Mih?lyi)
   2. Re: Glassfish 5.0 compatibility (reza_rahman)
 
 
----------------------------------------------------------------------
 
Message: 1
Date: Tue, 3 Oct 2017 09:02:25 -0700
From: Ondrej Mih?lyi <ondrej.mihalyi@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Glassfish 5.0 compatibility
Message-ID:
        <CACZTZYVYethuuXRt4vJOywnxHGEdDvREqFQayK3vD0JQagDiqg@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
 
I agree that preserving the javax prefix even for new APIs is the most
preferred option to maintain consistency and secure success of the whole
platform after migration to the Eclipse foundation.
 
If that's not possible due to legal concerns, John's suggestion of using a
new top level prefix sounds well to me. Except I would prefer some other
prefix than ee4j. - maybe something like jx. or eej. To be honest, ee4j
sounds like a joke to developers, more like a business acronym we all look
at with despect. It's perfectly fine to use the name as a top level Eclipse
project, but I would avoid using it in real API.
 
A compromise solution would be to allocate a fixed namespace with the
javax. prefix, for example javax.ee.
 
I would appreciate seeking Oracle's and lawyers' opinion on these package
namespaces for *new* specs:
 
- using javax.
- using javax.<fixednamespace>, e.g. javax.ee.
- using a new top-level prefix, such as eej. or ee.
 
I hope that Eclipse would be OK with such namespaces for API. Of course,
non-API packages are a different thing and I'm perfectly OK to rename
packages like org.glassfish to org.eclipse.glassfish unless it breaks some
contracts.
 
Ondro
 
2017-10-03 8:45 GMT-07:00 reza_rahman <reza_rahman@xxxxxxxxx>:
 
> I would say your assessment is entirely accurate. The concerns really
> speak to the continued strength of the Java and Java EE names. It would be
> very well received by the community if Oracle decided to make some further
> concessions on this subject. In particular I wonder if they can allow
> limited permission to just use the javax.enterprise sub-package for future
> specifications that come out of this effort?
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
> -------- Original message --------
> From: John Clingan <jclingan@xxxxxxxxxx>
> Date: 10/3/17 8:36 AM (GMT-08:00)
> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> Subject: Re: [ee4j-community] Glassfish 5.0 compatibility
>
> It's clear from various chats at JavaOne that package names are an area of
> concern for the Java EE community as it moves into the Eclipse Foundation.
>
> There is a *strong* desire to keep javax even for new specifications, but
> there are challenges with that approach.
>
> The secondary "vote", if you will, is to not use org.eclipse as the
> top-level domain, with it getting lost in the vastness of the namespace.
> The most pragmatic example I heard is that some customer/user organizations
> limit their use of namespaces for enterprise development, and org.eclipse
> is too broad (and org.eclipse .ee4j, for example, isn't a solution). A
> top-level domain of ee4j.* could be a potential compromise.
>
> I am not advocating any position here, just trying to gather data points
> and convey them here.
>
> On Oct 3, 2017 7:52 AM, Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
> wrote:
>
> This isn't something that we normally put in a charter.
>
> Where possible, we expect Eclipse projects to use the org.eclipse.*
> namespace (e.g. org.eclipse.glassfish.*), but there are exceptions (e.g.
> Eclipse Vert.x). We will seek advice from the Top Level Project's Project
> Management Committee (PMC) regarding exceptions.
>
> Breaking an existing community is not a great idea. Assuming that we don't
> run into trademark issues that cannot be resolved, I expect that existing
> package and class names will be preserved, at least in some cases (e.g.
> official and de facto APIs), and at least initially. The project team may,
> for example, chart out a migration path for future versions that includes
> some sort of compatibility layer. Again, we'll expect that the PMC will
> work with the projects to sort out the right solution.
>
> HTH,
>
> Wayne
>
> On Tue, Oct 3, 2017 at 8:35 AM, Mark Little <mlittle@xxxxxxxxxx> wrote:
>
> I'm pretty sure Mike mentioned this in an earlier email to the group
> but package names have not be considered yet for new additions but
> existing code will come across unmodified.
>
> Mark.
>
> On Tue, Oct 3, 2017 at 7:09 AM, Emmanuel Bernard <ebernard@xxxxxxxxxx>
> wrote:
> > Hi everyone,
> >
> > The charter says
> > "The initial Eclipse Enterprise for Java RI is compatible with GlassFish
> 5.0, and passes Java EE 8 compatibility tests transitioned to EE4J."
> >
> > From what I have seen for Eclipse Ceylon, package renaming for
> implementations is part of the on boarding process. This means that people
> using actual Glassfish classes (not the spec classes) would have to convert
> their app and thus might not be qualified as compatible. Do we want to
> adjust the charter or will there be a package renaming exception for
> Eclipse Glassfish?
> > Or maybe I've misunderstood the rules altogether :)
> >
> > Emmanuel
> > _______________________________________________
> > ee4j-community mailing list
> > ee4j-community@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/ee4j-community
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j-community
>
>
>
>
> --
> Wayne Beaton
> Director of Open Source Projects
> The Eclipse Foundation
>
>
>
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j-community
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171003/ead8b3f2/attachment.html>
 
------------------------------
 
Message: 2
Date: Tue, 03 Oct 2017 09:12:00 -0700
From: reza_rahman <reza_rahman@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Glassfish 5.0 compatibility
Message-ID: <mailman.259.1507047126.11765.ee4j-community@xxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
 
For whatever the reasons, the EE4J name really has not been that warmly received by the community. What I suggest here is coming up with a few options (including for packaging if javax is really categorically out of the question) and let the community vote on it. I know it's a lot more effort, but it may be worth it in the long run given how large, vocal and active the Java EE community is.
By the community voting on it, I don't mean just discussions on this list. Although people care a lot about Java EE, the reality is that only the most committed folks would likely directly contribute here.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Ondrej Mih?lyi <ondrej.mihalyi@xxxxxxxxx> Date: 10/3/17  9:02 AM  (GMT-08:00) To: EE4J community discussions <ee4j-community@xxxxxxxxxxx> Subject: Re: [ee4j-community] Glassfish 5.0 compatibility
I agree that preserving the javax prefix even for new APIs is the most preferred option to maintain consistency and secure success of the whole platform after migration to the Eclipse foundation.
If that's not possible due to legal concerns, John's suggestion of using a new top level?prefix sounds well to me. Except I would prefer some other prefix than ee4j. - maybe something like jx. or eej. To be honest, ee4j sounds like a joke to developers, more like a business acronym we all look at with despect. It's perfectly fine to use the name as a top level?Eclipse project, but I would avoid using it in real API.
A compromise solution would be to allocate a fixed namespace with the javax. prefix, for example javax.ee.
I would appreciate seeking Oracle's and lawyers' opinion on these package namespaces for new specs:
?- using javax.??- using javax.<fixednamespace>, e.g. javax.ee.?- using a new top-level prefix, such as eej. or ee.
I hope that Eclipse would be OK with such namespaces for API. Of course, non-API packages are a different thing and I'm perfectly OK to rename packages like org.glassfish to org.eclipse.glassfish unless it breaks some contracts.
Ondro
2017-10-03 8:45 GMT-07:00 reza_rahman <reza_rahman@xxxxxxxxx>:
I would say your assessment is entirely accurate. The concerns really speak to the continued strength of the Java and Java EE names. It would be very well received by the community if Oracle decided to make some further concessions on this subject. In particular I wonder if they can allow limited permission to just use the javax.enterprise sub-package for future specifications that come out of this effort?
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: John Clingan <jclingan@xxxxxxxxxx> Date: 10/3/17  8:36 AM  (GMT-08:00) To: EE4J community discussions <ee4j-community@xxxxxxxxxxx> Subject: Re: [ee4j-community] Glassfish 5.0 compatibility
It's clear from various chats at JavaOne that package names are an area of concern for the Java EE community as it moves into the Eclipse Foundation.
There is a *strong* desire to keep javax even for new specifications, but there are challenges with that approach.?
The secondary "vote", if you will, is to not use org.eclipse as the top-level domain, with it getting lost in the vastness of the namespace. The most pragmatic example I heard is that some customer/user organizations limit their use of namespaces for enterprise development, and org.eclipse is too broad (and org.eclipse .ee4j, for example, isn't a solution). A top-level domain of ee4j.* could be a potential compromise.
I am not advocating any position here, just trying to gather data points and convey them here.
On Oct 3, 2017 7:52 AM, Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
This isn't something that we normally put in a charter.
Where possible, we expect Eclipse projects to use the org.eclipse.* namespace (e.g. org.eclipse.glassfish.*), but there are exceptions (e.g. Eclipse Vert.x). We will seek advice from the Top Level Project's Project Management Committee (PMC) regarding exceptions.
Breaking an existing community is not a great idea. Assuming that we don't run into trademark issues that cannot be resolved, I expect that existing package and class names will be preserved, at least in some cases (e.g. official and de facto APIs), and at least initially. The project team may, for example, chart out a migration path for future versions that includes some sort of compatibility layer. Again, we'll expect that the PMC will work with the projects to sort out the right solution.
HTH,
Wayne
On Tue, Oct 3, 2017 at 8:35 AM, Mark Little <mlittle@xxxxxxxxxx> wrote:
I'm pretty sure Mike mentioned this in an earlier email to the group
 
but package names have not be considered yet for new additions but
 
existing code will come across unmodified.
 
 
 
Mark.
 
 
 
On Tue, Oct 3, 2017 at 7:09 AM, Emmanuel Bernard <ebernard@xxxxxxxxxx> wrote:
 
> Hi everyone,
 
>
 
> The charter says
 
> "The initial Eclipse Enterprise for Java RI is compatible with GlassFish 5.0, and passes Java EE 8 compatibility tests transitioned to EE4J."
 
>
 
> From what I have seen for Eclipse Ceylon, package renaming for implementations is part of the on boarding process. This means that people using actual Glassfish classes (not the spec classes) would have to convert their app and thus might not be qualified as compatible. Do we want to adjust the charter or will there be a package renaming exception for Eclipse Glassfish?
 
> Or maybe I've misunderstood the rules altogether :)
 
>
 
> Emmanuel
 
> _______________________________________________
 
> ee4j-community mailing list
 
> ee4j-community@xxxxxxxxxxx
 
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
 
> https://dev.eclipse.org/mailman/listinfo/ee4j-community
 
_______________________________________________
 
ee4j-community mailing list
 
ee4j-community@xxxxxxxxxxx
 
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
 
https://dev.eclipse.org/mailman/listinfo/ee4j-community
 
 
 
 
--
Wayne BeatonDirector of Open Source Projects
The Eclipse Foundation
 
 
 
_______________________________________________
 
ee4j-community mailing list
 
ee4j-community@xxxxxxxxxxx
 
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
 
https://dev.eclipse.org/mailman/listinfo/ee4j-community
 
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171003/352e651f/attachment.html>
 
------------------------------
 
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
 
 
End of ee4j-community Digest, Vol 2, Issue 13
*********************************************
 _______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=YE0iYXhwvvuyijSftCg1Wlnae106KFSPJTCBc7nbH64&s=RxKrnV6gKbx9rjCH3L0PNtrreWhoLAJKYMs79GQ9Rb4&e=



Back to the top