Peter Lawrey Application to Join the EG

[Greg Luck]

Guys

Peter Lawrey would like to join the 107 EG. We are in maintenance mode but are considering add new features.

Please vote in the normal way.

Regards

Greg Luck

web: http://gregluck.com

skype: gregrluck

yahoo: gregrluck

mobile: +61 408 061 622

Begin forwarded message:

Date: 1 December 2014 9:18:44 pm GMT+2

Subject: DataGrid wiki

From: Peter Lawrey <peter....@higherfrequencytrading.com>

To: Greg Luck <gr...@hazelcast.com>

Hello Greg,

   I would like to be considered the the expert panel of JSR-107.

In case you need any supporting information on who I am;

- I am the lead developer of OpenHFT with persisted queue and map designed for low latency. This is designed to be the fastest persisted collections in any language.

- I am the founder of the Performance Java User's Group, 1100+ members.

- I have the most Java answers on stackoverflow.com, 10K+, first to get a silver badge for JVM questions.

- My blog "Vanilla Java" has had over 3 million page views.

- My Java performance presentation has had 20K viewing. http://www.slideshare.net/PeterLawrey/writing-and-testing-high-frequency-trading-engines-in-java

Regards,

   Peter.

------

https://github.com/datagrids/spec/wiki

Features Proposed

https://github.com/datagrids/spec/wiki/Proposed-features

Including future based API.

public interface AsyncCache<K, V> {
    Future<V> get(K key);
    Future<Void> put(K key);
    Future<V> getAndPut(K key);
    Future<Boolean> remove(K key);
    Future<V> getAndRemove(K key);

    ... etc ...
}

[Brian Oliver]

Hi All,

As JSR-107 is now final, I think there's very little benefit accepting new members to the EG (if that's even possible?), mostly because;

1. No new APIs can be added (that's why the specification is "final" ;).

2. Only clarifications to the API / documentation / tests can really be made.

For #2 developers don't need to be a member of the EG.   Anyone can raise issues in the github issue tracker for these things, including posting questions that we try to answer pretty quickly.

For new APIs, they really have to occur as part of a new JSR (not part of maintenance of JSR-107), for which there isn't one for JCACHE (as yet).   The bottom line is that adding new APIs is a very big deal as it effects not only developers but every platform / vendor that's currently implemented the existing JSR.

Ultimately for a new JSR we'd need form a new EG, which I think is a good thing as the current JSR-107 is very large (lots of people being able to vote), but sadly has very few people making contributions.   

For the most part, the new JCP rules make it easier for anyone to observe and contribute without being an EG member, which I think is the "default case" for most people.   I think if we'd adopted the current JCP, the JSR-107 EG would actually be smaller, and somewhat more productive.   A good example of this is simply the fact that we had more feedback / corrections / suggestions about the API and specification from people outside of the JSR-107 EG than in it.

For me:

   -1 on joining the EG (for adding new features)

   +1 on joining the EG (to help maintain it, answer questions etc which can be done publicly already)

-- Brian (co-spec lead).

[Brian Oliver]

Regarding an AsyncCache, I think many challenging issues here that need to be addressed, that simply aren't reflected in the design of the proposed API.   

Let's walk through a few of them.

1. One of the core issues is understanding the semantics of what a "async" operations mean against a lossy data-structure like a cache.

Let's start by looking at the Future interface.

    https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html

There are a number of methods on Future which don't seem to make much sense in the realm of Caches.

For Example:  

    Future<V> future = cache.get(key);

    future.cancel(true);

What does "cancel" mean here?   Can an application really cancel a "get"?   What are the semantics of doing this?  Typically calling "get" will often update statistics, call backend-stores etc etc.   There's no concept of "canceling" these activities an furthermore, I'm struggling to see what this would actually mean.   Would statistics be "rolled back"?

Given this an other methods on Future, I think it's the wrong interface.

I think what *may* be requested is the ability to get a "callback" when a get has completed.  That is, an application wants to perform a "get" but doesn't want to wait around for it to complete.   So it may be better expressed something like:

interface AsynchronousCache {

   void getAndNotify(K key, CompletionListener<K, V> listener);

}

Similar arguments / thoughts can be made about the "put" and "remove" methods, especially about "cancel" semantics.

2. The Future interface essentially encourages synchronous, not asynchronous programming (and or unnecessary polling which is just a waste of time in my view).

For Example:

    Future<V> future = cache.get(key);

    V v = future.get();

This is the sort of thing we see pretty often.   Looking closely at the code, what we see is that the application is creating a future and then immediately waiting on it.   Effectively this is the same as (the synchronous version).

    V v = cache.get(key);

Worse is when we see things like:

For Example:

    Future<V> future = cache.get(key);

    while(!future.isDone()) { ... do something else ...}

    //now do something with the future...

Which arguably could be better written as something like:

    cache.get(key, new CompletionListener<K, V> {

        public void onCompletion(K key, V value) {

            //now do something with the future

        }

    });

Mostly what I'm suggesting / advocating is an "event-based solution", perhaps using "closures" / "lambdas" to perform the asynchronous processing.

The nice thing is that we have an example of this with our Cache.loadAll(...) method.

https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java

(and we can also use this as a Future if need be).

Thoughts?

-- Brian (co-spec lead)

[Noctarius]

Hi Brian,

About joining the JSR for new people:

I never really realized that JPA has 3 different JSR numbers. I also was quite sure the new version was created in the same JSR. Realizing that I’m wrong it might be that it doesn’t really make sense adding more people here but since I for myself joined after final release it is hard to say no :)

