Return-Path: X-Original-To: apmail-groovy-dev-archive@minotaur.apache.org Delivered-To: apmail-groovy-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 80B4F18225 for ; Sat, 28 Nov 2015 08:12:14 +0000 (UTC) Received: (qmail 55944 invoked by uid 500); 28 Nov 2015 08:12:14 -0000 Delivered-To: apmail-groovy-dev-archive@groovy.apache.org Received: (qmail 55903 invoked by uid 500); 28 Nov 2015 08:12:14 -0000 Mailing-List: contact dev-help@groovy.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.incubator.apache.org Delivered-To: mailing list dev@groovy.incubator.apache.org Received: (qmail 55893 invoked by uid 99); 28 Nov 2015 08:12:14 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Nov 2015 08:12:14 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id B0FE81A4154 for ; Sat, 28 Nov 2015 08:12:13 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.9 X-Spam-Level: ** X-Spam-Status: No, score=2.9 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id HprHQcbJvHtX for ; Sat, 28 Nov 2015 08:12:04 +0000 (UTC) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 6F43B20231 for ; Sat, 28 Nov 2015 08:12:03 +0000 (UTC) Received: by obdgf3 with SMTP id gf3so96597634obd.3 for ; Sat, 28 Nov 2015 00:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ADbz+zdyYokPdwY3ip32rSpLpYFmLLwuXZSNyG4CMJE=; b=TcGNjs216SMD7jQIh7BAp2dH7xPY3KD/fHt8O+0r8nMjOAa6FNJPeQzcqQQPwkZale ypJMcroqUqHDirBg2yM5aA9GZoPA2m/WUsq+YfhI6Z4A6+DhqV9xnnmX9/mMFXSm9NMq IgcTHUEpQ1sF4hQhNtVFvum9VUx+paEUKGglJtYxU6G27zjQFMaAOSiUdZjkCS+3vmYE 3reK9gdebRWA63actDusTB3tLctZUHSuSs+VWFrBiHyn30I/F9QvADGSuxja+HTOkGF3 U9xLU9eRTksIrWQDFnO5PaRuQLmNI4C12I/2pTMLARrs+jNO5+xUileMbTHJtFyRY5aZ yG8A== MIME-Version: 1.0 X-Received: by 10.60.92.138 with SMTP id cm10mr35005884oeb.64.1448698322276; Sat, 28 Nov 2015 00:12:02 -0800 (PST) Received: by 10.182.110.195 with HTTP; Sat, 28 Nov 2015 00:12:02 -0800 (PST) In-Reply-To: References: <56164EAB.1030302@gmx.org> <5648ADB3.9090906@gmx.org> <56570630.4060401@gmx.org> <56574CFC.4030204@gmx.net> Date: Sat, 28 Nov 2015 09:12:02 +0100 Message-ID: Subject: Re: challenges through Java modules (aka jigsaw) From: Thibault Kruse To: "dev@groovy.incubator.apache.org" Content-Type: multipart/alternative; boundary=047d7b33d418e2d9990525955cf7 --047d7b33d418e2d9990525955cf7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Given the funding of groovy changed last year, this situation will show what kind of support exists. I know my PRs are growing long beards. Maybe work on this could be modularized in smaller milestones, and be pursues over kickstarter or GSoC. Also I remember another discussion where I put forward the idea of reducing the core codebase. Meaning to split out things like groovysh. It's not ideal maybe, but this might be a 'pick the lesser of two evils' situation. On Thursday, November 26, 2015, Guillaume Laforge wrote: > I'm also thinking it's the right moment to "fix" things we've done wrong, > have a clean separation, not leaking implementation, etc. > That's feeling like the right moment to seize this opportunity. We > wouldn't keep the odd location of some of the classes we've already > mentioned. And as C=C3=A9dric says, we could also offer a converter in a = way or > another to help the migration. > People fear transitions like Python 2 to 3 would happen as soon as we > break compatibility, but the differences between Python 2 and 3 were much > bigger that what we're speaking about here. > > On Thu, Nov 26, 2015 at 8:49 PM, C=C3=A9dric Champeau < > cedric.champeau@gmail.com > > wrote: > >> Honestly I don't think 1 or 2 is reasonable. The simple example of XML i= s >> enough to show the damage. We won't be able to have a separate XML modul= e. >> That defeats the concepts of modules. Also it would lead to bigger jars, >> which is something we want to avoid as much as possible. Last but not >> least, the more I think about it, the more I think it's the event that w= e >> were all waiting for to finally do the breaking changes we've thought of >> for years. Eventually, we could come up with a smoother migration path, = by >> providing an automatic source converter (remapping packages). It would h= ave >> the same advantages as the ones R=C3=A9mi talked about. >> >> 2015-11-26 19:18 GMT+01:00 Pascal Schumacher > >: >> >>> Thanks for the detailed analysis C=C3=A9dric. :) >>> >>> Am 26.11.2015 um 13:10 schrieb C=C3=A9dric Champeau: >>> >>>> So what can we do? >>>> >>>> 1. the easiest, fastest path, is to kill all modules that we have >>>> today, and go with a single, good old, groovy-all jar. We would go yea= rs >>>> backwards, and it's definitely not something we want to do. We want to= have >>>> *more* modularization, in particular for Android, where the current sp= lit >>>> is still too big. >>>> 2. refactor modules so that each module has its own set of packages, >>>> and hope that we don't end up with a big groovy-all jar. Seems very >>>> unlikely. >>>> 3. break binary compatibility, move classes around, reorganize stuff. >>>> >>> >>> Am 26.11.2015 um 14:16 schrieb Jochen Theodorou: >>> >>>> I think we should concentrate on solving the package name conflicts in >>>> the new module system first... which basically is route 2. I am pretty= sure >>>> the jdk9 problems won't end there and we need time to solve these prob= lems >>>> as well... Of course we could still think about getting rid of the cal= lsite >>>> caching part and depend on say JDK7 as minimum version. >>>> >>> >>> I agree, we should try option 2 or - if it's nearly the same as option = 1 >>> - take option 1. >>> >>> I think option 3 is the worst. With our current lack of resources I >>> doubt that we could implement enough "killer" features to motivate peop= le >>> to update (getting people to update would be difficult anyway). >>> >>> Cheers, >>> Pascal >>> >> >> > > > -- > Guillaume Laforge > Apache Groovy committer & PMC member > Product Ninja & Advocate at Restlet > > Blog: http://glaforge.appspot.com/ > Social: @glaforge / Google+ > > --047d7b33d418e2d9990525955cf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Given the funding of groovy changed last year, this situation will show wha= t kind of support exists. I know my PRs are growing long beards. Maybe work= on this could be modularized in smaller milestones, and be pursues over ki= ckstarter or GSoC.

