Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Use of javax.* in new EE4J projects
First and foremost the MR Greg mentioned looks like the foundation to even be accepted by ANY Eclipse project (we solved this in JSR 363 at a much earlier stage and the final version is now used by Smart Home and other Eclipse projects)
https://jcp.org/aboutJava/communityprocess/maintenance/jsr107/index.html

Since JSR 107 is not a part of the Java EE Platform, it is not affected by EE4J changes or donations per se. 

What's crucial for every JSR also the existing ones is to get a proper Module definition for "Java EE 9" (aka EE4J) which shall be based on Java SE 8 (or Eclipse OpenJ9 maybe?;-) at the very least as minimum version. 
Everything should expose a module-info like JSON-B 1.0 or JSON-P 1.1.x do already, while CDI 2 or JAX-RS 2.1 (to only take MicroProfile ingredients) don't. 
So to make sense under an EE4J Umbrella, every JSR that is either part of the "platform" or wishes to be used as optional module (like JCache or MVC, neither or them make sense as a mandatory requirement for a "Micro Profile" or "EE4J Core" if you want) they better try to define a proper module instead of relying on auto-module by Jigsaw.

The proposed MR of JSR 107 does not yet define a module-info either btw, but it is not alone, so don't panic now ;-)

Werner 



On Sat, Nov 4, 2017 at 5:00 PM, <ee4j-community-request@xxxxxxxxxxx> wrote:
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@eclipse.org

You can reach the person managing the list at
        ee4j-community-owner@eclipse.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."


Today's Topics:

   1. Re: Use of javax.* in new EE4J projects (Rudy De Busscher)
   2. Re: Use of javax.* in new EE4J projects (Giorgio Desideri)


----------------------------------------------------------------------

Message: 1
Date: Sat, 4 Nov 2017 08:41:26 +0100
From: Rudy De Busscher <rdebusscher@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Use of javax.* in new EE4J projects
Message-ID:
        <CAL+wt-700X+n2R7xiF2S2cN5QdPaL48k628fo+ejawWZS_0F9w@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

This sentence

Any API that continues to evolve through the JCP can continue to use
> javax.* package names as it always has.


means that if

the process has changed from JCP to the yet unnamed and to be formed
> Eclipse Community Process.


we have to change the package names, even for existing specifications which
are continued under the Eclipse Foundation?

Or do I read this wrong?

Backwards compatibility is in my eyes THE most important thing about Java
and Java EE and that seems to be sacrificed lately.

Rudy

On 3 November 2017 at 21:06, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

> It would be great to include JCache in EE4J!
>
> Any API that continues to evolve through the JCP can continue to use
> javax.* package names as it always has.
>
> We're still working out the rules for existing JCP specs that want to
> evolve outside of the JCP.  Clearly JCache is an existing JCP spec.
>
> Completely new specs outside of the JCP should not expect to use javax.*
> package names.
>
> Greg Luck wrote on 11/ 3/17 11:07 AM:
>
> Hi
>
> Had a call with Mike today about moving JCache across to EE4J.
>
> We have JCache 1.1 in the JCP review process now and it should be out in a
> few weeks? time. So we could consider moving after that point.
>
> The biggest issue to me is that, at least currently, any new APIs will not
> be allowed to use javax. Today we use javax.cache. This would mean that
> JCache 2 would need to change its package name. We have 13 implementations
> out there and a huge amount of user code that uses javax.cache. This would
> be an extremely disruptive change.
>
> In our case Oracle is a copyright owner along with myself for the spec. As
> an owner, Oracle if they wished, should be able to allow JCache 2 to
> continue to use the javax.cache package even though the process has changed
> from JCP to the yet unnamed and to be formed Eclipse Community Process.
>
> Interested in anyone?s thoughts on this.
>
> Regards
>
> Greg Luck
>
>
>
>
> _______________________________________________
> ee4j-community mailing listee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171104/28be8305/attachment.html>

------------------------------

Message: 2
Date: Sat, 4 Nov 2017 15:49:42 +0700
From: Giorgio Desideri <giorgio.desideri@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Use of javax.* in new EE4J projects
Message-ID:
        <CA+5CEso=Z_XMAFMopmwi3MSeYC8SiSX6kNnWyxOuTy67-igBDQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

Hi,

I think if we want satisfy the desire to include the JCache inside EE4J,
the questions to raise are:
- how many big / how much is the effort to rename packages, "remove Oracle
copyright", and apply inside EE4J ?
- this time for changes can be suitable for changes inside the current JCP ?

If the AND of the both answers is TRUE or 1, can be scheduled, otherwise
not, good for next release

Thanks

*Doct. Giorgio Desideri*

*Skype:*                  kallsu82
*Linkedin*:
http://www.linkedin.com/pub/giorgio-desideri/7/a5a/176

*PGP-Public Key*:   4096R/E8B659C4
*PGP Fingerprint*:    52C8 09E5 346B A2EE E210  2399 073A 778E E8B6 59C4

-----

*"If people do not believe that mathematics is simple, it is only because
they do not realize how complicated life is"  (J. von Neumann)*
*"Il saggio coltiva Linux, perch? s? che Window$ si pianta da solo !"*



2017-11-04 14:41 GMT+07:00 Rudy De Busscher <rdebusscher@xxxxxxxxx>:

> This sentence
>
> Any API that continues to evolve through the JCP can continue to use
>> javax.* package names as it always has.
>
>
> means that if
>
> the process has changed from JCP to the yet unnamed and to be formed
>> Eclipse Community Process.
>
>
> we have to change the package names, even for existing specifications
> which are continued under the Eclipse Foundation?
>
> Or do I read this wrong?
>
> Backwards compatibility is in my eyes THE most important thing about Java
> and Java EE and that seems to be sacrificed lately.
>
> Rudy
>
> On 3 November 2017 at 21:06, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
>
>> It would be great to include JCache in EE4J!
>>
>> Any API that continues to evolve through the JCP can continue to use
>> javax.* package names as it always has.
>>
>> We're still working out the rules for existing JCP specs that want to
>> evolve outside of the JCP.  Clearly JCache is an existing JCP spec.
>>
>> Completely new specs outside of the JCP should not expect to use javax.*
>> package names.
>>
>> Greg Luck wrote on 11/ 3/17 11:07 AM:
>>
>> Hi
>>
>> Had a call with Mike today about moving JCache across to EE4J.
>>
>> We have JCache 1.1 in the JCP review process now and it should be out in
>> a few weeks? time. So we could consider moving after that point.
>>
>> The biggest issue to me is that, at least currently, any new APIs will
>> not be allowed to use javax. Today we use javax.cache. This would mean that
>> JCache 2 would need to change its package name. We have 13 implementations
>> out there and a huge amount of user code that uses javax.cache. This would
>> be an extremely disruptive change.
>>
>> In our case Oracle is a copyright owner along with myself for the spec.
>> As an owner, Oracle if they wished, should be able to allow JCache 2 to
>> continue to use the javax.cache package even though the process has changed
>> from JCP to the yet unnamed and to be formed Eclipse Community Process.
>>
>> Interested in anyone?s thoughts on this.
>>
>> Regards
>>
>> Greg Luck
>>
>>
>>
>>
>> _______________________________________________
>> ee4j-community mailing listee4j-community@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://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
>>
>>
>
> _______________________________________________
> 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/20171104/3064db0a/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 3, Issue 16
*********************************************

Back to the top