About the async API:

I guess looking at the Future interface is a bit, let’s call it, old school :) 

Nowadays you would look more to CompletableFuture which is the sub-interface meant to support reactive way programming. I agree that cancel is hard to argue about the idea of what it actually does but having a single callback might also not be sufficient in newer reactive applications.

Maybe it would make more sense to create something like a CachePromise interface which offers the way of waiting for the result CachePromise::get or adding callback listeners CachePromise::andThen.

PS: People using futures to wait for completion are either using the wrong API or haven’t understood the idea of async. It doesn’t mean there aren’t plenty of those wrong usages out there, it simply means we all did a very bad job in the past educating people to use Future :)

Chris

--
You received this message because you are subscribed to the Google Groups "jsr107" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr107+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Greg Luck]

Brian

JCP Process 2.9 states

All changes proposed by the ML shall make their way into the Specification either through the Maintenance Release process (described below) or through a new JSR. Changes appropriate for a Maintenance Release include bug-fixes, clarifications of the Specification, changes to the implementation of existing APIs, and implementation-specific enhancements. Changes introduced in Maintenance Releases – for example, modifications to existing APIs or the addition of new APIs - must not break binary compatibility as defined by the Java Language Specification. Changes that would break binary compatibility should therefore be deferred to a new JSR.

And the JLS defines binary compatibility as follows.

https://docs.oracle.com/javase/specs/jls/se5.0/html/binaryComp.html

I think there are some useful things we can do, such as considering async API additions which fit wiithin these rules. Peter Lawrey would like to help with these additions. thus the request to add him to JSR107. He is a member of JSR347 and would like to see the async stuff get done in JSR107.

Regards

Greg Luck

web: http://gregluck.com

skype: gregrluck

yahoo: gregrluck

mobile: +61 408 061 622

On 2 Dec 2014, at 9:07 pm, Brian Oliver <brian....@oracle.com> wrote:

Hi All,

As JSR-107 is now final, I think there's very little benefit accepting new members to the EG (if that's even possible?), mostly because;

