You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Robbie Gemmell <ro...@gmail.com> on 2020/06/16 12:34:51 UTC
[DISCUSS] ErrorProne on [JDK8] Artemis builds
I have come to realise that the newer ErrorProne config for JDK8 added
as part of https://issues.apache.org/jira/browse/ARTEMIS-2109 doesn't
actually work presently, i.e it isn't running. I have prepared a
couple of alternative changes that do get it working again, but they
themselves have issues and have raised a question for me.
One approach was to go back to the older style ErrorProne-specific
compiler approach when running on JDK8. The problem with that one is
it requires downgrading back to ErrorProne 2.3.4 as its the last that
supports that method. So that doesn't seem like a great idea as it
blocks upgrades.
The other continues using the newer style javac plugin approach which
is being used for JDK11+ (and is required for 2.4.0+ generally) but
resolving the issues with the config for JDK8 to get it running there.
The concern with this one is that for the ErrorProne javac plugin to
be registered on JDK8 you must fork the compiler, which happens on
every execution of the maven plugin. This isn't speedy, and due to the
vast numbers of modules in the build this happens _a lot_, so it
really adds up. The forking appears to add nearing a couple of minutes
to the overall build, on top of the couple minutes running ErrorProne
looks to add itself. Between them the resulting build [only, with
skipTests] is about 2.5 times longer on JDK8 with this in place than
it is without ErrorProne in play at all.
Having been through all this, I can't help wondering if it would be
worth setting things up with ErrorProne in a profile, activated if
enabled by a property. That could either be only for JDK8 (where it is
slowest due to all the forks), or for all the JDK versions. It would
still be set to always run in CI for PRs etc in any case. Thoughts?
Robbie
Re: [DISCUSS] ErrorProne on [JDK8] Artemis builds
Posted by Robbie Gemmell <ro...@gmail.com>.
I raised https://github.com/apache/activemq-artemis/pull/3186 to fix
things to work forJDK8, move it to a profile to make it optional on
JDK8, and enable it in CI. Still on by default in JDK11+.
Robbie
On Tue, 16 Jun 2020 at 15:03, Robbie Gemmell <ro...@gmail.com> wrote:
>
> The additional couple minutes slowdown from forking only happens on JDK8, yes.
>
> The comparable couple minutes overhead from running with ErrorProne at
> all happens across the board though. Given the extent I don't
> personally think it's justified for every single build when it's on in
> CI anyway, it seems more suited to enabling on demand.
>
> Robbie
>
> On Tue, 16 Jun 2020 at 13:46, Emmanuel Hugonnet <eh...@redhat.com> wrote:
> >
> > I would deactivate error-prone with JDK 8 and only 'run' it on CI via a proper activated profile.
> >
> > As far as I understand this is not an issue with JDK 11 so we should have it on per default on Java > = 11.
> >
> > Emmanuel
> >
> > Le 16/06/2020 à 14:34, Robbie Gemmell a écrit :
> > > I have come to realise that the newer ErrorProne config for JDK8 added
> > > as part of https://issues.apache.org/jira/browse/ARTEMIS-2109 doesn't
> > > actually work presently, i.e it isn't running. I have prepared a
> > > couple of alternative changes that do get it working again, but they
> > > themselves have issues and have raised a question for me.
> > >
> > > One approach was to go back to the older style ErrorProne-specific
> > > compiler approach when running on JDK8. The problem with that one is
> > > it requires downgrading back to ErrorProne 2.3.4 as its the last that
> > > supports that method. So that doesn't seem like a great idea as it
> > > blocks upgrades.
> > >
> > > The other continues using the newer style javac plugin approach which
> > > is being used for JDK11+ (and is required for 2.4.0+ generally) but
> > > resolving the issues with the config for JDK8 to get it running there.
> > > The concern with this one is that for the ErrorProne javac plugin to
> > > be registered on JDK8 you must fork the compiler, which happens on
> > > every execution of the maven plugin. This isn't speedy, and due to the
> > > vast numbers of modules in the build this happens _a lot_, so it
> > > really adds up. The forking appears to add nearing a couple of minutes
> > > to the overall build, on top of the couple minutes running ErrorProne
> > > looks to add itself. Between them the resulting build [only, with
> > > skipTests] is about 2.5 times longer on JDK8 with this in place than
> > > it is without ErrorProne in play at all.
> > >
> > > Having been through all this, I can't help wondering if it would be
> > > worth setting things up with ErrorProne in a profile, activated if
> > > enabled by a property. That could either be only for JDK8 (where it is
> > > slowest due to all the forks), or for all the JDK versions. It would
> > > still be set to always run in CI for PRs etc in any case. Thoughts?
> > >
> > > Robbie
> > >
> >
Re: [DISCUSS] ErrorProne on [JDK8] Artemis builds
Posted by Robbie Gemmell <ro...@gmail.com>.
The additional couple minutes slowdown from forking only happens on JDK8, yes.
The comparable couple minutes overhead from running with ErrorProne at
all happens across the board though. Given the extent I don't
personally think it's justified for every single build when it's on in
CI anyway, it seems more suited to enabling on demand.
Robbie
On Tue, 16 Jun 2020 at 13:46, Emmanuel Hugonnet <eh...@redhat.com> wrote:
>
> I would deactivate error-prone with JDK 8 and only 'run' it on CI via a proper activated profile.
>
> As far as I understand this is not an issue with JDK 11 so we should have it on per default on Java > = 11.
>
> Emmanuel
>
> Le 16/06/2020 à 14:34, Robbie Gemmell a écrit :
> > I have come to realise that the newer ErrorProne config for JDK8 added
> > as part of https://issues.apache.org/jira/browse/ARTEMIS-2109 doesn't
> > actually work presently, i.e it isn't running. I have prepared a
> > couple of alternative changes that do get it working again, but they
> > themselves have issues and have raised a question for me.
> >
> > One approach was to go back to the older style ErrorProne-specific
> > compiler approach when running on JDK8. The problem with that one is
> > it requires downgrading back to ErrorProne 2.3.4 as its the last that
> > supports that method. So that doesn't seem like a great idea as it
> > blocks upgrades.
> >
> > The other continues using the newer style javac plugin approach which
> > is being used for JDK11+ (and is required for 2.4.0+ generally) but
> > resolving the issues with the config for JDK8 to get it running there.
> > The concern with this one is that for the ErrorProne javac plugin to
> > be registered on JDK8 you must fork the compiler, which happens on
> > every execution of the maven plugin. This isn't speedy, and due to the
> > vast numbers of modules in the build this happens _a lot_, so it
> > really adds up. The forking appears to add nearing a couple of minutes
> > to the overall build, on top of the couple minutes running ErrorProne
> > looks to add itself. Between them the resulting build [only, with
> > skipTests] is about 2.5 times longer on JDK8 with this in place than
> > it is without ErrorProne in play at all.
> >
> > Having been through all this, I can't help wondering if it would be
> > worth setting things up with ErrorProne in a profile, activated if
> > enabled by a property. That could either be only for JDK8 (where it is
> > slowest due to all the forks), or for all the JDK versions. It would
> > still be set to always run in CI for PRs etc in any case. Thoughts?
> >
> > Robbie
> >
>
Re: [DISCUSS] ErrorProne on [JDK8] Artemis builds
Posted by Clebert Suconic <cl...@gmail.com>.
On Tue, Jun 16, 2020 at 8:47 AM Emmanuel Hugonnet <eh...@redhat.com> wrote:
>
> I would deactivate error-prone with JDK 8 and only 'run' it on CI via a proper activated profile.
+1
Re: [DISCUSS] ErrorProne on [JDK8] Artemis builds
Posted by Emmanuel Hugonnet <eh...@redhat.com>.
I would deactivate error-prone with JDK 8 and only 'run' it on CI via a proper activated profile.
As far as I understand this is not an issue with JDK 11 so we should have it on per default on Java > = 11.
Emmanuel
Le 16/06/2020 à 14:34, Robbie Gemmell a écrit :
> I have come to realise that the newer ErrorProne config for JDK8 added
> as part of https://issues.apache.org/jira/browse/ARTEMIS-2109 doesn't
> actually work presently, i.e it isn't running. I have prepared a
> couple of alternative changes that do get it working again, but they
> themselves have issues and have raised a question for me.
>
> One approach was to go back to the older style ErrorProne-specific
> compiler approach when running on JDK8. The problem with that one is
> it requires downgrading back to ErrorProne 2.3.4 as its the last that
> supports that method. So that doesn't seem like a great idea as it
> blocks upgrades.
>
> The other continues using the newer style javac plugin approach which
> is being used for JDK11+ (and is required for 2.4.0+ generally) but
> resolving the issues with the config for JDK8 to get it running there.
> The concern with this one is that for the ErrorProne javac plugin to
> be registered on JDK8 you must fork the compiler, which happens on
> every execution of the maven plugin. This isn't speedy, and due to the
> vast numbers of modules in the build this happens _a lot_, so it
> really adds up. The forking appears to add nearing a couple of minutes
> to the overall build, on top of the couple minutes running ErrorProne
> looks to add itself. Between them the resulting build [only, with
> skipTests] is about 2.5 times longer on JDK8 with this in place than
> it is without ErrorProne in play at all.
>
> Having been through all this, I can't help wondering if it would be
> worth setting things up with ErrorProne in a profile, activated if
> enabled by a property. That could either be only for JDK8 (where it is
> slowest due to all the forks), or for all the JDK versions. It would
> still be set to always run in CI for PRs etc in any case. Thoughts?
>
> Robbie
>