Also I remember another discussion wh= ere I put forward the idea of reducing the core codebase. Meaning to split = out things like groovysh.

It's not ideal maybe= , but this might be a 'pick the lesser of two evils' situation.
=
On Thursday, November 26, 2015, Guillaume Laforge <glaforge@gmail.com> wrote:
I'm also thinking it's the right mom= ent to "fix" things we've done wrong, have a clean separation= , not leaking implementation, etc.
That's feeling like the right mo= ment to seize this opportunity. We wouldn't keep the odd location of so= me of the classes we've already mentioned. And as C=C3=A9dric says, we = could also offer a converter in a way or another to help the migration.
People fear transitions like Python 2 to 3 would happen as soon as w= e break compatibility, but the differences between Python 2 and 3 were much= bigger that what we're speaking about here.

On Thu, Nov 26, 2015 at 8:49 PM,= C=C3=A9dric Champeau <ce= dric.champeau@gmail.com> wrote:
Honestly I don't think 1 or 2 is reasonable. The = simple example of XML is enough to show the damage. We won't be able to= have a separate XML module. That defeats the concepts of modules. Also it = would lead to bigger jars, which is something we want to avoid as much as p= ossible. Last but not least, the more I think about it, the more I think it= 's the event that we were all waiting for to finally do the breaking ch= anges we've thought of for years. Eventually, we could come up with a s= moother migration path, by providing an automatic source converter (remappi= ng packages). It would have the same advantages as the ones R=C3=A9mi talke= d about.

2015-11-26 19:18 GMT+01:00 Pascal Schumacher <<= a href=3D"javascript:_e(%7B%7D,'cvml','pascalschumacher@gmx.net= ');" target=3D"_blank">pascalschumacher@gmx.net>:
Thanks for the detailed analysis C=C3=A9dric. :)=

Am 26.11.2015 um 13:10 schrieb C=C3=A9dric Champeau:
So what can we do?

1. the easiest, fastest path, is to kill all modules that we have today, an= d go with a single, good old, groovy-all jar. We would go years backwards, = and it's definitely not something we want to do. We want to have *more*= modularization, in particular for Android, where the current split is stil= l too big.
 2. refactor modules so that each module has its own set of packages, and ho= pe that we don't end up with a big groovy-all jar. Seems very unlikely.=
3. break binary compatibility, move classes around, reorganize stuff.

Am 26.11.2015 um 14:16 schrieb Jochen Theodorou:
I think we should concentrate on solving the package name conflicts in the = new module system first... which basically is route 2. I am pretty sure the= jdk9 problems won't end there and we need time to solve these problems= as well... Of course we could still think about getting rid of the callsit= e caching part and depend on say JDK7 as minimum version.

 I agree, we should try option 2 or - if it's nearly the same as option = 1 - take option 1.

I think option 3 is the worst. With our current lack of resources I doubt t= hat we could implement enough "killer" features to motivate peopl= e to update (getting people to update would be difficult anyway).

Cheers,
Pascal




--
=
Guillaume Laforge
Apache Groovy committer & PMC member
Product Ninja & Advocate at Restlet

--047d7b33d418e2d9990525955cf7--