1. No new APIs can be added (that's why the specification is "final" ;).

2. Only clarifications to the API / documentation / tests can really be made.

For #2 developers don't need to be a member of the EG.   Anyone can raise issues in the github issue tracker for these things, including posting questions that we try to answer pretty quickly.

For new APIs, they really have to occur as part of a new JSR (not part of maintenance of JSR-107), for which there isn't one for JCACHE (as yet).   The bottom line is that adding new APIs is a very big deal as it effects not only developers but every platform / vendor that's currently implemented the existing JSR.

Ultimately for a new JSR we'd need form a new EG, which I think is a good thing as the current JSR-107 is very large (lots of people being able to vote), but sadly has very few people making contributions.   

For the most part, the new JCP rules make it easier for anyone to observe and contribute without being an EG member, which I think is the "default case" for most people.   I think if we'd adopted the current JCP, the JSR-107 EG would actually be smaller, and somewhat more productive.   A good example of this is simply the fact that we had more feedback / corrections / suggestions about the API and specification from people outside of the JSR-107 EG than in it.

For me:

   -1 on joining the EG (for adding new features)

   +1 on joining the EG (to help maintain it, answer questions etc which can be done publicly already)

-- Brian (co-spec lead).

On Tuesday, December 2, 2014 6:27:57 AM UTC-5, Greg Luck wrote:

[Chris Dennis]

Personally I think this is a ‘letter’ versus ‘spirit’ issue.  I’ve CC’ed the PMO on this issue because I think it’s important that we get an official word on what the correct process is here.

That being said here is my interpretation:

"Changes introduced in Maintenance Releases … must not break binary compatibility as defined by the Java Language Specification."

This does not mean that any change that doesn’t break binary compatibility is suitable for a maintenance release.

"Changes appropriate for a Maintenance Release include bug-fixes, clarifications of the Specification, changes to the implementation of existing APIs, and implementation-specific enhancements."

This sentence explicitly calls out what is supposed to be done under a maintenance release – note that none of these relate to adding new features:

• bug-fixes
• clarifications of the Specification

• changes to the implementation of existing APIs

• implementation-specific enhancements

Adding features to the specification may be legal under the JCP strictly by the letter, but to me it goes explicitly against the spirit of the JCP process.  Adding new features is something that should be done under a new JSR as part of a JCache 2.0 effort.  Note that I’m not making a technical comment either way on whether I think async (or any other proposed feature) belongs in a caching specification, but rather that I don’t think a maintenance release is the right place to be adding features.

+1 to Peter as an EG member, although like Brian, I’m not sure I see the point this late in the game.

-1 to a JSR-107 maintenance release that adds features.

Chris

[Yannis Cosmadopoulos]

-1 on adding new features

[Heather VanCura]

Hi all,

We cannot add EG members to a JSR that has completed Final Release.
There should be only very minor modifications to a JSR following Final
Release. If you want to add new features, you should submit a new JSR
for approval, and then start forming a new Expert Group, and go through
the JSR life cycle stages.

For a description of Maintenance from the JCP Process Document see:
https://jcp.org/en/procedures/jcp2#5

Excerpt of text:

Changes appropriate for a Maintenance Release include bug-fixes,
clarifications of the Specification, changes to the implementation of
existing APIs, and implementation-specific enhancements. Changes
introduced in Maintenance Releases – for example, modifications to
existing APIs or the addition of new APIs - must not break binary
compatibility as defined by the Java Language Specification. Changes
that would break binary compatibility should therefore be deferred to a
new JSR.

Please let me know if you have any questions.

Best regards,
Heather

Yannis Cosmadopoulos wrote:
> -1 on adding new features
>
> On Wed, Dec 3, 2014 at 10:01 AM, Chris Dennis
> <chris.w...@gmail.com <mailto:chris.w...@gmail.com>> wrote:
>
> Personally I think this is a ‘letter’ versus ‘spirit’ issue. I’ve
> CC’ed the PMO on this issue because I think it’s important that we
> get an official word on what the correct process is here.
>
> That being said here is my interpretation:
>

> /"Changes introduced in Maintenance Releases … must not break
> binary compatibility as defined by the Java Language Specification."/

> This does not mean that any change that doesn’t break binary
> compatibility is suitable for a maintenance release.
>

> /"Changes appropriate for a Maintenance Release include bug-fixes,

> clarifications of the Specification, changes to the implementation

> of existing APIs, and implementation-specific enhancements."/

> This sentence explicitly calls out what is supposed to be done
> under a maintenance release – note that none of these relate to
> adding new features:
>

> * /bug-fixes/
> * //clarifications of the Specification//
> * /changes to the implementation of existing APIs/
> * /implementation-specific enhancements/

>
> Adding features to the specification may be legal under the JCP
> strictly by the letter, but to me it goes explicitly against the
> spirit of the JCP process. Adding new features is something that
> should be done under a new JSR as part of a JCache 2.0 effort.
> Note that I’m not making a technical comment either way on whether
> I think async (or any other proposed feature) belongs in a caching
> specification, but rather that I don’t think a maintenance release
> is the right place to be adding features.
>
> +1 to Peter as an EG member, although like Brian, I’m not sure I
> see the point this late in the game.
> -1 to a JSR-107 maintenance release that adds features.
>
> Chris
>
> On 12/3/14, 1:06 AM, "Greg Luck" <gr...@hazelcast.com

> <mailto:gr...@hazelcast.com>> wrote:
>
> Brian
>
> JCP Process 2.9 states
> All changes proposed by the ML shall make their way into the
> Specification either through the Maintenance Release process
> (described below) or through a new JSR. Changes appropriate for a
> Maintenance Release include bug-fixes, clarifications of the
> Specification, changes to the implementation of existing APIs, and
> implementation-specific enhancements. Changes introduced in
> Maintenance Releases – for example, modifications to existing APIs
> or the addition of new APIs - must not break binary compatibility
> as defined by the Java Language Specification. Changes that would
> break binary compatibility should therefore be deferred to a new JSR.
>
> And the JLS defines binary compatibility as follows.
>
> https://docs.oracle.com/javase/specs/jls/se5.0/html/binaryComp.html
>
> I think there are some useful things we can do, such as
> considering async API additions which fit wiithin these rules.
> Peter Lawrey would like to help with these additions. thus the
> request to add him to JSR107. He is a member of JSR347 and would
> like to see the async stuff get done in JSR107.
>
>
> Regards
>
> Greg Luck
>

> web: http://gregluck.com <http://gregluck.com/>
> skype: gregrluck
> yahoo: gregrluck
> mobile: +61 408 061 622 <tel:%2B61%20408%20061%20622>

>
>> On 2 Dec 2014, at 9:07 pm, Brian Oliver <brian....@oracle.com

>> web: http://gregluck.com <http://gregluck.com/>
>> skype: gregrluck
>> yahoo: gregrluck
>> mobile: +61 408 061 622 <tel:%2B61%20408%20061%20622>
>>
>>> Begin forwarded message:
>>>
>>> *Date: *1 December 2014 9:18:44 pm GMT+2
>>> *Subject: **DataGrid wiki*
>>> *From: *Peter Lawrey <peter....@higherfrequencytrading.com
>>> <http://higherfrequencytrading.com/>>
>>> *To: *Greg Luck <gr...@hazelcast.com <http://hazelcast.com/>>

>>>
>>> Hello Greg,
>>> I would like to be considered the the expert panel of
>>> JSR-107.
>>>
>>> In case you need any supporting information on who I am;
>>> - I am the lead developer of OpenHFT with persisted queue
>>> and map designed for low latency. This is designed to be the
>>> fastest persisted collections in any language.
>>> - I am the founder of the Performance Java User's Group,
>>> 1100+ members.
>>> - I have the most Java answers on stackoverflow.com

>>> <http://stackoverflow.com/>, 10K+, first to get a silver

>>> badge for JVM questions.
>>> - My blog "Vanilla Java" has had over 3 million page views.
>>> - My Java performance presentation has had 20K
>>> viewing. http://www.slideshare.net/PeterLawrey/writing-and-testing-high-frequency-trading-engines-in-java
>>>
>>> Regards,
>>> Peter.
>>>
>>> ------
>>>
>>>
>>> https://github.com/datagrids/spec/wiki
>>>
>>> Features Proposed
>>>
>>> https://github.com/datagrids/spec/wiki/Proposed-features
>>>
>>> Including future based API.
>>> |public interface AsyncCache<K, V> {
>>> Future<V> get(K key);
>>> Future<Void> put(K key);
>>> Future<V> getAndPut(K key);
>>> Future<Boolean> remove(K key);
>>> Future<V> getAndRemove(K key);
>>>
>>> ... etc ...
>>> }|
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "jsr107" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to jsr107+un...@googlegroups.com

> <mailto:jsr107+un...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
> --
> You received this message because you are subscribed to the Google
> Groups "jsr107" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to jsr107+un...@googlegroups.com

> <mailto:jsr107+un...@googlegroups.com>.

[Alex Snaps]

Hey Heather, Patrick,

I'm reviving this thread again, as apparently some further work can and is currently happening under jsr107... namely the introduction of a new async API.

As Peter is apparently actively contributing to that effort, don't we need to have him join the EG? I'm not really sure whether its actually required for as long as a JSPA has been received already, but would like some clarification on this (more so in the light of JSR364). I must say what can and cannot be done under a maintenance release is now really confusing me... 

Thanks, 

Alex

[Brian Oliver]

Hi Alex,

Greg and I met in December and spent about a day looking over the proposal and talking with the PMO regarding what can / can’t be added.

For the most part we were told;

a). We can’t add new people to the EG as it’s now in maintenance mode.   That said, we can take contributions providing the appropriate Contributor Agreements are executed.

