You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Russel Winder <ru...@winder.org.uk> on 2017/11/21 02:43:20 UTC
Building Groovy
Hi,
It seems that building Groovy immediately after building Groovy means
everything is compiled again. Surely what should be a null build should
take 0 seconds rather than 5 minutes? (A null build taking 5 minutes
rather than 0 seconds would, in the native code world, indicate a
failed build system.)
Also Groovy 3 still seems to be built twice, non-indy and indy. Isn't
it time to decide and ditch one of the builds to save 3 minutes on the
build?
--
Russel.
===========================================
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
Re: Building Groovy
Posted by Russel Winder <ru...@winder.org.uk>.
On Tue, 2017-11-21 at 17:28 +1000, Paul King wrote:
> The "double" build is because of indy vs non-indy (one wipes out the
> other)
> because of some assumptions that keep other parts of the build
> simple.
> Could no doubt be streamlined given some TLC.
Ah, I had assumed the builds were handled in separate target
directories. If that is not the case then the behaviour is explained.
> Last I checked there were different performance characteristics
> between
> indy/non-indy. We haven't gotten around to working out the best path
> forward yet that will give us one set of jars without losing
> performance in
> some scenarios. Again, just needs some time dedicated to it.
I guess it is all about resource, as ever. I will try and get GPars 2.0
going next year (*). It may be that I could then get involved in
looking at the build, but on this no promises (**). I wonder if someone
could fund Schalk to do some work on this?
(*) I know I promised this for the last two years and have failed. Long
story.
(**) I seem to be doing mostly Rust stuff, with a bit of D and C++,
these days.
--
Russel.
===========================================
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
Re: Building Groovy
Posted by MG <mg...@arscreat.com>.
But the fact that it is an internal implementation detail does not
prohibit technical minded people to be interested in them. Most
developers I have met were interested in such things.
Most men have e.g. at least some knowledge about the inner workings of
their car, even if that are internal implementation details.
In any case I think it would be worth a try, if nothing comes of it,
nothing is lost...
On 21.12.2017 15:59, Cédric Champeau wrote:
>
>>
>> I disagree. 99% of our users don't even know what call site
>> caching is. They don't know what invokedynamic means,
>
> You think that 99% of Java professionals do not know what a
> feature that has been around since Java 7 is ?
> And even if that was the case: Google "java invoke dynamic" =>
> https://stackoverflow.com/questions/6638735/whats-invokedynamic-and-how-do-i-use-it
> <https://stackoverflow.com/questions/6638735/whats-invokedynamic-and-how-do-i-use-it>
> from 2011
>
>
> Of course. It's not a user facing feature. It's an internal
> implementation detail of JVM languages. Even if you play with
> `MethodHandles`, you will never deal directly with invoke dynamic.
Re: Building Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
>
>
> I disagree. 99% of our users don't even know what call site caching is.
> They don't know what invokedynamic means,
>
>
> You think that 99% of Java professionals do not know what a feature that
> has been around since Java 7 is ?
> And even if that was the case: Google "java invoke dynamic" =>
> https://stackoverflow.com/questions/6638735/whats-
> invokedynamic-and-how-do-i-use-it from 2011
>
Of course. It's not a user facing feature. It's an internal implementation
detail of JVM languages. Even if you play with `MethodHandles`, you will
never deal directly with invoke dynamic.
Re: Building Groovy
Posted by MG <mg...@arscreat.com>.
On 19.12.2017 09:37, Cédric Champeau wrote:
> 2017-12-19 2:21 GMT+01:00 MG <mgbiz@arscreat.com
> <ma...@arscreat.com>>:
>
> Hmmm, I don't know if Paul has some comeback, but to me you make a
> very convincing point...
> In that case the best way forward to me seems to be to
> 1) Ask non-@CompileStatic Groovy users who can afford the time to
> switch to the invoke dynamic variety of the Groovy jars and report
> back on performance issues (tests that run much slower, etc)
>
>
> This has been the case for years now, and almost nobody uses the
> invokedynamic version.
Speaking from my own experience: Of course, why would they - unless you
give them a reason/motivation...
> 2) Add a clearly visible message to the Groovy distribution
> download section, Maven/etc URL spots that Groovy 3.0 will be
> invoke dynamic only, and again ask for people to use indy now &
> give feedback if code seems to be unusally slow
>
>
> I disagree. 99% of our users don't even know what call site caching
> is. They don't know what invokedynamic means,
You think that 99% of Java professionals do not know what a feature that
has been around since Java 7 is ?
And even if that was the case: Google "java invoke dynamic" =>
https://stackoverflow.com/questions/6638735/whats-invokedynamic-and-how-do-i-use-it
from 2011
> and they don't have to. It's an internal implementation detail. What
> they care, on the other hand, is performance. So "is it slow? yes ->
> report a bug". No one has to care about the implementation detail,
> unless you're a language designer.
Or "is it slow? yes -> Groovy sucks (1st time user) / has become slow
(returning user) -> let's use Kotlin"
In the web there are still posts that present Groovy as being slow, back
from the time when it actually was, so it actually becoming slow is
something which in my humble opinion one should try to avoid.
In my experience with technical minded people it is never a bad idea to
explain why things are the way they are.
Paul seems to be of the opinion that it is just a problem of resources,
but even then I think it would be better to have more input now, to be
able to gauge the extent of the problem. Anyways, just my 0.1 EUR...
Cheers,
mg
Re: Building Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
2017-12-19 2:21 GMT+01:00 MG <mg...@arscreat.com>:
> Hmmm, I don't know if Paul has some comeback, but to me you make a very
> convincing point...
> In that case the best way forward to me seems to be to
> 1) Ask non-@CompileStatic Groovy users who can afford the time to switch
> to the invoke dynamic variety of the Groovy jars and report back on
> performance issues (tests that run much slower, etc)
>
This has been the case for years now, and almost nobody uses the
invokedynamic version. It's not just the fault of the users: when you have
a dependency on a library that is built to use the old call site caching
version, it's just not possible to "switch it to indy".
> 2) Add a clearly visible message to the Groovy distribution download
> section, Maven/etc URL spots that Groovy 3.0 will be invoke dynamic only,
> and again ask for people to use indy now & give feedback if code seems to
> be unusally slow
>
I disagree. 99% of our users don't even know what call site caching is.
They don't know what invokedynamic means, and they don't have to. It's an
internal implementation detail. What they care, on the other hand, is
performance. So "is it slow? yes -> report a bug". No one has to care about
the implementation detail, unless you're a language designer.
> 3) Start a competition who can come up with the most unexpectedly worst
> performing piece of Groovy indy code... ;-)
> (To be quite honest, I am wondering myself how invoke dynamic can be
> slower than the older, homebrewn approach, even if that is highly optimized
> - it seems to me like it should be a bit like a software renderer going up
> against a GPU...)
>
Again, I don't think optimizing the worst case is what we need to do. We
need to optimize the most common cases. If there are edge cases worth
optimizing, we can try, but we shouldn't compromise on the other cases for
a corner one.
>
> Cheers,
> mg
>
>
>
> On 18.12.2017 15:54, Jochen Theodorou wrote:
>
>> On 18.12.2017 01:01, MG wrote:
>>
>>> Just came across this as an example where using Groovy 2.4.6
>>> invokedynamic seems to have been much slower than the older callsite
>>> caching mechanism: https://www.linkedin.com/pulse
>>> /how-make-groovy-fast-java-david-e-jones (https://dzone.com/articles/ho
>>> w-to-make-groovy-as-fast-as-java)
>>>
>>
>> It is a chicken-egg problem. We still need to optimize indy in some
>> areas. But this does not happen if no users care to give detailed reports
>> which we can base optimizations on. They on the other hand simply switch to
>> static compilation or old callsite caching then. So in the end there is no
>> optimization, because optimizations tend to inflate and complicate code.
>>
>> And for the old callsite caching there is another part... I highly doubt
>> it is still well working with JDK9. Worse, I do not see how this can be
>> made work efficiently under JDK9. The preferred way in JDK9 is
>> invokedynamic after all. And while they (JDK developers) tend to increase
>> the capabilities of invokedynamic, it is the opposite story for reflection
>> (deep reflection, callsite sensitive rights made even worse through
>> modules, ...)
>>
>> So frankly I do not see much of a future for the old callsite caching
>>
>> bye Jochen
>>
>>
>
Re: Building Groovy
Posted by Russel Winder <ru...@winder.org.uk>.
On Wed, 2017-12-20 at 17:48 -0700, Nathan Harvey wrote:
>
[…]
> and
> advertised forum. Unfortunately the concept of a mailing list is
> deeply
[…]
For some people forums are anathema, email being the only sane way.
Other believe the opposite. The only community I know that deal with
this is the D community that has an email/forum system that everyone
can use the way they want.
The Gradle forum is a huge turn off for me
The Rust forum likewise.
But at least both provide RSS feeds so you can work with them a bit.
The whole idea of going to a forum is to create a walled garden.
--
Russel.
===========================================
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
Re: Building Groovy
Posted by Nathan Harvey <na...@gmail.com>.
I have another thread dedicated to the discussion of the forum. Ironically,
my post is marked as "not being accepted by the mailing list" despite there
being replies, but now my follow up posts aren't showing up, so I don't know
if the discussion can continue there. Here is the thread:
http://groovy.329449.n5.nabble.com/Start-a-forum-using-Discourse-tp5742677.html
- would you mind posting on there and telling me what the last post is?
Thanks.
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Building Groovy
Posted by Jochen Theodorou <bl...@gmx.org>.
On 21.12.2017 01:48, Nathan Harvey wrote:
> Although I think this discussion is getting off topic, I'll go ahead and
> chime in myself. I would once again remind people that a strong open source
> community is built on public communications. Mailing lists are old, they are
> fickle, they are annoying, and the list goes on. If Groovy wants to remain
> relevant, it needs to stay up to date, and it needs a well supported and
> advertised forum. Unfortunately the concept of a mailing list is deeply
> entrenched in Apache's requirements, which holds the community back. In
> truth, I don't know if that is possible to fix.
There is no Apache requirement to have a user list mailing list at all.
Only the developers/contributors decisions, discussions and votes have
to be present on the mailing list.
bye Jochen
Re: Building Groovy
Posted by Nathan Harvey <na...@gmail.com>.
Although I think this discussion is getting off topic, I'll go ahead and
chime in myself. I would once again remind people that a strong open source
community is built on public communications. Mailing lists are old, they are
fickle, they are annoying, and the list goes on. If Groovy wants to remain
relevant, it needs to stay up to date, and it needs a well supported and
advertised forum. Unfortunately the concept of a mailing list is deeply
entrenched in Apache's requirements, which holds the community back. In
truth, I don't know if that is possible to fix.
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Building Groovy
Posted by MG <mg...@arscreat.com>.
On 19.12.2017 18:23, Paul King wrote:
> I agree with earlier comments in particular from Jochen and Cédric. I
> also suspect that JDK 9 issues may force us down the indy only path at
> some point not too far away and I think we just have to keep
> optimising the common cases in the meantime using some benchmarking
> tests perhaps to guide efforts - just hard to find the time to tackle
> that right now.
10 cent time: With regards to the problem of development resources, have
you tried / considered gathering money through crowdfunding to pay
someone to speed up important development goals ? I think I read a post
by you that touched on the topic of being a paid Groovy developer, and I
am not suggesting someone quit his day job to do this. Funding would
most likely be too unsteady to do that. But if someone already had a
software company with some employees, he could see this as one project
among others, on which one developer could work for some time. And it
woud allow companies who use Groovy to expedit development without
committing too much...
Cheers,
mg
Re: Building Groovy
Posted by Paul King <pa...@asert.com.au>.
On Tue, Dec 19, 2017 at 11:21 AM, MG <mg...@arscreat.com> wrote:
> Hmmm, I don't know if Paul has some comeback, but to me you make a very
> convincing point...
>
I agree with earlier comments in particular from Jochen and Cédric. I also
suspect that JDK 9 issues may force us down the indy only path at some
point not too far away and I think we just have to keep optimising the
common cases in the meantime using some benchmarking tests perhaps to guide
efforts - just hard to find the time to tackle that right now.
Cheers, Paul.
> In that case the best way forward to me seems to be to
> 1) Ask non-@CompileStatic Groovy users who can afford the time to switch
> to the invoke dynamic variety of the Groovy jars and report back on
> performance issues (tests that run much slower, etc)
> 2) Add a clearly visible message to the Groovy distribution download
> section, Maven/etc URL spots that Groovy 3.0 will be invoke dynamic only,
> and again ask for people to use indy now & give feedback if code seems to
> be unusally slow
> 3) Start a competition who can come up with the most unexpectedly worst
> performing piece of Groovy indy code... ;-)
> (To be quite honest, I am wondering myself how invoke dynamic can be
> slower than the older, homebrewn approach, even if that is highly optimized
> - it seems to me like it should be a bit like a software renderer going up
> against a GPU...)
>
> Cheers,
> mg
>
>
>
> On 18.12.2017 15:54, Jochen Theodorou wrote:
>
>> On 18.12.2017 01:01, MG wrote:
>>
>>> Just came across this as an example where using Groovy 2.4.6
>>> invokedynamic seems to have been much slower than the older callsite
>>> caching mechanism: https://www.linkedin.com/pulse
>>> /how-make-groovy-fast-java-david-e-jones (https://dzone.com/articles/ho
>>> w-to-make-groovy-as-fast-as-java)
>>>
>>
>> It is a chicken-egg problem. We still need to optimize indy in some
>> areas. But this does not happen if no users care to give detailed reports
>> which we can base optimizations on. They on the other hand simply switch to
>> static compilation or old callsite caching then. So in the end there is no
>> optimization, because optimizations tend to inflate and complicate code.
>>
>> And for the old callsite caching there is another part... I highly doubt
>> it is still well working with JDK9. Worse, I do not see how this can be
>> made work efficiently under JDK9. The preferred way in JDK9 is
>> invokedynamic after all. And while they (JDK developers) tend to increase
>> the capabilities of invokedynamic, it is the opposite story for reflection
>> (deep reflection, callsite sensitive rights made even worse through
>> modules, ...)
>>
>> So frankly I do not see much of a future for the old callsite caching
>>
>> bye Jochen
>>
>>
>
Re: Building Groovy
Posted by MG <mg...@arscreat.com>.
Hmmm, I don't know if Paul has some comeback, but to me you make a very
convincing point...
In that case the best way forward to me seems to be to
1) Ask non-@CompileStatic Groovy users who can afford the time to switch
to the invoke dynamic variety of the Groovy jars and report back on
performance issues (tests that run much slower, etc)
2) Add a clearly visible message to the Groovy distribution download
section, Maven/etc URL spots that Groovy 3.0 will be invoke dynamic
only, and again ask for people to use indy now & give feedback if code
seems to be unusally slow
3) Start a competition who can come up with the most unexpectedly worst
performing piece of Groovy indy code... ;-)
(To be quite honest, I am wondering myself how invoke dynamic can be
slower than the older, homebrewn approach, even if that is highly
optimized - it seems to me like it should be a bit like a software
renderer going up against a GPU...)
Cheers,
mg
On 18.12.2017 15:54, Jochen Theodorou wrote:
> On 18.12.2017 01:01, MG wrote:
>> Just came across this as an example where using Groovy 2.4.6
>> invokedynamic seems to have been much slower than the older callsite
>> caching mechanism:
>> https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones
>> (https://dzone.com/articles/how-to-make-groovy-as-fast-as-java)
>
> It is a chicken-egg problem. We still need to optimize indy in some
> areas. But this does not happen if no users care to give detailed
> reports which we can base optimizations on. They on the other hand
> simply switch to static compilation or old callsite caching then. So
> in the end there is no optimization, because optimizations tend to
> inflate and complicate code.
>
> And for the old callsite caching there is another part... I highly
> doubt it is still well working with JDK9. Worse, I do not see how this
> can be made work efficiently under JDK9. The preferred way in JDK9 is
> invokedynamic after all. And while they (JDK developers) tend to
> increase the capabilities of invokedynamic, it is the opposite story
> for reflection (deep reflection, callsite sensitive rights made even
> worse through modules, ...)
>
> So frankly I do not see much of a future for the old callsite caching
>
> bye Jochen
>
Re: Building Groovy
Posted by Jochen Theodorou <bl...@gmx.org>.
On 18.12.2017 01:01, MG wrote:
> Just came across this as an example where using Groovy 2.4.6
> invokedynamic seems to have been much slower than the older callsite
> caching mechanism:
> https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones
> (https://dzone.com/articles/how-to-make-groovy-as-fast-as-java)
It is a chicken-egg problem. We still need to optimize indy in some
areas. But this does not happen if no users care to give detailed
reports which we can base optimizations on. They on the other hand
simply switch to static compilation or old callsite caching then. So in
the end there is no optimization, because optimizations tend to inflate
and complicate code.
And for the old callsite caching there is another part... I highly doubt
it is still well working with JDK9. Worse, I do not see how this can be
made work efficiently under JDK9. The preferred way in JDK9 is
invokedynamic after all. And while they (JDK developers) tend to
increase the capabilities of invokedynamic, it is the opposite story for
reflection (deep reflection, callsite sensitive rights made even worse
through modules, ...)
So frankly I do not see much of a future for the old callsite caching
bye Jochen
Re: Building Groovy
Posted by MG <mg...@arscreat.com>.
Just came across this as an example where using Groovy 2.4.6
invokedynamic seems to have been much slower than the older callsite
caching mechanism:
https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones
(https://dzone.com/articles/how-to-make-groovy-as-fast-as-java)
Quote:
"While Groovy has performance options that allow you to keep your code
dynamically typed I never had good results with them. For Moqui
Framework using the Indy compiler and runtime (for Java invokedynamic)
actually made it significantly slower!
The best option for code that needs to run fast is the @CompileStatic
annotation. When you apply this annotation you can't use Groovy features
that depend on dynamic typing, but fortunately most of the more useful
features still work just fine."
I can totally understand the pull to get rid of large, old code parts -
but if this holds for more projects, I expect it will not go down well
with (dynamic) Groovy users...
mg
On 21.11.2017 17:38, Jochen Theodorou wrote:
>
>
> Am 21.11.2017 um 08:28 schrieb Paul King:
>> The "double" build is because of indy vs non-indy (one wipes out the
>> other) because of some assumptions that keep other parts of the build
>> simple. Could no doubt be streamlined given some TLC.
>>
>> Last I checked there were different performance characteristics
>> between indy/non-indy. We haven't gotten around to working out the
>> best path forward yet that will give us one set of jars without
>> losing performance in some scenarios. Again, just needs some time
>> dedicated to it.
>
> I don't see the old callsite caching still working properly in a Java9
> world, so it is time to cut loose
>
> bye Jochen
>
Re: Building Groovy
Posted by MG <mg...@arscreat.com>.
I also agree.
The one argument I see for a fat groovy-all, is that it lowers the
hurdle of trying Groovy in your project, if you are in a (e.g. secure)
environment where you cannot use Maven/Gradle to pull in all
dependencies from the internet.
On 22.11.2017 20:22, Leonard Brünings wrote:
> I agree with Cédric, that is also what I suggested before.
>
> With maven/gradle the usage of groovy-all is currently done out of
> convenience.
>
> I think most projects would work just as well, if groovy-all would be
> turned into an
> empty jar that just depends on the other jars.
>
> Am 22.11.2017 um 19:41 schrieb Jochen Theodorou:
>> Of course you arr right, I am more worried about the migration path
>> in combination with the final result.
>>
>> On 22.11.2017 14:30, Cédric Champeau wrote:
>>> Said differently, if you depend on `groovy-all`, it will
>>> _effectively_ bring groovy, groovy-json, groovy-xml, groovy-...
>>>
>>> All of those can be proper modules (as long as we fix the split
>>> packages). Then if someone else only brings in `groovy` +
>>> `groovy-json`, there's no conflict.
>>>
>>> 2017-11-22 14:29 GMT+01:00 Cédric Champeau
>>> <cedric.champeau@gmail.com <ma...@gmail.com>>:
>>>
>>> That's precisely what I'm saying: we don't need a fat jar. We
>>> need a
>>> _module_ (Maven/Gradle sense of a module), which brings in the jars
>>> of the individual modules (JPMS sense). So there's no such think as
>>> a fat jar anymore, we don't need it.
>>>
>>> 2017-11-22 14:26 GMT+01:00 Jochen Theodorou <blackdrag@gmx.org
>>> <ma...@gmx.org>>:
>>>
>>>
>>>
>>> Am 22.11.2017 um 11:47 schrieb Cédric Champeau:
>>>
>>> What is the advantage of providing a fat jar, if you can
>>> have a "virtual" dependency, groovy-all, which brings all
>>> the others in? There used to be a difference, but now it's
>>> not that clear.
>>>
>>>
>>> How are you going to express dependencies with automatic
>>> modules? They are automatic, because they lack the
>>> information a
>>> proper module provides and part of that information is the
>>> dependencies afaik. JPMS != maven.
>>>
>>> If you want groovy-all to bring in all the dependencies, then
>>> basically it is an almost empty jar with dependencies and the
>>> dependencies are the real modules. the fat-jar itself cannot
>>> provide any packages those dependencies to provide, otherwise
>>> you have conflicts. The empty groovy-all-approach is something
>>> we could go for in maven too of course. But its is not a fatjar
>>> then ;)
>>>
>>> bye Jochen
>>>
>>>
>>>
>>
>
>
Re: Building Groovy
Posted by MG <mg...@arscreat.com>.
I did download the distribution a few years back, but still added
groovy-all to my project, since it is simply more convenient and
groovy-all sounds like it is the thing you want.
If Groovy is just something you are giving a shot, and you have a lot of
things to evaluate, you naturally want to spend as little time as
possible setting things up / fiddle around with dependencies.
On 22.11.2017 21:58, Paul King wrote:
> The advantage with the fat jar is the convenience of being able to run
> Groovy without a dependency management system (Gradle/Maven). Java
> -jar with just the groovy-all jar is going to get you a long way. Then
> again, I bet most people who aren't using Gradle/Maven probably just
> download the distribution. So I see the groovy-all jar as a nice to
> have but not necessarily essential.
>
> Cheers, Paul.
>
> On Thu, Nov 23, 2017 at 5:22 AM, Leonard Brünings
> <groovy-dev@bruenings-it.net <ma...@bruenings-it.net>> wrote:
>
> I agree with Cédric, that is also what I suggested before.
>
> With maven/gradle the usage of groovy-all is currently done out of
> convenience.
>
> I think most projects would work just as well, if groovy-all would
> be turned into an
> empty jar that just depends on the other jars.
>
>
> Am 22.11.2017 um 19:41 schrieb Jochen Theodorou:
>
> Of course you arr right, I am more worried about the migration
> path in combination with the final result.
>
> On 22.11.2017 14:30, Cédric Champeau wrote:
>
> Said differently, if you depend on `groovy-all`, it will
> _effectively_ bring groovy, groovy-json, groovy-xml,
> groovy-...
>
> All of those can be proper modules (as long as we fix the
> split packages). Then if someone else only brings in
> `groovy` + `groovy-json`, there's no conflict.
>
> 2017-11-22 14:29 GMT+01:00 Cédric Champeau
> <cedric.champeau@gmail.com
> <ma...@gmail.com>
> <mailto:cedric.champeau@gmail.com
> <ma...@gmail.com>>>:
>
> That's precisely what I'm saying: we don't need a fat
> jar. We need a
> _module_ (Maven/Gradle sense of a module), which
> brings in the jars
> of the individual modules (JPMS sense). So there's no
> such think as
> a fat jar anymore, we don't need it.
>
> 2017-11-22 14:26 GMT+01:00 Jochen Theodorou
> <blackdrag@gmx.org <ma...@gmx.org>
> <mailto:blackdrag@gmx.org <ma...@gmx.org>>>:
>
>
>
> Am 22.11.2017 um 11:47 schrieb Cédric Champeau:
>
> What is the advantage of providing a fat jar,
> if you can
> have a "virtual" dependency, groovy-all, which
> brings all
> the others in? There used to be a difference,
> but now it's
> not that clear.
>
>
> How are you going to express dependencies with
> automatic
> modules? They are automatic, because they lack the
> information a
> proper module provides and part of that
> information is the
> dependencies afaik. JPMS != maven.
>
> If you want groovy-all to bring in all the
> dependencies, then
> basically it is an almost empty jar with
> dependencies and the
> dependencies are the real modules. the fat-jar
> itself cannot
> provide any packages those dependencies to
> provide, otherwise
> you have conflicts. The empty groovy-all-approach
> is something
> we could go for in maven too of course. But its is
> not a fatjar
> then ;)
>
> bye Jochen
>
>
>
>
>
>
Re: Building Groovy
Posted by Paul King <pa...@asert.com.au>.
The issue we sometimes get with names like "standalone" (and even "all") is
that sometimes folks assume that means with all optional dependencies
embedded like ivy, commons-cli, junit etc. I am not saying that
"standalone" is any worse than "all", just a point to keep in mind when
picking names ...
Cheers, Paul.
On Thu, Nov 23, 2017 at 8:53 AM, MG <mg...@arscreat.com> wrote:
> I like groovy-standalone.jar as a name (clearer than "all").
> Alas changing names breaks all internet guides/posts/etc preceeding the
> name change, so one has to be careful with things like this...
>
>
> On 22.11.2017 23:33, Leonard Brünings wrote:
>
> If you are doing that then most likely you won't be using the module path
> either, so we could have groovy-standalone.jar,
> with a Automatic-Module-Name of "dont.use.this.jar.for.module.path" to
> make it really obvious on what the proper usage is.
>
> Am 22.11.2017 um 21:58 schrieb Paul King:
>
> The advantage with the fat jar is the convenience of being able to run
> Groovy without a dependency management system (Gradle/Maven). Java -jar
> with just the groovy-all jar is going to get you a long way. Then again, I
> bet most people who aren't using Gradle/Maven probably just download the
> distribution. So I see the groovy-all jar as a nice to have but not
> necessarily essential.
>
> Cheers, Paul.
>
> On Thu, Nov 23, 2017 at 5:22 AM, Leonard Brünings <
> groovy-dev@bruenings-it.net> wrote:
>
>> I agree with Cédric, that is also what I suggested before.
>>
>> With maven/gradle the usage of groovy-all is currently done out of
>> convenience.
>>
>> I think most projects would work just as well, if groovy-all would be
>> turned into an
>> empty jar that just depends on the other jars.
>>
>>
>> Am 22.11.2017 um 19:41 schrieb Jochen Theodorou:
>>
>>> Of course you arr right, I am more worried about the migration path in
>>> combination with the final result.
>>>
>>> On 22.11.2017 14:30, Cédric Champeau wrote:
>>>
>>>> Said differently, if you depend on `groovy-all`, it will _effectively_
>>>> bring groovy, groovy-json, groovy-xml, groovy-...
>>>>
>>>> All of those can be proper modules (as long as we fix the split
>>>> packages). Then if someone else only brings in `groovy` + `groovy-json`,
>>>> there's no conflict.
>>>>
>>>> 2017-11-22 14:29 GMT+01:00 Cédric Champeau <cedric.champeau@gmail.com
>>>> <ma...@gmail.com>>:
>>>>
>>>> That's precisely what I'm saying: we don't need a fat jar. We need a
>>>> _module_ (Maven/Gradle sense of a module), which brings in the jars
>>>> of the individual modules (JPMS sense). So there's no such think as
>>>> a fat jar anymore, we don't need it.
>>>>
>>>> 2017-11-22 14:26 GMT+01:00 Jochen Theodorou <blackdrag@gmx.org
>>>> <ma...@gmx.org>>:
>>>>
>>>>
>>>>
>>>> Am 22.11.2017 um 11:47 schrieb Cédric Champeau:
>>>>
>>>> What is the advantage of providing a fat jar, if you can
>>>> have a "virtual" dependency, groovy-all, which brings all
>>>> the others in? There used to be a difference, but now it's
>>>> not that clear.
>>>>
>>>>
>>>> How are you going to express dependencies with automatic
>>>> modules? They are automatic, because they lack the information a
>>>> proper module provides and part of that information is the
>>>> dependencies afaik. JPMS != maven.
>>>>
>>>> If you want groovy-all to bring in all the dependencies, then
>>>> basically it is an almost empty jar with dependencies and the
>>>> dependencies are the real modules. the fat-jar itself cannot
>>>> provide any packages those dependencies to provide, otherwise
>>>> you have conflicts. The empty groovy-all-approach is something
>>>> we could go for in maven too of course. But its is not a fatjar
>>>> then ;)
>>>>
>>>> bye Jochen
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
Re: Building Groovy
Posted by MG <mg...@arscreat.com>.
I like groovy-standalone.jar as a name (clearer than "all").
Alas changing names breaks all internet guides/posts/etc preceeding the
name change, so one has to be careful with things like this...
On 22.11.2017 23:33, Leonard Brünings wrote:
>
> If you are doing that then most likely you won't be using the module
> path either, so we could have groovy-standalone.jar,
> with a Automatic-Module-Name of "dont.use.this.jar.for.module.path" to
> make it really obvious on what the proper usage is.
>
>
> Am 22.11.2017 um 21:58 schrieb Paul King:
>> The advantage with the fat jar is the convenience of being able to
>> run Groovy without a dependency management system (Gradle/Maven).
>> Java -jar with just the groovy-all jar is going to get you a long
>> way. Then again, I bet most people who aren't using Gradle/Maven
>> probably just download the distribution. So I see the groovy-all jar
>> as a nice to have but not necessarily essential.
>>
>> Cheers, Paul.
>>
>> On Thu, Nov 23, 2017 at 5:22 AM, Leonard Brünings
>> <groovy-dev@bruenings-it.net <ma...@bruenings-it.net>> wrote:
>>
>> I agree with Cédric, that is also what I suggested before.
>>
>> With maven/gradle the usage of groovy-all is currently done out
>> of convenience.
>>
>> I think most projects would work just as well, if groovy-all
>> would be turned into an
>> empty jar that just depends on the other jars.
>>
>>
>> Am 22.11.2017 um 19:41 schrieb Jochen Theodorou:
>>
>> Of course you arr right, I am more worried about the
>> migration path in combination with the final result.
>>
>> On 22.11.2017 14:30, Cédric Champeau wrote:
>>
>> Said differently, if you depend on `groovy-all`, it will
>> _effectively_ bring groovy, groovy-json, groovy-xml,
>> groovy-...
>>
>> All of those can be proper modules (as long as we fix the
>> split packages). Then if someone else only brings in
>> `groovy` + `groovy-json`, there's no conflict.
>>
>> 2017-11-22 14:29 GMT+01:00 Cédric Champeau
>> <cedric.champeau@gmail.com
>> <ma...@gmail.com>
>> <mailto:cedric.champeau@gmail.com
>> <ma...@gmail.com>>>:
>>
>> That's precisely what I'm saying: we don't need a fat
>> jar. We need a
>> _module_ (Maven/Gradle sense of a module), which
>> brings in the jars
>> of the individual modules (JPMS sense). So there's no
>> such think as
>> a fat jar anymore, we don't need it.
>>
>> 2017-11-22 14:26 GMT+01:00 Jochen Theodorou
>> <blackdrag@gmx.org <ma...@gmx.org>
>> <mailto:blackdrag@gmx.org <ma...@gmx.org>>>:
>>
>>
>>
>> Am 22.11.2017 um 11:47 schrieb Cédric Champeau:
>>
>> What is the advantage of providing a fat jar,
>> if you can
>> have a "virtual" dependency, groovy-all,
>> which brings all
>> the others in? There used to be a difference,
>> but now it's
>> not that clear.
>>
>>
>> How are you going to express dependencies with
>> automatic
>> modules? They are automatic, because they lack
>> the information a
>> proper module provides and part of that
>> information is the
>> dependencies afaik. JPMS != maven.
>>
>> If you want groovy-all to bring in all the
>> dependencies, then
>> basically it is an almost empty jar with
>> dependencies and the
>> dependencies are the real modules. the fat-jar
>> itself cannot
>> provide any packages those dependencies to
>> provide, otherwise
>> you have conflicts. The empty groovy-all-approach
>> is something
>> we could go for in maven too of course. But its
>> is not a fatjar
>> then ;)
>>
>> bye Jochen
>>
>>
>>
>>
>>
>>
>
Re: Building Groovy
Posted by Leonard Brünings <gr...@bruenings-it.net>.
If you are doing that then most likely you won't be using the module
path either, so we could have groovy-standalone.jar,
with a Automatic-Module-Name of "dont.use.this.jar.for.module.path" to
make it really obvious on what the proper usage is.
Am 22.11.2017 um 21:58 schrieb Paul King:
> The advantage with the fat jar is the convenience of being able to run
> Groovy without a dependency management system (Gradle/Maven). Java
> -jar with just the groovy-all jar is going to get you a long way. Then
> again, I bet most people who aren't using Gradle/Maven probably just
> download the distribution. So I see the groovy-all jar as a nice to
> have but not necessarily essential.
>
> Cheers, Paul.
>
> On Thu, Nov 23, 2017 at 5:22 AM, Leonard Brünings
> <groovy-dev@bruenings-it.net <ma...@bruenings-it.net>> wrote:
>
> I agree with Cédric, that is also what I suggested before.
>
> With maven/gradle the usage of groovy-all is currently done out of
> convenience.
>
> I think most projects would work just as well, if groovy-all would
> be turned into an
> empty jar that just depends on the other jars.
>
>
> Am 22.11.2017 um 19:41 schrieb Jochen Theodorou:
>
> Of course you arr right, I am more worried about the migration
> path in combination with the final result.
>
> On 22.11.2017 14:30, Cédric Champeau wrote:
>
> Said differently, if you depend on `groovy-all`, it will
> _effectively_ bring groovy, groovy-json, groovy-xml,
> groovy-...
>
> All of those can be proper modules (as long as we fix the
> split packages). Then if someone else only brings in
> `groovy` + `groovy-json`, there's no conflict.
>
> 2017-11-22 14:29 GMT+01:00 Cédric Champeau
> <cedric.champeau@gmail.com
> <ma...@gmail.com>
> <mailto:cedric.champeau@gmail.com
> <ma...@gmail.com>>>:
>
> That's precisely what I'm saying: we don't need a fat
> jar. We need a
> _module_ (Maven/Gradle sense of a module), which
> brings in the jars
> of the individual modules (JPMS sense). So there's no
> such think as
> a fat jar anymore, we don't need it.
>
> 2017-11-22 14:26 GMT+01:00 Jochen Theodorou
> <blackdrag@gmx.org <ma...@gmx.org>
> <mailto:blackdrag@gmx.org <ma...@gmx.org>>>:
>
>
>
> Am 22.11.2017 um 11:47 schrieb Cédric Champeau:
>
> What is the advantage of providing a fat jar,
> if you can
> have a "virtual" dependency, groovy-all, which
> brings all
> the others in? There used to be a difference,
> but now it's
> not that clear.
>
>
> How are you going to express dependencies with
> automatic
> modules? They are automatic, because they lack the
> information a
> proper module provides and part of that
> information is the
> dependencies afaik. JPMS != maven.
>
> If you want groovy-all to bring in all the
> dependencies, then
> basically it is an almost empty jar with
> dependencies and the
> dependencies are the real modules. the fat-jar
> itself cannot
> provide any packages those dependencies to
> provide, otherwise
> you have conflicts. The empty groovy-all-approach
> is something
> we could go for in maven too of course. But its is
> not a fatjar
> then ;)
>
> bye Jochen
>
>
>
>
>
>
Re: Building Groovy
Posted by Paul King <pa...@asert.com.au>.
The advantage with the fat jar is the convenience of being able to run
Groovy without a dependency management system (Gradle/Maven). Java -jar
with just the groovy-all jar is going to get you a long way. Then again, I
bet most people who aren't using Gradle/Maven probably just download the
distribution. So I see the groovy-all jar as a nice to have but not
necessarily essential.
Cheers, Paul.
On Thu, Nov 23, 2017 at 5:22 AM, Leonard Brünings <
groovy-dev@bruenings-it.net> wrote:
> I agree with Cédric, that is also what I suggested before.
>
> With maven/gradle the usage of groovy-all is currently done out of
> convenience.
>
> I think most projects would work just as well, if groovy-all would be
> turned into an
> empty jar that just depends on the other jars.
>
>
> Am 22.11.2017 um 19:41 schrieb Jochen Theodorou:
>
>> Of course you arr right, I am more worried about the migration path in
>> combination with the final result.
>>
>> On 22.11.2017 14:30, Cédric Champeau wrote:
>>
>>> Said differently, if you depend on `groovy-all`, it will _effectively_
>>> bring groovy, groovy-json, groovy-xml, groovy-...
>>>
>>> All of those can be proper modules (as long as we fix the split
>>> packages). Then if someone else only brings in `groovy` + `groovy-json`,
>>> there's no conflict.
>>>
>>> 2017-11-22 14:29 GMT+01:00 Cédric Champeau <cedric.champeau@gmail.com
>>> <ma...@gmail.com>>:
>>>
>>> That's precisely what I'm saying: we don't need a fat jar. We need a
>>> _module_ (Maven/Gradle sense of a module), which brings in the jars
>>> of the individual modules (JPMS sense). So there's no such think as
>>> a fat jar anymore, we don't need it.
>>>
>>> 2017-11-22 14:26 GMT+01:00 Jochen Theodorou <blackdrag@gmx.org
>>> <ma...@gmx.org>>:
>>>
>>>
>>>
>>> Am 22.11.2017 um 11:47 schrieb Cédric Champeau:
>>>
>>> What is the advantage of providing a fat jar, if you can
>>> have a "virtual" dependency, groovy-all, which brings all
>>> the others in? There used to be a difference, but now it's
>>> not that clear.
>>>
>>>
>>> How are you going to express dependencies with automatic
>>> modules? They are automatic, because they lack the information a
>>> proper module provides and part of that information is the
>>> dependencies afaik. JPMS != maven.
>>>
>>> If you want groovy-all to bring in all the dependencies, then
>>> basically it is an almost empty jar with dependencies and the
>>> dependencies are the real modules. the fat-jar itself cannot
>>> provide any packages those dependencies to provide, otherwise
>>> you have conflicts. The empty groovy-all-approach is something
>>> we could go for in maven too of course. But its is not a fatjar
>>> then ;)
>>>
>>> bye Jochen
>>>
>>>
>>>
>>>
>>
>
Re: Building Groovy
Posted by Leonard Brünings <gr...@bruenings-it.net>.
I agree with Cédric, that is also what I suggested before.
With maven/gradle the usage of groovy-all is currently done out of
convenience.
I think most projects would work just as well, if groovy-all would be
turned into an
empty jar that just depends on the other jars.
Am 22.11.2017 um 19:41 schrieb Jochen Theodorou:
> Of course you arr right, I am more worried about the migration path in
> combination with the final result.
>
> On 22.11.2017 14:30, Cédric Champeau wrote:
>> Said differently, if you depend on `groovy-all`, it will
>> _effectively_ bring groovy, groovy-json, groovy-xml, groovy-...
>>
>> All of those can be proper modules (as long as we fix the split
>> packages). Then if someone else only brings in `groovy` +
>> `groovy-json`, there's no conflict.
>>
>> 2017-11-22 14:29 GMT+01:00 Cédric Champeau <cedric.champeau@gmail.com
>> <ma...@gmail.com>>:
>>
>> That's precisely what I'm saying: we don't need a fat jar. We need a
>> _module_ (Maven/Gradle sense of a module), which brings in the jars
>> of the individual modules (JPMS sense). So there's no such think as
>> a fat jar anymore, we don't need it.
>>
>> 2017-11-22 14:26 GMT+01:00 Jochen Theodorou <blackdrag@gmx.org
>> <ma...@gmx.org>>:
>>
>>
>>
>> Am 22.11.2017 um 11:47 schrieb Cédric Champeau:
>>
>> What is the advantage of providing a fat jar, if you can
>> have a "virtual" dependency, groovy-all, which brings all
>> the others in? There used to be a difference, but now it's
>> not that clear.
>>
>>
>> How are you going to express dependencies with automatic
>> modules? They are automatic, because they lack the information a
>> proper module provides and part of that information is the
>> dependencies afaik. JPMS != maven.
>>
>> If you want groovy-all to bring in all the dependencies, then
>> basically it is an almost empty jar with dependencies and the
>> dependencies are the real modules. the fat-jar itself cannot
>> provide any packages those dependencies to provide, otherwise
>> you have conflicts. The empty groovy-all-approach is something
>> we could go for in maven too of course. But its is not a fatjar
>> then ;)
>>
>> bye Jochen
>>
>>
>>
>
Re: Building Groovy
Posted by Jochen Theodorou <bl...@gmx.org>.
Of course you arr right, I am more worried about the migration path in
combination with the final result.
On 22.11.2017 14:30, Cédric Champeau wrote:
> Said differently, if you depend on `groovy-all`, it will _effectively_
> bring groovy, groovy-json, groovy-xml, groovy-...
>
> All of those can be proper modules (as long as we fix the split
> packages). Then if someone else only brings in `groovy` + `groovy-json`,
> there's no conflict.
>
> 2017-11-22 14:29 GMT+01:00 Cédric Champeau <cedric.champeau@gmail.com
> <ma...@gmail.com>>:
>
> That's precisely what I'm saying: we don't need a fat jar. We need a
> _module_ (Maven/Gradle sense of a module), which brings in the jars
> of the individual modules (JPMS sense). So there's no such think as
> a fat jar anymore, we don't need it.
>
> 2017-11-22 14:26 GMT+01:00 Jochen Theodorou <blackdrag@gmx.org
> <ma...@gmx.org>>:
>
>
>
> Am 22.11.2017 um 11:47 schrieb Cédric Champeau:
>
> What is the advantage of providing a fat jar, if you can
> have a "virtual" dependency, groovy-all, which brings all
> the others in? There used to be a difference, but now it's
> not that clear.
>
>
> How are you going to express dependencies with automatic
> modules? They are automatic, because they lack the information a
> proper module provides and part of that information is the
> dependencies afaik. JPMS != maven.
>
> If you want groovy-all to bring in all the dependencies, then
> basically it is an almost empty jar with dependencies and the
> dependencies are the real modules. the fat-jar itself cannot
> provide any packages those dependencies to provide, otherwise
> you have conflicts. The empty groovy-all-approach is something
> we could go for in maven too of course. But its is not a fatjar
> then ;)
>
> bye Jochen
>
>
>
Re: Building Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
Said differently, if you depend on `groovy-all`, it will _effectively_
bring groovy, groovy-json, groovy-xml, groovy-...
All of those can be proper modules (as long as we fix the split packages).
Then if someone else only brings in `groovy` + `groovy-json`, there's no
conflict.
2017-11-22 14:29 GMT+01:00 Cédric Champeau <ce...@gmail.com>:
> That's precisely what I'm saying: we don't need a fat jar. We need a
> _module_ (Maven/Gradle sense of a module), which brings in the jars of the
> individual modules (JPMS sense). So there's no such think as a fat jar
> anymore, we don't need it.
>
> 2017-11-22 14:26 GMT+01:00 Jochen Theodorou <bl...@gmx.org>:
>
>>
>>
>> Am 22.11.2017 um 11:47 schrieb Cédric Champeau:
>>
>>> What is the advantage of providing a fat jar, if you can have a
>>> "virtual" dependency, groovy-all, which brings all the others in? There
>>> used to be a difference, but now it's not that clear.
>>>
>>
>> How are you going to express dependencies with automatic modules? They
>> are automatic, because they lack the information a proper module provides
>> and part of that information is the dependencies afaik. JPMS != maven.
>>
>> If you want groovy-all to bring in all the dependencies, then basically
>> it is an almost empty jar with dependencies and the dependencies are the
>> real modules. the fat-jar itself cannot provide any packages those
>> dependencies to provide, otherwise you have conflicts. The empty
>> groovy-all-approach is something we could go for in maven too of course.
>> But its is not a fatjar then ;)
>>
>> bye Jochen
>>
>
>
Re: Building Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
That's precisely what I'm saying: we don't need a fat jar. We need a
_module_ (Maven/Gradle sense of a module), which brings in the jars of the
individual modules (JPMS sense). So there's no such think as a fat jar
anymore, we don't need it.
2017-11-22 14:26 GMT+01:00 Jochen Theodorou <bl...@gmx.org>:
>
>
> Am 22.11.2017 um 11:47 schrieb Cédric Champeau:
>
>> What is the advantage of providing a fat jar, if you can have a "virtual"
>> dependency, groovy-all, which brings all the others in? There used to be a
>> difference, but now it's not that clear.
>>
>
> How are you going to express dependencies with automatic modules? They are
> automatic, because they lack the information a proper module provides and
> part of that information is the dependencies afaik. JPMS != maven.
>
> If you want groovy-all to bring in all the dependencies, then basically it
> is an almost empty jar with dependencies and the dependencies are the real
> modules. the fat-jar itself cannot provide any packages those dependencies
> to provide, otherwise you have conflicts. The empty groovy-all-approach is
> something we could go for in maven too of course. But its is not a fatjar
> then ;)
>
> bye Jochen
>
Re: Building Groovy
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 22.11.2017 um 11:47 schrieb Cédric Champeau:
> What is the advantage of providing a fat jar, if you can have a
> "virtual" dependency, groovy-all, which brings all the others in? There
> used to be a difference, but now it's not that clear.
How are you going to express dependencies with automatic modules? They
are automatic, because they lack the information a proper module
provides and part of that information is the dependencies afaik. JPMS !=
maven.
If you want groovy-all to bring in all the dependencies, then basically
it is an almost empty jar with dependencies and the dependencies are the
real modules. the fat-jar itself cannot provide any packages those
dependencies to provide, otherwise you have conflicts. The empty
groovy-all-approach is something we could go for in maven too of course.
But its is not a fatjar then ;)
bye Jochen
Re: Building Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
What is the advantage of providing a fat jar, if you can have a "virtual"
dependency, groovy-all, which brings all the others in? There used to be a
difference, but now it's not that clear.
2017-11-22 11:45 GMT+01:00 Jochen Theodorou <bl...@gmx.org>:
>
>
> Am 22.11.2017 um 10:09 schrieb Cédric Champeau:
>
>> To me it's very clear that Groovy.next is indy only, so all the
>> discussions we have about module names or call site caching are solved.
>>
>
> for the transition time from Groovy not as module and Groovy as module we
> require a discussion. Not about the indy versions, but about the fatjar.
> Unless my arguments before are good enough and we use different names for
> the fatjar and the proper module jars.
>
> Btw, In my eyes there is zero advantage for Groovy as module. The step is
> only required to not be at disadvantage, or even being ruled out as
> possibility. Of course the bigger required breaking changes may have the
> same effect
>
> bye Jochen
>
Re: Building Groovy
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 22.11.2017 um 10:09 schrieb Cédric Champeau:
> To me it's very clear that Groovy.next is indy only, so all the
> discussions we have about module names or call site caching are solved.
for the transition time from Groovy not as module and Groovy as module
we require a discussion. Not about the indy versions, but about the
fatjar. Unless my arguments before are good enough and we use different
names for the fatjar and the proper module jars.
Btw, In my eyes there is zero advantage for Groovy as module. The step
is only required to not be at disadvantage, or even being ruled out as
possibility. Of course the bigger required breaking changes may have the
same effect
bye Jochen
Re: Building Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
To me it's very clear that Groovy.next is indy only, so all the discussions
we have about module names or call site caching are solved.
2017-11-22 10:06 GMT+01:00 Russel Winder <ru...@winder.org.uk>:
> On Tue, 2017-11-21 at 17:38 +0100, Jochen Theodorou wrote:
> >
> […]
> > I don't see the old callsite caching still working properly in a
> > Java9
> > world, so it is time to cut loose
> >
>
> And now of course people will be using OpendJDK10 ;-)
>
> --
> Russel.
> ===========================================
> Dr Russel Winder t: +44 20 7585 2200
> 41 Buckmaster Road m: +44 7770 465 077
> London SW11 1EN, UK w: www.russel.org.uk
>
Re: Building Groovy
Posted by Russel Winder <ru...@winder.org.uk>.
On Wed, 2017-11-22 at 09:53 +0000, Remi Forax wrote:
> Do you have a problem with those people ? :)
Not at all, but I am unlikely to be one of them as I am doing native
code stuff now. If I was still using JVM, it would be OpenJDK10,
OpenJDK9 is so passè, and OpenJDK8 must be close to retirement by now.
> Rémi
>
>
> On November 22, 2017 10:06:48 AM GMT+01:00, Russel Winder <russel@win
> der.org.uk> wrote:
> > On Tue, 2017-11-21 at 17:38 +0100, Jochen Theodorou wrote:
> > >
> >
> > […]
> > > I don't see the old callsite caching still working properly in a
> > > Java9
> > > world, so it is time to cut loose
> > >
> >
> > And now of course people will be using OpendJDK10 ;-)
>
--
Russel.
===========================================
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
Re: Building Groovy
Posted by Remi Forax <fo...@univ-mlv.fr>.
Do you have a problem with those people ? :)
Rémi
On November 22, 2017 10:06:48 AM GMT+01:00, Russel Winder <ru...@winder.org.uk> wrote:
>On Tue, 2017-11-21 at 17:38 +0100, Jochen Theodorou wrote:
>>
>[…]
>> I don't see the old callsite caching still working properly in a
>> Java9
>> world, so it is time to cut loose
>>
>
>And now of course people will be using OpendJDK10 ;-)
>
>--
>Russel.
>===========================================
>Dr Russel Winder t: +44 20 7585 2200
>41 Buckmaster Road m: +44 7770 465 077
>London SW11 1EN, UK w: www.russel.org.uk
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Building Groovy
Posted by Russel Winder <ru...@winder.org.uk>.
On Tue, 2017-11-21 at 17:38 +0100, Jochen Theodorou wrote:
>
[…]
> I don't see the old callsite caching still working properly in a
> Java9
> world, so it is time to cut loose
>
And now of course people will be using OpendJDK10 ;-)
--
Russel.
===========================================
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
Re: Building Groovy
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 21.11.2017 um 08:28 schrieb Paul King:
> The "double" build is because of indy vs non-indy (one wipes out the
> other) because of some assumptions that keep other parts of the build
> simple. Could no doubt be streamlined given some TLC.
>
> Last I checked there were different performance characteristics between
> indy/non-indy. We haven't gotten around to working out the best path
> forward yet that will give us one set of jars without losing performance
> in some scenarios. Again, just needs some time dedicated to it.
I don't see the old callsite caching still working properly in a Java9
world, so it is time to cut loose
bye Jochen
Re: Building Groovy
Posted by Paul King <pa...@asert.com.au>.
The "double" build is because of indy vs non-indy (one wipes out the other)
because of some assumptions that keep other parts of the build simple.
Could no doubt be streamlined given some TLC.
Last I checked there were different performance characteristics between
indy/non-indy. We haven't gotten around to working out the best path
forward yet that will give us one set of jars without losing performance in
some scenarios. Again, just needs some time dedicated to it.
Cheers, Paul.
On Tue, Nov 21, 2017 at 12:43 PM, Russel Winder <ru...@winder.org.uk>
wrote:
> Hi,
>
> It seems that building Groovy immediately after building Groovy means
> everything is compiled again. Surely what should be a null build should
> take 0 seconds rather than 5 minutes? (A null build taking 5 minutes
> rather than 0 seconds would, in the native code world, indicate a
> failed build system.)
>
> Also Groovy 3 still seems to be built twice, non-indy and indy. Isn't
> it time to decide and ditch one of the builds to save 3 minutes on the
> build?
>
> --
> Russel.
> ===========================================
> Dr Russel Winder t: +44 20 7585 2200
> 41 Buckmaster Road m: +44 7770 465 077
> London SW11 1EN, UK w: www.russel.org.uk
>