Major concern over 347's raison d'etre

[Joseph Ottinger]

Well, I joined the IRC channel expecting a crowd, but NOBODY WAS THERE EXCEPT ALEX. So nyar to you all.

But it got me thinking...

I'm wondering what JSR 347's raison d'etre, its reason for existence, is right now.

What follows is purely my POV of the moment, and I will deny anything with which I disagree five minutes from now. (Meaning "I might change my mind," not "I will deny in five minutes.")

When JSR107 was languishing and we were stuck with Java 7, there was a clear need for:

1) A caching API that actually existed, as opposed to JSR107's "one day soonish!" existence

2) A variation on that caching API that focused on data grid requirements, with compute grids being sort of along for the ride

3) A validation suite for packages that implemented #2 in some fashion.

Well, JSR107 has completed. Poorly, I might add, since they provide a key/value mechanism that doesn't, like, use Map as a basis. This was, pardon my language for any 107 participants, stupid.

So now I see 347 as a chance to do 107 correctly, which should be pretty freaking easy: create a mechanism by which a Map<K, V> can be provided, such that stream() and parallelStream() offer an access point to the provider's distributed capabilities.

In other words, I see Java 8 as a valid, viable target (if only because it makes 347's job so much easier) and I see it as a chance to show those ol' JSR107 people what a wise decision it was to be stuck in 2006.

This leaves #3 as a viable option as well. I do think the decision to build upon 107 is now, um, a flawed decision - I have been trying to figure out why you'd not use java.util.Map, even under java 5, and I've failed.

So what I would like to see for 347, speaking personally and with complete deniability, is at least a viable migration to the java 8 API - i.e., provide similar features, if not the same features, with different and deprecatable names to prevent collision. This is ONLY if older versions of Java should be included as part of the targeted platforms, which I'd fully understand.

The reason for this is, BTW, the mercury project - almost everything mercury does is part of Java 8's Map now. The only difference would be the acquisition mechanism.

Sorry, just jotting down some thoughts.

--
Joseph B. Ottinger
http://enigmastation.com

Memento mori.

[Cotton, Ben]

I apologize to you Joseph.  We were all here.  We should have published this at the 347 googlegroup forum.  Again, I apologize.

1] https://plus.google.com/116072392884422070588
[2] https://github.com/datagrids/spec/wiki/Proposed-features

Looking forward to it!
Mircea

View your event at http://www.google.com/calendar/event?action=VIEW&eid=XzYxMTNlYzloOGdwazhiYTY4Y3I0OGI5azcxMGpnYmExNmdxM2liOWw3MHBqZWRwazhnczM2ZHEyNjggbW1hcmt1c0ByZWRoYXQuY29t&tok=MjMjbWlyY2VhLm1hcmt1c0BnbWFpbC5jb21lM2E3OWNkYThmODdkMzA2NWQyMTVkOGEwMDU1OWRhODE3NjRhNjBk&ctz=Europe/London&hl=en.
View your event at http://www.google.com/calendar/event?action=VIEW&eid=XzYxMTNlYzloOGdwazhiYTY4Y3I0OGI5azcxMGpnYmExNmdxM2liOWw3MHBqZWRwazhnczM2ZHEyNjggbW1hcmt1c0ByZWRoYXQuY29t&tok=MjMjbWlyY2VhLm1hcmt1c0BnbWFpbC5jb21lM2E3OWNkYThmODdkMzA2NWQyMTVkOGEwMDU1OWRhODE3NjRhNjBk&ctz=Europe/London&hl=en.

 

 

 

 

 

 

Ben D. Cotton III
J.P.Morgan
Liquidity Risk Technology
277 Park Ave  Desk 08-GG64
New York, NY 10172-0003
212.622.5010
ben.c...@jpmorgan.com

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

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

[Joseph Ottinger]

Hey, no worries, Ben - I've not looked at that proposed-features page for a while. But that only solidifies what I think 347 should be, which is good, because it makes me look brilliant through idiocy.

[Rich Midwinter]

So that's where everyone was...!

Might be worth sending the agenda / outline of any conclusions to this list?

Thanks

Rich.

[Manik Surtani]

On Friday, 28 March 2014 09:41:02 UTC-7, Joseph Ottinger wrote:

I'm wondering what JSR 347's raison d'etre, its reason for existence, is right now.

When JSR107 was languishing and we were stuck with Java 7, there was a clear need for:

1) A caching API that actually existed, as opposed to JSR107's "one day soonish!" existence

2) A variation on that caching API that focused on data grid requirements, with compute grids being sort of along for the ride

3) A validation suite for packages that implemented #2 in some fashion.

Well, JSR107 has completed. Poorly, I might add, since they provide a key/value mechanism that doesn't, like, use Map as a basis. This was, pardon my language for any 107 participants, stupid.

I disagree and can happily argue my point but this isn't the forum for that.  Join the JSR 107 group for that.

 

So now I see 347 as a chance to do 107 correctly, which should be pretty freaking easy: create a mechanism by which a Map<K, V> can be provided, such that stream() and parallelStream() offer an access point to the provider's distributed capabilities.

I agree that we need streaming APIs, so +1 there.

 

In other words, I see Java 8 as a valid, viable target

+1

 

(if only because it makes 347's job so much easier) and I see it as a chance to show those ol' JSR107 people what a wise decision it was to be stuck in 2006.

Again, if you want to troll, this isn't the forum for that.

 

This leaves #3 as a viable option as well. I do think the decision to build upon 107 is now, um, a flawed decision - I have been trying to figure out why you'd not use java.util.Map, even under java 5, and I've failed.

So what I would like to see for 347, speaking personally and with complete deniability, is at least a viable migration to the java 8 API - i.e., provide similar features, if not the same features, with different and deprecatable names to prevent collision. This is ONLY if older versions of Java should be included as part of the targeted platforms, which I'd fully understand.

The reason for this is, BTW, the mercury project - almost everything mercury does is part of Java 8's Map now. The only difference would be the acquisition mechanism.

To sum it up - a lot of your thoughts here are more related to JSR 107 than JSR 347.  Bring those up on the JSR 107 group, read through postings on that group, etc.

As for 347, I agree that baselining it on Java 8 makes sense.  Streaming and lambdas make working on a dataset easy.

- M

[Joseph Ottinger]

Heh, I wasn't necessarily trying to troll with 107, but since I wasn't trying to write formally, some snark found its way in. Honestly, while it's frustrating that they didn't implement Map, I understand that there are situations in which it's entirely appropriate and important. I just don't think that 107 should be as relevant for 347, personally. But I'm only one voice, of course.

--

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

[Rick Hightower]

107 flashbacks... I remember the conversations around why they did not implement Map (ConcurrentMap).

But like Manik said. Wrong forum. But if you want to write me privately, I'd love to discuss the thought process around why Map was not chosen.

Rick Hightower
(415) 968-9037
Profile