Beginning getting GPars 2.0 in place

16 views
Skip to first unread message

Russel Winder

unread,
Mar 29, 2017, 2:19:49 AM3/29/17
to GPars Developers
Hi,

I will be taking little bites at getting rid of the 247 test fails in
the current jdk8 branch (*). This mornings strategy decision:

With the old ParallelArray stuff we added extension methods to the Java
ArrayList instances. In particular, there was a parallel attribute that
transformed an Array list to a ParallelArray, which then had lots of
interesting methods such as reduce, map, etc. With ditching the
ParallelArray (definitely the right choice so no going back) we have a
problem of what to do with the parallel attribute. Do we require people
to explicitly use stream().parallel() and then the official Java
methods, or do we provide a parallel attribute to hide this?


(*) Is there any objection to me making the current master branch the
1_X maintenance branch and switching jdk8 in as master?

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc

eve.no...@gmail.com

unread,
Apr 7, 2017, 3:42:03 PM4/7/17
to GPars Developers
so this means jdk8 becomes the default minimum jvm for GPars 2.0 ? it had to happen.

Cannot explain why, but FWIW feel that having an explicit parallel attribute implies future user code would/might be
more protected from our own future changes 'under the hatch' hence less user rewriting of their code later.
jim


On Wednesday, March 29, 2017 at 8:19:49 AM UTC+2, Russel Winder wrote:
Hi,

I will be taking little bites at getting rid of the 247 test fails in
the current jdk8 branch (*). This mornings strategy decision:

With the old ParallelArray stuff we added extension methods to the Java
ArrayList instances. In particular, there was a parallel attribute that
transformed an Array list to a ParallelArray, which then had lots of
interesting methods such as reduce, map, etc. With ditching the
ParallelArray (definitely the right choice so no going back) we have a
problem of what to do with the parallel attribute. Do we require people
to explicitly use stream().parallel() and then the official Java
methods, or do we provide a parallel attribute to hide this?  


(*) Is there any objection to me making the current master branch the
1_X maintenance branch and switching jdk8 in as master?

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russ...@ekiga.net

Russel Winder

unread,
Apr 9, 2017, 8:35:17 AM4/9/17
to eve.no...@gmail.com, GPars Developers
On Fri, 2017-04-07 at 12:42 -0700, eve.no...@gmail.com wrote:
> so this means jdk8 becomes the default minimum jvm for GPars 2.0 ? it
> had 
> to happen. 

That was always to be the case, so yes GPars 2.x requires JDK8.

> Cannot explain why, but FWIW feel that having an explicit parallel 
> attribute implies future user code would/might be
> more protected from our own future changes 'under the hatch' hence
> less 
> user rewriting of their code later.

Sounds like this is a vote for putting a parallel attribute in there in
some form, the question then is whether to try and hide the stream().

X.f()
X.stream().f()
X.stream().parallel().f()

Do these ungainly in a Groovy program? If not then maybe just do not
wrap the Streams stuff at all, but just say this data parallel stuff is
the JDK stuff and remove all the GPars wrapping. I have to admit I
think I like this. Strip down GPars, and add stuff back as people ask
for it if it is appropriate.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
signature.asc
Reply all
Reply to author
Forward
0 new messages