b). Assuming we need to, we can make enhancements to the API so long as we maintain binary compatibility.   Adding a new API should allow this.

Given that we looked extensively at the proposed async API and after some discussions (including via email with Peter), we’d came to the initial conclusion that we’d probably go in a slightly different direction than what was being proposed, namely to ensure we support Java 8 style features (while not requiring Java 8). 

eg: One thought was that all asynchronous methods should not return futures, but instead take CompletionFutures (or the like) as input parameters.   We do this already with Cache Loading.   Ultimately this allows for “continuation-style” development and “futures” if required.

Another thought was that making every API call asynchronous was probably not a good idea… as it may not make sense.  

eg: cache.containsKey(key, Continuation) achieves what exactly?   Does it mean at some point in the future an application will receive a callback when the cache contains an entry, or does it mean at some point in the future an application will receive a callback that the cache may/may not contain a key.

The biggest challenge was with respect to the semantics of certain existing methods.  eg: what does a synchronous listener mean in the context of an asynchronous method call?   Personally I’m interested to know what the semantics of asynchronous entry processors would be, especially when either an application or cache server fails?

While it’s certainly possible adding asynchronous support to the API could be achieved in a maintenance release, I’m not sure that’s a good idea.

In the end we decided the most important thing was to get the first maintenance release out as these questions could not easily be answered in the time we had.

