[gpars-dev] Re: [groovy-dev] GPars and Groovy

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[gpars-dev] Re: [groovy-dev] GPars and Groovy

Guillaume Laforge
Hi Russel,

Might indeed be a possibility to have GPars as a Groovy module.
I'm interested in hearing what others think.

We already bundle GPars in the distribution, so why not go the next mile, I'm open to this.

And for reference, historically, we had thought about integrating GPars in Groovy, but then Groovy wasn't modularized, and we didn't want to tie GPars rapidly evolving codebase to be too tied to Groovy's.

What's the current status with the jsr-xxx extensions and with JDK versions?
The state of remoting?

Guillaume


On Thu, Feb 19, 2015 at 6:58 PM, Russel Winder <[hidden email]> wrote:
With all the changes around the Groovy project, projects such as GPars
and Spock need to plan their future. Spock is SEP, hopefully the Spock
team are thinking about what to do. As for GPars:

GPars was a separate project so as to have an independent development
cycle. Also Groovy was monolithic at the time, and GPars needed to have
a separate existence so as to be usable with Java.

GPars can remain a separate project but some futures of Groovy may
impact massively wrt Groovy distributions.

Groovy is now modularized and it would be possible for GPars to be a
module in the Groovy codebase.

Given the state of Groovy, GPars, etc. I wonder if merging GPars into
Groovy as a module might be for the best of both GPars and Groovy.


--
Russel.
=============================================================================
Dr Russel Winder      t: <a href="tel:%2B44%2020%207585%202200" value="+442075852200">+44 20 7585 2200   voip: [hidden email]
41 Buckmaster Road    m: <a href="tel:%2B44%207770%20465%20077" value="+447770465077">+44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



--
Guillaume Laforge
Groovy Project Manager
Pivotal, Inc.

Reply | Threaded
Open this post in threaded view
|

[gpars-dev] Re: [groovy-dev] GPars and Groovy

Russel Winder-2
On Thu, 2015-02-19 at 20:01 +0100, Guillaume Laforge wrote:
> [….]
>
> What's the current status with the jsr-xxx extensions and with JDK
> versions?

So as to run on JDK 1.7, GPars mainline still uses extra166y, but we
have an internal clone so there is no transitive dependency on any
JSR166 artefacts. GPars does not run on JDK 1.6 so there is no need
for jsr166y.jar.

The JDK 1.8 work is currently stalled, but really needs to get going
again. The question would be how to organize this in a "Groovy module"
context. Currently it is a feature branch in the GPars repository,
maybe this can be the same. The issue is whether to use classifiers to
distinguish the (effectively deprecated) JDK 1.7 version from the JDK
1.8+ version, or whether to encode things in the artefact name.

> The state of remoting?

Remoting works and is already in Groovy since it has 1.3.0-SNAPSHOT. I
am sure there are things to be done, but that is now a maintenance
thing rather than a first development thing.

There is one more pull request to finalize, and then we can almost
certainly release 1.3.0. This JDK 1.7 version should then go into
maintenance mode only, and the JDK 1.8 version should become the
mainline with a view to making JDK 1.8 the base version of Java for
GPars. (*)

Of course if GPars were to become a Groovy module some of this
planning would have to change to fit with the Groovy Way™.


(*) Given the rejection of ParallelArray in favour of Stream in JDK 1.8 (which in my view is a good thing) continuing with ParallelArray in GPars is the wrong thing to do.
--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[gpars-dev] Re: [groovy-dev] GPars and Groovy

Russel Winder-2
On Fri, 2015-02-20 at 08:06 +0000, Russel Winder wrote:
>
[…]
The JDK 1.8 work is currently stalled, but really needs to get going
again. The question would be how to organize this in a "Groovy […]

I should have mentioned that there is an option of removing all the
extra166y dependent stuff and not replacing it at all, i.e. remove all
the current GPars API that is now just an adaptor to Stream API and
get Groovy people using Streams directly. I am torn between:

1. it is important to preserve the GPars API and just change the way
it is presented.

2. it is important to have as little code as possible between the user
code and the infrastructure code. This reinforces that Groovy is as
close to Java as it is possible to be.

Since Groovy Closures can be used where a Stream function might expect
a lambda expression, the interworking of Groovy and Java Streams makes
it highly feasible to follow 2 at the expense of breaking everyone's
code.

This is why the current policy is to declare the JDK 1.8 version of
GPars as GPars 2, it is likely a serious breaking change of API as
well as implementation.

The philosphy here is that GPars should be as small as possible, but
no smaller. 1 above breaks this, whereas 2 follows it.

It is also worth noting that ParallelArray was an eager system with
allocations, Stream is a lazy system avoiding allocations. Hence why
the former was rejected for Java in favour of the latter.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc (188 bytes) Download Attachment