You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2017/12/05 15:23:42 UTC
Java 9 support, Sling 10 release
Hi,
With recent changes to Sling we are very close to having proper Java 9
( thanks Radu and Karl for their effort ).
One thing that is becoming clear is that we won't be able to support
Java 9 without the CLI flag '--add-modules java.se.ee' . That is
because:
- Tika is yet to have a release which removes JAXB usage
- We did not have the time to replace deprecated modules with third
party jars, partly because we would need to do it for all supported
Java versions, which is complicated.
So my proposition, once the latest scripting.core and servlet.resolver
release are out it to start the Sling 10 release process, supporting
Java 9 with the --add-modules java.se.ee flag, and work towards
removing that constraint for Sling 10. We would also run tests with
that, obviously.
Thoughts?
Thanks,
Robert
Re: Java 9 support, Sling 10 release
Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2017-12-05 at 17:23 +0200, Robert Munteanu wrote:
> work towards
> removing that constraint for Sling 10.
That's Sling 11, thanks Karl for noticing.
Robert
Re: Java 9 support, Sling 10 release
Posted by Robert Munteanu <ro...@apache.org>.
On Mon, 2017-12-11 at 22:51 +0200, Robert Munteanu wrote:
> On Wed, 2017-12-06 at 14:16 +0100, Konrad Windszus wrote:
> > > On 6. Dec 2017, at 14:15, Robert Munteanu <ro...@apache.org>
> > > wrote:
> > >
> > > On Wed, 2017-12-06 at 14:02 +0100, Konrad Windszus wrote:
> > > > > The way out would be to either:
> > > > >
> > > > > 1. adjust the exported package lists for Java 8
> > > > > 2. deploy new bundles only for Java 9
> > > > >
> > > > > 1. is a risky proposition, especially since it can affect
> > > > > backwards
> > > > > compatibility
> > > > > 2. requires further work in the provisioning model, and maybe
> > > > > a
> > > > > bad
> > > > > idea to invest in since the feature model is hopefully close
> > > > > to
> > > > > complete.
> > > > >
> > > >
> > > > I would propose not tweak the actual deployment but rather
> > > > leverage
> > > > OSGi execution environments (OSGi Core Spec 3.4). That should
> > > > lead to
> > > > the fact that
> > > > ...
> > > > A bundle can only resolve if the framework is running on a VM
> > > > which
> > > > implements one of the listed
> > > > required execution environments.
> > > > ...
> > >
> > > Does that mean we get bundles that fail to resolve by default on
> > > Java
> > > 8? That would not be good IMO.
> >
> > Yes, exactly.
> > IMHO that should not do any harm (maybe except for some failing
> > healthchecks which need to be adjusted)
>
> I think it's a bad impression at least to have bundles that can't
> resolve at startup. We have no idea what the impact will be for
> consumers and it's tricky to make sure all health checks are done
> right, and presumably anyone using the web console will start looking
> for clues when they see bundles that don't start. We can document it,
> but I am sure not that many people read the documentation :-)
>
> What we can try - not sure if feasible - is to add a run mode named
> 'java9' and activate it from a special bootstrap bundle if we detect
> that Java 9 is used to run Sling. Then in the provisioning model the
> Java 9-specific bundles are attached to this 'java9' runmode, which
> would mean:
>
> - Java 8 is untouched
> - Java 9 no longer requires adding the '--add-modules' flag
>
> Again, note that this is completely untested but just might work.
To get back at this...
I incorporated Tika 1.17 in the Sling starter. I am almost convinced
that my idea from above will not work since we need to inject other
bundles in start level 1 ( javax.annotation is an example ).
So my proposal is the following:
If anyone has the time to do more Java 9 improvements, please say so. I
don't have it right now and also I don't think having unresolved
bundles in Java 9 is a good option.
If no one steps up, I will start the Sling 10 release work on Monday,
hopefully getting everything out in 1 week.
Thanks,
Robert
Re: Java 9 support, Sling 10 release
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2017-12-06 at 14:16 +0100, Konrad Windszus wrote:
> > On 6. Dec 2017, at 14:15, Robert Munteanu <ro...@apache.org>
> > wrote:
> >
> > On Wed, 2017-12-06 at 14:02 +0100, Konrad Windszus wrote:
> > > > The way out would be to either:
> > > >
> > > > 1. adjust the exported package lists for Java 8
> > > > 2. deploy new bundles only for Java 9
> > > >
> > > > 1. is a risky proposition, especially since it can affect
> > > > backwards
> > > > compatibility
> > > > 2. requires further work in the provisioning model, and maybe a
> > > > bad
> > > > idea to invest in since the feature model is hopefully close to
> > > > complete.
> > > >
> > >
> > > I would propose not tweak the actual deployment but rather
> > > leverage
> > > OSGi execution environments (OSGi Core Spec 3.4). That should
> > > lead to
> > > the fact that
> > > ...
> > > A bundle can only resolve if the framework is running on a VM
> > > which
> > > implements one of the listed
> > > required execution environments.
> > > ...
> >
> > Does that mean we get bundles that fail to resolve by default on
> > Java
> > 8? That would not be good IMO.
>
> Yes, exactly.
> IMHO that should not do any harm (maybe except for some failing
> healthchecks which need to be adjusted)
I think it's a bad impression at least to have bundles that can't
resolve at startup. We have no idea what the impact will be for
consumers and it's tricky to make sure all health checks are done
right, and presumably anyone using the web console will start looking
for clues when they see bundles that don't start. We can document it,
but I am sure not that many people read the documentation :-)
What we can try - not sure if feasible - is to add a run mode named
'java9' and activate it from a special bootstrap bundle if we detect
that Java 9 is used to run Sling. Then in the provisioning model the
Java 9-specific bundles are attached to this 'java9' runmode, which
would mean:
- Java 8 is untouched
- Java 9 no longer requires adding the '--add-modules' flag
Again, note that this is completely untested but just might work.
Robert
Re: Java 9 support, Sling 10 release
Posted by Konrad Windszus <ko...@gmx.de>.
> On 6. Dec 2017, at 14:15, Robert Munteanu <ro...@apache.org> wrote:
>
> On Wed, 2017-12-06 at 14:02 +0100, Konrad Windszus wrote:
>>> The way out would be to either:
>>>
>>> 1. adjust the exported package lists for Java 8
>>> 2. deploy new bundles only for Java 9
>>>
>>> 1. is a risky proposition, especially since it can affect backwards
>>> compatibility
>>> 2. requires further work in the provisioning model, and maybe a bad
>>> idea to invest in since the feature model is hopefully close to
>>> complete.
>>>
>>
>> I would propose not tweak the actual deployment but rather leverage
>> OSGi execution environments (OSGi Core Spec 3.4). That should lead to
>> the fact that
>> ...
>> A bundle can only resolve if the framework is running on a VM which
>> implements one of the listed
>> required execution environments.
>> ...
>
> Does that mean we get bundles that fail to resolve by default on Java
> 8? That would not be good IMO.
Yes, exactly.
IMHO that should not do any harm (maybe except for some failing healthchecks which need to be adjusted)
>
> Robert
Re: Java 9 support, Sling 10 release
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2017-12-06 at 14:02 +0100, Konrad Windszus wrote:
> > The way out would be to either:
> >
> > 1. adjust the exported package lists for Java 8
> > 2. deploy new bundles only for Java 9
> >
> > 1. is a risky proposition, especially since it can affect backwards
> > compatibility
> > 2. requires further work in the provisioning model, and maybe a bad
> > idea to invest in since the feature model is hopefully close to
> > complete.
> >
>
> I would propose not tweak the actual deployment but rather leverage
> OSGi execution environments (OSGi Core Spec 3.4). That should lead to
> the fact that
> ...
> A bundle can only resolve if the framework is running on a VM which
> implements one of the listed
> required execution environments.
> ...
Does that mean we get bundles that fail to resolve by default on Java
8? That would not be good IMO.
Robert
Re: Java 9 support, Sling 10 release
Posted by Konrad Windszus <ko...@gmx.de>.
> The way out would be to either:
>
> 1. adjust the exported package lists for Java 8
> 2. deploy new bundles only for Java 9
>
> 1. is a risky proposition, especially since it can affect backwards
> compatibility
> 2. requires further work in the provisioning model, and maybe a bad
> idea to invest in since the feature model is hopefully close to
> complete.
>
I would propose not tweak the actual deployment but rather leverage OSGi execution environments (OSGi Core Spec 3.4). That should lead to the fact that
...
A bundle can only resolve if the framework is running on a VM which implements one of the listed
required execution environments.
...
Re: Java 9 support, Sling 10 release
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2017-12-06 at 11:52 +0100, Konrad Windszus wrote:
> I for sure don't want to block any release. So if we can release
> Sling 10 soon that's great.
>
> I would still like to understand why it is hard to deploy the missing
> dependencies for Java9 as additional bundles (with the according
> require headers). Do you have concerns that it is hard to figure out,
> which dependencies need to be added or is it hard to build OSGi
> bundles out of those dependencies?
If we deploy bundles for those dependencies Java 9 should work out of
the box, as the exported package lists are based on the modules
available at runtime.
However, the Java 8 package definitions are static, and we would get
packages exported by both the system bundle and some other bundles with
different versions. This is opening a can of worms, which sooner or
later leads to use constraint violations and overall system fragility.
The way out would be to either:
1. adjust the exported package lists for Java 8
2. deploy new bundles only for Java 9
1. is a risky proposition, especially since it can affect backwards
compatibility
2. requires further work in the provisioning model, and maybe a bad
idea to invest in since the feature model is hopefully close to
complete.
I'm open to trying out any of these, and maybe there's an option (3)
that I've missed, but neither of these look simple to me.
Thanks,
Robert
Re: Java 9 support, Sling 10 release
Posted by Konrad Windszus <ko...@gmx.de>.
I for sure don't want to block any release. So if we can release Sling 10 soon that's great.
I would still like to understand why it is hard to deploy the missing dependencies for Java9 as additional bundles (with the according require headers). Do you have concerns that it is hard to figure out, which dependencies need to be added or is it hard to build OSGi bundles out of those dependencies?
Konrad
Re: Java 9 support, Sling 10 release
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2017-12-06 at 13:56 +0100, Julian Reschke wrote:
> <https://issues.apache.org/jira/browse/SUREFIRE-1424> has some
> related
> discussion.
>
> FWIW, adding "--add-modules java.se.ee" doesn't work for some
> packages,
> such as javax.transaction.UserTransaction (see
> https://issues.apache.org/jira/browse/JCR-4200).
Thanks for the reference. I remember that javax.transaction and
javax.transaction.xa are special, I think Karl explained it to me some
time ago. Another reason to eventually remove the --add-modules
requirement.
Robert
Re: Java 9 support, Sling 10 release
Posted by Julian Reschke <ju...@gmx.de>.
On 2017-12-06 11:39, Robert Munteanu wrote:
> Hi Konrad,
>
> On Tue, 2017-12-05 at 16:47 +0100, Konrad Windszus wrote:
>> Hi Robert,
>> please see my inline comments
>>
>>> On 5. Dec 2017, at 16:23, Robert Munteanu <ro...@apache.org>
>>> wrote:
>>>
>>> Hi,
>>>
>>> ...
>>>
>>> - Tika is yet to have a release which removes JAXB usage
>>
>> This tika release should happen very soon (tm):
>> http://lucene.472066.n3.nabble.com/Tika-1-17-td4361894.html
>
> Well, they've been discussing this for a month :-)
>
>>
>>> - We did not have the time to replace deprecated modules with third
>>> party jars, partly because we would need to do it for all supported
>>> Java versions, which is complicated.
>>
>> Maybe I don't see all the details, but if I understand correctly we
>> are talking mostly about https://issues.apache.org/jira/browse/SLING-
>> 7135 <https://issues.apache.org/jira/browse/SLING-7135> (i.e. the
>> class javax/annotation/PostConstruct). This should be contained in ht
>> tps://mvnrepository.com/artifact/javax.annotation/jsr250-api <https:/
>> /mvnrepository.com/artifact/javax.annotation/jsr250-api>. Isn't it
>> possible to add that to the Sling Launchpad with a bundle header
>> which prevents it from being started with a JRE < 9?
>> The only other one is https://issues.apache.org/jira/browse/SLING-
>> 7106 <https://issues.apache.org/jira/browse/SLING-7106> but I am not
>> sure, whether the javax/xml/bind/JAXBException is only used in the
>> test class or also in a code path that is executed at run time.
>
> That's the root of the problem. We would need to add external jars for
> all packages that are no in java.see.ee, and make sure we don't break
> anything for older JVMs. Which AFAICT is problematic.
> ...
<https://issues.apache.org/jira/browse/SUREFIRE-1424> has some related
discussion.
FWIW, adding "--add-modules java.se.ee" doesn't work for some packages,
such as javax.transaction.UserTransaction (see
https://issues.apache.org/jira/browse/JCR-4200).
Best regards, Julian
Re: Java 9 support, Sling 10 release
Posted by Robert Munteanu <ro...@apache.org>.
Hi Konrad,
On Tue, 2017-12-05 at 16:47 +0100, Konrad Windszus wrote:
> Hi Robert,
> please see my inline comments
>
> > On 5. Dec 2017, at 16:23, Robert Munteanu <ro...@apache.org>
> > wrote:
> >
> > Hi,
> >
> > ...
> >
> > - Tika is yet to have a release which removes JAXB usage
>
> This tika release should happen very soon (tm):
> http://lucene.472066.n3.nabble.com/Tika-1-17-td4361894.html
Well, they've been discussing this for a month :-)
>
> > - We did not have the time to replace deprecated modules with third
> > party jars, partly because we would need to do it for all supported
> > Java versions, which is complicated.
>
> Maybe I don't see all the details, but if I understand correctly we
> are talking mostly about https://issues.apache.org/jira/browse/SLING-
> 7135 <https://issues.apache.org/jira/browse/SLING-7135> (i.e. the
> class javax/annotation/PostConstruct). This should be contained in ht
> tps://mvnrepository.com/artifact/javax.annotation/jsr250-api <https:/
> /mvnrepository.com/artifact/javax.annotation/jsr250-api>. Isn't it
> possible to add that to the Sling Launchpad with a bundle header
> which prevents it from being started with a JRE < 9?
> The only other one is https://issues.apache.org/jira/browse/SLING-
> 7106 <https://issues.apache.org/jira/browse/SLING-7106> but I am not
> sure, whether the javax/xml/bind/JAXBException is only used in the
> test class or also in a code path that is executed at run time.
That's the root of the problem. We would need to add external jars for
all packages that are no in java.see.ee, and make sure we don't break
anything for older JVMs. Which AFAICT is problematic.
We can't rely on just our failing ITs, we need to make sure we cover
all packages that were moved.
Also, the
> > So my proposition, once the latest scripting.core and
> > servlet.resolver
> > release are out it to start the Sling 10 release process,
> > supporting
> > Java 9 with the --add-modules java.se.ee flag, and work towards
> > removing that constraint for Sling 10. We would also run tests with
> > that, obviously
>
> Temporarily running the ITs with that is fine for sure, but I would
> like to be able to start Sling 10 even without that option.
Like? Sure, I'd like that as well :-) and that was my objective from
the beginning. But I believe that getting Sling 10 out in say 2 weeks
is better than next year - which is going to be 6 weeks probably, with
the end of year vacations.
Thanks,
Robert
Re: Java 9 support, Sling 10 release
Posted by Konrad Windszus <ko...@gmx.de>.
Hi Robert,
please see my inline comments
> On 5. Dec 2017, at 16:23, Robert Munteanu <ro...@apache.org> wrote:
>
> Hi,
>
> ...
>
> - Tika is yet to have a release which removes JAXB usage
This tika release should happen very soon (tm): http://lucene.472066.n3.nabble.com/Tika-1-17-td4361894.html
> - We did not have the time to replace deprecated modules with third
> party jars, partly because we would need to do it for all supported
> Java versions, which is complicated.
Maybe I don't see all the details, but if I understand correctly we are talking mostly about https://issues.apache.org/jira/browse/SLING-7135 <https://issues.apache.org/jira/browse/SLING-7135> (i.e. the class javax/annotation/PostConstruct). This should be contained in https://mvnrepository.com/artifact/javax.annotation/jsr250-api <https://mvnrepository.com/artifact/javax.annotation/jsr250-api>. Isn't it possible to add that to the Sling Launchpad with a bundle header which prevents it from being started with a JRE < 9?
The only other one is https://issues.apache.org/jira/browse/SLING-7106 <https://issues.apache.org/jira/browse/SLING-7106> but I am not sure, whether the javax/xml/bind/JAXBException is only used in the test class or also in a code path that is executed at run time.
>
> So my proposition, once the latest scripting.core and servlet.resolver
> release are out it to start the Sling 10 release process, supporting
> Java 9 with the --add-modules java.se.ee flag, and work towards
> removing that constraint for Sling 10. We would also run tests with
> that, obviously
Temporarily running the ITs with that is fine for sure, but I would like to be able to start Sling 10 even without that option.
> .
>
> Thoughts?
>
> Thanks,
>
> Robert