Hope this helps?

Cheers

— Brian

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

[Chris Dennis]

Obviously I’m not privy to all of the conversations that has happened here behind various closed doors, and with various people drawn from the PMO Office, the spec leads, the EG group, and externals, but I don’t see how any of the discussion that previously occurred on the mailing lists on this topic doesn’t still apply.  The upshot of the previous conversation was a pretty clear statement from the PMO, and a number of EG members, that if we want to add async operations to the JCache API then a new JSR needs to be created.

I don’t understand why there is continuing conversation on this topic, and I’m even more puzzled as to why the conversations that have obviously occurred have happened outside of both the EG list and the public 107 list.  As an EG member how am I supposed to provide input to help design specifications if the first time I see anything it comes in the form of a fully realized proposal with significant man-hour investment?

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to jsr107+un...@googlegroups.com.

[ben.c...@alumni.rutgers.edu]

(adding Peter Lawrey)

+1 to everything Chris wrote.

One central reason for 347 was to conveniently address things (like topology,  AsyncProcessors,etc.) 107 could not reasonably address in a timely fashion (once 107 re-ignited with activity in 2011 after a full decade of inactivity).  107 would specify the "tree" (JCACHE).  347 would specify the "forrest" (JGRID).

As pointed out, a new JSR seems to be the only JCP policy compliant route to pursue.  Can't call it 347 because that has some strange "only RedHat can be EG lead" binding.  So let's call it something non-347, non-107.  In such an approach, the EG can take on newly interested members (e.g. Peter Lawrey) without delay nor concern (i.e. it would be convenient).

[Heather VanCura]

Hello,

I am resending my message that I sent to the entire EG list (not a
private conversation) on 12/3/14 (pasting it below). Officially the JSR
EG disbands at Final Release; although many Maintenance Leads do
continue to consult with their EG members after Final Release. Also,
note that JSR 347 was withdrawn by Red Hat earlier this month. Please
let me know if you have any further questions.


Message to list from 12/14/14
----------------

Hi all,

We cannot add EG members to a JSR that has completed Final Release.
There should be only very minor modifications to a JSR following Final
Release. If you want to add new features, you should submit a new JSR
for approval, and then start forming a new Expert Group, and go through
the JSR life cycle stages.
For a description of Maintenance from the JCP Process Document see:
https://jcp.org/en/procedures/jcp2#5

Excerpt of text:
Changes appropriate for a Maintenance Release include bug-fixes,
clarifications of the Specification, changes to the implementation of
existing APIs, and implementation-specific enhancements. Changes
introduced in Maintenance Releases – for example, modifications to
existing APIs or the addition of new APIs - must not break binary
compatibility as defined by the Java Language Specification. Changes
that would break binary compatibility should therefore be deferred to a
new JSR.

Please let me know if you have any questions.

Best regards,
Heather

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

I hope this helps.

Heather VanCura
Manager, JCP PMO

ben.c...@alumni.rutgers.edu wrote:
> (adding Peter Lawrey)
>
> +1 to everything Chris wrote.
>

> One central reason for 347 was to /conveniently /address things (like

>>> <http://gmail.com/> <mailto:chris.w...@gmail.

>>> <http://hazelcast.com/>

>>> <http://gregluck.com/> <http://gregluck.com/>

>>> > skype: gregrluck
>>> > yahoo: gregrluck
>>> > mobile: +61 408 061 622 <tel:%2B61%20408%20061%20622>
>>> >
>>> >> On 2 Dec 2014, at 9:07 pm, Brian Oliver

>>> <brian....@oracle.com <http://oracle.com/>
>>> >> <mailto:brian....@oracle. <http://oracle.com/>com

>>> <http://gregluck.com/> <http://gregluck.com/>

>>> >> skype: gregrluck
>>> >> yahoo: gregrluck
>>> >> mobile: +61 408 061 622 <tel:%2B61%20408%20061%20622>
>>> >>
>>> >>> Begin forwarded message:
>>> >>>
>>> >>> *Date: *1 December 2014 9:18:44 pm GMT+2
>>> >>> *Subject: **DataGrid wiki*
>>> >>> *From: *Peter Lawrey
>>> <peter....@higherfrequencytrading.com
>>> <http://higherfrequencytrading.com/>

>>> >>> <http://higherfrequencytrading.com/

>>> <http://higherfrequencytrading.com/>>>
>>> >>> *To: *Greg Luck <gr...@hazelcast.com

>>> <http://hazelcast.com/> <http://hazelcast.com/>>

>>> <http://googlegroups.com/>
>>> > <mailto:jsr107+un...@googlegroups.com
>>> <http://googlegroups.com/>>.

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

>>> <https://groups.google.com/d/optout>.

>>> > --
>>> > You received this message because you are subscribed to the
>>> Google
>>> > Groups "jsr107" group.
>>> > To unsubscribe from this group and stop receiving emails
>>> from it,
>>> > send an email to jsr107+un...@googlegroups.com

>>> <http://googlegroups.com/>
>>> > <mailto:jsr107+un...@googlegroups.com
>>> <http://googlegroups.com/>>.

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

>>> <https://groups.google.com/d/optout>.

>>> >
>>> >
>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in
>>> the Google Groups "jsr107" group.
>>> To unsubscribe from this topic,
>>> visit https://groups.google.com/d/topic/jsr107/3lCBOA5TXDk/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email

>>> to jsr107+un...@googlegroups.com

[Alex Snaps]

Heather, 
Let me ask this straight question: would the addition of such an async API happen under a MR?

I seem to have understood the answer being "no" from that very email you kindly sent again. But looks like Brian now tells us that such an addition would actually be allowed under such a maintenance release... For as along as it'd be binary compatible. Effectively, I guess I am asking about the definition of "binary compatibility": do we mean for users? Or both users & implementors? Or is it for the spec lead(s) to decide. In all cases, this just feels confusing to users in any case though... As a user running a 1.0 implementation against a 1.0.1 API would just run into LinkageError and the like.

Thanks, 

Alex

>>> to jsr107+unsubscribe@googlegroups.com
>>> <mailto:jsr107+unsubscribe@googlegroups.com>.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "jsr107" group.
>> To unsubscribe from this group and stop receiving emails from it,

>> send an email to jsr107+unsubscribe@googlegroups.com
>> <mailto:jsr107+unsubscribe@googlegroups.com>.

>> For more options, visit https://groups.google.com/d/optout.
>> --
>> You received this message because you are subscribed to the Google
>> Groups "jsr107" group.
>> To unsubscribe from this group and stop receiving emails from it,

>> send an email to jsr107+unsubscribe@googlegroups.com
>> <mailto:jsr107+unsubscribe@googlegroups.com>.

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

--
You received this message because you are subscribed to the Google Groups "jsr107" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jsr107+unsubscribe@googlegroups.com.

[Heather VanCura]

Hi Alex,

You should not be adding features in a MR.

- Heather

Alex Snaps wrote:
> Heather,
> Let me ask this straight question: would the addition of such an async
> API happen under a MR?
> I seem to have understood the answer being "no" from that very email
> you kindly sent again. But looks like Brian now tells us that such an
> addition would actually be allowed under such a maintenance release...
> For as along as it'd be binary compatible. Effectively, I guess I am
> asking about the definition of "binary compatibility": do we mean for
> users? Or both users & implementors? Or is it for the spec lead(s) to
> decide. In all cases, this just feels confusing to users in any case
> though... As a user running a 1.0 implementation against a 1.0.1 API
> would just run into LinkageError and the like.
> Thanks,
> Alex
>
>
> On Tue Feb 10 2015 at 5:38:02 PM Heather VanCura <hea...@jcp.org

> <mailto:brian....@oracle.com>
> >> <mailto:brian....@oracle.com

> >>> <mailto:alex....@gmail.com <mailto:alex....@gmail.com>>>

> >>> > <chris.w...@gmail.com <mailto:chris.w...@gmail.com>
> >>> <http://gmail.com/> <mailto:chris.w...@gmail
> <mailto:chris.w...@gmail>.

> <gr...@hazelcast.com <mailto:gr...@hazelcast.com>

> >>> <brian....@oracle.com <mailto:brian....@oracle.com>
> <http://oracle.com/>
> >>> >> <mailto:brian....@oracle <mailto:brian....@oracle>.

> <mailto:peter....@higherfrequencytrading.com>

> >>> <http://higherfrequencytrading.com/>
> >>> >>> <http://higherfrequencytrading.com/
> >>> <http://higherfrequencytrading.com/>>>
> >>> >>> *To: *Greg Luck <gr...@hazelcast.com

> <mailto:gr...@hazelcast.com>

> <mailto:jsr107%2Bun...@googlegroups.com>
> >>> <http://googlegroups.com/>
> >>> > <mailto:jsr107+un...@googlegroups.com
> <mailto:jsr107%2Bun...@googlegroups.com>

> >>> <http://googlegroups.com/>>.
> >>> > For more options, visit
> https://groups.google.com/d/optout
> >>> <https://groups.google.com/d/optout>.
> >>> > --
> >>> > You received this message because you are subscribed
> to the
> >>> Google
> >>> > Groups "jsr107" group.
> >>> > To unsubscribe from this group and stop receiving emails
> >>> from it,
> >>> > send an email to jsr107+un...@googlegroups.com

> <mailto:jsr107%2Bun...@googlegroups.com>
> >>> <http://googlegroups.com/>
> >>> > <mailto:jsr107+un...@googlegroups.com
> <mailto:jsr107%2Bun...@googlegroups.com>

> >>> <http://googlegroups.com/>>.
> >>> > For more options, visit
> https://groups.google.com/d/optout
> >>> <https://groups.google.com/d/optout>.
> >>> >
> >>> >
> >>>
> >>>
> >>> --
> >>> You received this message because you are subscribed to a topic in
> >>> the Google Groups "jsr107" group.
> >>> To unsubscribe from this topic,
> >>> visit
> https://groups.google.com/d/topic/jsr107/3lCBOA5TXDk/unsubscribe.
> >>> To unsubscribe from this group and all its topics, send an email

> >>> to jsr107+un...@googlegroups.com
> <mailto:jsr107%2Bunsu...@googlegroups.com>
> >>> <mailto:jsr107+un...@googlegroups.com
> <mailto:jsr107%2Bunsu...@googlegroups.com>>.

> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "jsr107" group.
> >> To unsubscribe from this group and stop receiving emails from it,

> >> send an email to jsr107+un...@googlegroups.com
> <mailto:jsr107%2Bunsu...@googlegroups.com>
> >> <mailto:jsr107+un...@googlegroups.com
> <mailto:jsr107%2Bunsu...@googlegroups.com>>.

> >> For more options, visit https://groups.google.com/d/optout.
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "jsr107" group.
> >> To unsubscribe from this group and stop receiving emails from it,

> >> send an email to jsr107+un...@googlegroups.com
> <mailto:jsr107%2Bunsu...@googlegroups.com>
> >> <mailto:jsr107+un...@googlegroups.com
> <mailto:jsr107%2Bunsu...@googlegroups.com>>.

> >> For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "jsr107" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to jsr107+un...@googlegroups.com
> <mailto:jsr107%2Bunsu...@googlegroups.com>.

[Alex Snaps]

Thanks Heather, that's what I thought I had understood!
I guess we can put this one to rest then now. I'd propose introducing some label in github in something to triage MR work vs. new JSR (JCache 2.0 or JGrid or whatever) work in order to avoid all that confusion from now on... wdyt Brian, Greg?

>     <mailto:brian.oliver@oracle.com>
>     >> <mailto:brian.oliver@oracle.com

>     >>> to jsr107+unsubscribe@googlegroups.com
>     <mailto:jsr107%2Bunsubscribe@googlegroups.com>
>     >>> <mailto:jsr107+unsubscribe@googlegroups.com
>     <mailto:jsr107%2Bunsubscribe@googlegroups.com>>.

>     >>> For more options, visit https://groups.google.com/d/optout.
>     >>
>     >> --
>     >> You received this message because you are subscribed to the Google
>     >> Groups "jsr107" group.
>     >> To unsubscribe from this group and stop receiving emails from it,

>     >> send an email to jsr107+unsubscribe@googlegroups.com
>     <mailto:jsr107%2Bunsubscribe@googlegroups.com>
>     >> <mailto:jsr107+unsubscribe@googlegroups.com
>     <mailto:jsr107%2Bunsubscribe@googlegroups.com>>.

>     >> For more options, visit https://groups.google.com/d/optout.
>     >> --
>     >> You received this message because you are subscribed to the Google
>     >> Groups "jsr107" group.
>     >> To unsubscribe from this group and stop receiving emails from it,

>     >> send an email to jsr107+unsubscribe@googlegroups.com
>     <mailto:jsr107%2Bunsubscribe@googlegroups.com>
>     >> <mailto:jsr107+unsubscribe@googlegroups.com
>     <mailto:jsr107%2Bunsubscribe@googlegroups.com>>.

>     >> For more options, visit https://groups.google.com/d/optout.
>     >
>
>     --
>     You received this message because you are subscribed to the Google
>     Groups "jsr107" group.
>     To unsubscribe from this group and stop receiving emails from it,

>     send an email to jsr107+unsubscribe@googlegroups.com
>     <mailto:jsr107%2Bunsubscribe@googlegroups.com>.

[Ben Cotton]

Interesting Alex .... Noting that 107 left a few things out in order to complete, and that 347 was withdrawn, a new JSR to deliver JCACHE 2.0 would have an opportunity to accommodate some *very* compelling capabilities:

-  Transactions

-  AsynchProcessors

-  Distributed Cache Topologies

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to jsr107+un...@googlegroups.com.

[Alex Snaps]

This has been taken elsewhere: 
https://github.com/jsr107/jsr107spec/issues/307#issuecomment-73816562

That being said, I'm letting the both leads figure it all out, and we shall see where this gets and whether input from the EG is sought on this possible MR. 

[Jens Wilke]

On Wednesday 11 February 2015 02:22:14 Alex Snaps wrote:
> This has been taken elsewhere:
> https://github.com/jsr107/jsr107spec/issues/307#issuecomment-73816562
>
> That being said, I'm letting the both leads figure it all out, and we shall see where this gets and whether input from the EG is sought on this possible MR.

Hi all,

as issue 307 points out (and if I understand it right) the async methods should be added to the Cache interface.

Gregs comment:
> If a use is using JCache 1.0 his code will continue to work with a JCache 1.1 interface without requiring
> a recompile. So it is binary compatible.

> As an implementer of JCache, you would be required to change your implementation to adopt JCache 1.1.
> But that will be true whether we add these methods or not.

Adding methods to an interface always breaks binary compatibility.

The Cache interface is a public interface. There may be more implementors of that interface, not only the Cache implementations.
For example there can be tools and applications that implement proxies to trace caching activity.

I would propose:

interface AsyncFunctions { ... }

and

interface AdvancedCache implements Cache, AsyncFunctions { }

Best,

Jens

--
"Everything superfluous is wrong!"

// Jens Wilke - headissue GmbH - Germany
\// http://www.headissue.com

[Steve Millidge]

I imagine the next step is to raise a new JSR and EG as in addition to this we need to integrate JCache with JavaEE 8 or it will miss the boat again.

Steve Millidge
C2B2
T: 08450 539457 | M: 07920 100626 | W: www.c2b2.co.uk | E: smil...@c2b2.co.uk

To unsubscribe from this group and stop receiving emails from it, send an email to jsr107+un...@googlegroups.com.

[Greg Luck]

Steve

I think it is a ton of work to integrate JCache into Java EE8. I would like to see a new JSR for that with someone who wants to do it. 

Regards

Greg Luck

web: http://gregluck.com

skype: gregrluck

yahoo: gregrluck

mobile: +61 408 061 622

On 13 Feb 2015, at 12:15 am, Steve Millidge <smil...@c2b2.co.uk> wrote:

I imagine the next step is to raise a new JSR and EG as in addition to this we need to integrate JCache with JavaEE 8 or it will miss the boat again.

Steve Millidge
C2B2
T: 08450 539457 | M: 07920 100626 | W: www.c2b2.co.uk | E: smil...@c2b2.co.uk

-----Original Message-----
From: jsr...@googlegroups.com [mailto:jsr...@googlegroups.com] On Behalf Of Heather VanCura
Sent: 10 February 2015 22:38
To: jsr...@googlegroups.com
Cc: ben.c...@alumni.rutgers.edu; yan...@gmail.com; jsr-1...@jcp.org; p...@jcp.org; Peter Lawrey
Subject: Re: [jsr-107-eg] Peter Lawrey Application to Join the EG

To unsubscribe from this group and stop receiving emails from it, send an email to jsr107+un...@googlegroups.com.