You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2016/04/25 17:42:03 UTC
tomcat 7 broken on java 7 for linux distro
Hi guys,
tomcat uses ConcurrentHashMap in few places and doesn't rely on
ConcurrentMap API (ApplicationContext IIRC for instance was the case I
encounter). This means if you build tomcat with java 8 and run on java 7 it
is broken cause of this new KeyViewSet API used on java 8 (returned type is
used for method lookup at runtime).
Why would you do it? Not sure but several linux distribution do it.
I know we could easily ask all linux distro to build using java 7 but at
least fedora/redhat/ubuntu are impacted and tomcat can easily without
loosing any feature make it passing for that case using the interface
instead of the implementation as field type.
Do you think it is possible or would you just move it over linux distro? If
this last one: how to ensure we don't get more regression in the future due
to another build process for user binaries?
Thanks,
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
Re: tomcat 7 broken on java 7 for linux distro
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 4/27/16 7:41 AM, Mark Thomas wrote:
> On 27/04/2016 00:03, Mark Thomas wrote:
>> On 25/04/2016 16:42, Romain Manni-Bucau wrote:
>>> Hi guys,
>>>
>>> tomcat uses ConcurrentHashMap in few places and doesn't rely on
>>> ConcurrentMap API (ApplicationContext IIRC for instance was the case I
>>> encounter). This means if you build tomcat with java 8 and run on java 7 it
>>> is broken cause of this new KeyViewSet API used on java 8 (returned type is
>>> used for method lookup at runtime).
>>>
>>> Why would you do it? Not sure but several linux distribution do it.
>>>
>>> I know we could easily ask all linux distro to build using java 7 but at
>>> least fedora/redhat/ubuntu are impacted and tomcat can easily without
>>> loosing any feature make it passing for that case using the interface
>>> instead of the implementation as field type.
>>>
>>> Do you think it is possible or would you just move it over linux distro?
>>
>> I've been through the source code and I have a patch locally ready to
>> commit that fixes this in 9.0.x. However...
>>
>> In some places, this would mean changing the API (usually a protected
>> field) of an internal component we might reasonably expect some users to
>> have extended. That is generally something we try and avoid in a point
>> release unless the change is absolutely necessary (e.g. security) or we
>> view the chances of it being used as very, very low.
>>
>> Therefore, I want to review my local changes and split them into two
>> commits. The safe one and the API breaking one. I'm not sure the API
>> breaking one is going to be back-ported beyond 8.5.x.
>>
>> Fundamentally, this is an issue for the distro. The Tomcat docs are
>> quite specific (see BUILDING.txt) about which version of Java should be
>> used to build Tomcat. If a distro wants to mess with that, they get to
>> deal with the consequences.
>>
>>> If
>>> this last one: how to ensure we don't get more regression in the future due
>>> to another build process for user binaries?
>>
>> This is generally something we check during the release. It is mostly a
>> manual process although it is automated where building with the wrong
>> Java version causes issues for DBCP.
>
> After rather more commits than I expected (it was easier top review
> package by package than all in one go) I think this is fixed.
In reading those commits, my only concern was of performance. I think in
all cases (Use of Map versus ConcurrentMap versus ConcurrentHashMap), an
invokevirtual call is made rather than an invokestatic, so I'm not sure
if it makes too much of a difference. But I seem to recall that making
an "interface" call used to be slower than a "class" call, because of
the extra level of indirection. These days, I'd expect that the JIT
solves all of that and the difference is no longer actually measurable.
But since some of these classes are used sometimes many times per
request, it did get my spidey-sense tingling.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: tomcat 7 broken on java 7 for linux distro
Posted by Romain Manni-Bucau <rm...@gmail.com>.
from what I saw in commit mails it seems so. Does it still worth a page
explaining linux distro rebuild tomcat and how to check the java version
(reading MANIFEST.MF from catalina.jar for instance) in case it happens
again or someone hits it short term?
Thanks to have taken it into consideration anyway.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-04-27 13:41 GMT+02:00 Mark Thomas <ma...@apache.org>:
> On 27/04/2016 00:03, Mark Thomas wrote:
> > On 25/04/2016 16:42, Romain Manni-Bucau wrote:
> >> Hi guys,
> >>
> >> tomcat uses ConcurrentHashMap in few places and doesn't rely on
> >> ConcurrentMap API (ApplicationContext IIRC for instance was the case I
> >> encounter). This means if you build tomcat with java 8 and run on java
> 7 it
> >> is broken cause of this new KeyViewSet API used on java 8 (returned
> type is
> >> used for method lookup at runtime).
> >>
> >> Why would you do it? Not sure but several linux distribution do it.
> >>
> >> I know we could easily ask all linux distro to build using java 7 but at
> >> least fedora/redhat/ubuntu are impacted and tomcat can easily without
> >> loosing any feature make it passing for that case using the interface
> >> instead of the implementation as field type.
> >>
> >> Do you think it is possible or would you just move it over linux distro?
> >
> > I've been through the source code and I have a patch locally ready to
> > commit that fixes this in 9.0.x. However...
> >
> > In some places, this would mean changing the API (usually a protected
> > field) of an internal component we might reasonably expect some users to
> > have extended. That is generally something we try and avoid in a point
> > release unless the change is absolutely necessary (e.g. security) or we
> > view the chances of it being used as very, very low.
> >
> > Therefore, I want to review my local changes and split them into two
> > commits. The safe one and the API breaking one. I'm not sure the API
> > breaking one is going to be back-ported beyond 8.5.x.
> >
> > Fundamentally, this is an issue for the distro. The Tomcat docs are
> > quite specific (see BUILDING.txt) about which version of Java should be
> > used to build Tomcat. If a distro wants to mess with that, they get to
> > deal with the consequences.
> >
> >> If
> >> this last one: how to ensure we don't get more regression in the future
> due
> >> to another build process for user binaries?
> >
> > This is generally something we check during the release. It is mostly a
> > manual process although it is automated where building with the wrong
> > Java version causes issues for DBCP.
>
> After rather more commits than I expected (it was easier top review
> package by package than all in one go) I think this is fixed.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: tomcat 7 broken on java 7 for linux distro
Posted by Mark Thomas <ma...@apache.org>.
On 27/04/2016 00:03, Mark Thomas wrote:
> On 25/04/2016 16:42, Romain Manni-Bucau wrote:
>> Hi guys,
>>
>> tomcat uses ConcurrentHashMap in few places and doesn't rely on
>> ConcurrentMap API (ApplicationContext IIRC for instance was the case I
>> encounter). This means if you build tomcat with java 8 and run on java 7 it
>> is broken cause of this new KeyViewSet API used on java 8 (returned type is
>> used for method lookup at runtime).
>>
>> Why would you do it? Not sure but several linux distribution do it.
>>
>> I know we could easily ask all linux distro to build using java 7 but at
>> least fedora/redhat/ubuntu are impacted and tomcat can easily without
>> loosing any feature make it passing for that case using the interface
>> instead of the implementation as field type.
>>
>> Do you think it is possible or would you just move it over linux distro?
>
> I've been through the source code and I have a patch locally ready to
> commit that fixes this in 9.0.x. However...
>
> In some places, this would mean changing the API (usually a protected
> field) of an internal component we might reasonably expect some users to
> have extended. That is generally something we try and avoid in a point
> release unless the change is absolutely necessary (e.g. security) or we
> view the chances of it being used as very, very low.
>
> Therefore, I want to review my local changes and split them into two
> commits. The safe one and the API breaking one. I'm not sure the API
> breaking one is going to be back-ported beyond 8.5.x.
>
> Fundamentally, this is an issue for the distro. The Tomcat docs are
> quite specific (see BUILDING.txt) about which version of Java should be
> used to build Tomcat. If a distro wants to mess with that, they get to
> deal with the consequences.
>
>> If
>> this last one: how to ensure we don't get more regression in the future due
>> to another build process for user binaries?
>
> This is generally something we check during the release. It is mostly a
> manual process although it is automated where building with the wrong
> Java version causes issues for DBCP.
After rather more commits than I expected (it was easier top review
package by package than all in one go) I think this is fixed.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: tomcat 7 broken on java 7 for linux distro
Posted by Mark Thomas <ma...@apache.org>.
On 25/04/2016 16:42, Romain Manni-Bucau wrote:
> Hi guys,
>
> tomcat uses ConcurrentHashMap in few places and doesn't rely on
> ConcurrentMap API (ApplicationContext IIRC for instance was the case I
> encounter). This means if you build tomcat with java 8 and run on java 7 it
> is broken cause of this new KeyViewSet API used on java 8 (returned type is
> used for method lookup at runtime).
>
> Why would you do it? Not sure but several linux distribution do it.
>
> I know we could easily ask all linux distro to build using java 7 but at
> least fedora/redhat/ubuntu are impacted and tomcat can easily without
> loosing any feature make it passing for that case using the interface
> instead of the implementation as field type.
>
> Do you think it is possible or would you just move it over linux distro?
I've been through the source code and I have a patch locally ready to
commit that fixes this in 9.0.x. However...
In some places, this would mean changing the API (usually a protected
field) of an internal component we might reasonably expect some users to
have extended. That is generally something we try and avoid in a point
release unless the change is absolutely necessary (e.g. security) or we
view the chances of it being used as very, very low.
Therefore, I want to review my local changes and split them into two
commits. The safe one and the API breaking one. I'm not sure the API
breaking one is going to be back-ported beyond 8.5.x.
Fundamentally, this is an issue for the distro. The Tomcat docs are
quite specific (see BUILDING.txt) about which version of Java should be
used to build Tomcat. If a distro wants to mess with that, they get to
deal with the consequences.
> If
> this last one: how to ensure we don't get more regression in the future due
> to another build process for user binaries?
This is generally something we check during the release. It is mostly a
manual process although it is automated where building with the wrong
Java version causes issues for DBCP.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: tomcat 7 broken on java 7 for linux distro
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Romain,
On 4/26/16 5:32 PM, Romain Manni-Bucau wrote:
> Le 26 avr. 2016 22:27, "Christopher Schultz" <ch...@christopherschultz.net>
> a écrit :
>>
>> Romain,
>>
>> On 4/25/16 11:42 AM, Romain Manni-Bucau wrote:
>>> Hi guys,
>>>
>>> tomcat uses ConcurrentHashMap in few places and doesn't rely on
>>> ConcurrentMap API (ApplicationContext IIRC for instance was the case I
>>> encounter). This means if you build tomcat with java 8 and run on java
> 7 it
>>> is broken cause of this new KeyViewSet API used on java 8 (returned
> type is
>>> used for method lookup at runtime).
>>
>> Which method, here? The return type of a method isn't officially part of
>> the method's signature. Are you saying that the Java 8 compiler will
>> choose a method (from a specific interface) at compile-time that doesn't
>> exist in earlier versions of Java?
>>
>> Can this be fixed with a cast?
>>
>
> This is not java 8 specific. The method lookup is done using return type
> too - check bytecode with javap for instance.
The *runtime* uses the return-type of a method as part of the signature
for method-lookup, but javac does not. There is no way to differentiate
between two methods with the same signature but different return types,
so that's not a legal in Java-source. But it's perfectly legal in
bytecode (e.g. if you have a bytecode assembler, you can do it... not
sure if the verifier will barf or not).
It appears there is a breaking API change between Java 8 and Java 7
which causes this. :(
In Java 7, java.util.concurrent.ConcurrentHashMap.keySet returns Set<K>
In Java 8, java.util.concurrent.ConcurrentHashMap.keySet returns
HashSetView<K,V>
This seems to be a oversight on the part of the API designers.
> I didnt check if a cast fixes it but using a temp var should or
> moving the impl typing to the interface at field level fixes it in
> tomcat and no api is missing AFAIK.
I checked, and using a cast does in fact fix the problem:
The Java source:
((AbstractMap)chm).keySet();
yields this bytecode:
3: invokevirtual #2 // Method
java/util/AbstractMap.keySet:()Ljava/util/Set;
, while this Java source:
chm.keySet();
yields this bytecode:
3: invokevirtual #2 // Method
java/util/concurrent/ConcurrentHashMap.keySet:()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
So Mark, I think this can be done using explicit casts. It would make it
much cleaner for users who have extended Tomcat internal classes. The
question is whether or not we should do this at all, since it's
basically a problem with Java and, if the BUILDING.txt instructions are
followed, then it shouldn't be a problem.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: tomcat 7 broken on java 7 for linux distro
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 26 avr. 2016 22:27, "Christopher Schultz" <ch...@christopherschultz.net>
a écrit :
>
> Romain,
>
> On 4/25/16 11:42 AM, Romain Manni-Bucau wrote:
> > Hi guys,
> >
> > tomcat uses ConcurrentHashMap in few places and doesn't rely on
> > ConcurrentMap API (ApplicationContext IIRC for instance was the case I
> > encounter). This means if you build tomcat with java 8 and run on java
7 it
> > is broken cause of this new KeyViewSet API used on java 8 (returned
type is
> > used for method lookup at runtime).
>
> Which method, here? The return type of a method isn't officially part of
> the method's signature. Are you saying that the Java 8 compiler will
> choose a method (from a specific interface) at compile-time that doesn't
> exist in earlier versions of Java?
>
> Can this be fixed with a cast?
>
This is not java 8 specific. The method lookup is done using return type
too - check bytecode with javap for instance. I didnt check if a cast fixes
it but using a temp var should or moving the impl typing to the interface
at field level fixes it in tomcat and no api is missing AFAIK.
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: tomcat 7 broken on java 7 for linux distro
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Romain,
On 4/25/16 11:42 AM, Romain Manni-Bucau wrote:
> Hi guys,
>
> tomcat uses ConcurrentHashMap in few places and doesn't rely on
> ConcurrentMap API (ApplicationContext IIRC for instance was the case I
> encounter). This means if you build tomcat with java 8 and run on java 7 it
> is broken cause of this new KeyViewSet API used on java 8 (returned type is
> used for method lookup at runtime).
Which method, here? The return type of a method isn't officially part of
the method's signature. Are you saying that the Java 8 compiler will
choose a method (from a specific interface) at compile-time that doesn't
exist in earlier versions of Java?
Can this be fixed with a cast?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: tomcat 7 broken on java 7 for linux distro
Posted by Stefan Huehner <st...@huehner.org>.
On Mon, Apr 25, 2016 at 06:18:53PM +0200, Emmanuel Bourg wrote:
> Le 25/04/2016 17:42, Romain Manni-Bucau a écrit :
>
> > I know we could easily ask all linux distro to build using java 7 but at
> > least fedora/redhat/ubuntu are impacted and tomcat can easily without
> > loosing any feature make it passing for that case using the interface
> > instead of the implementation as field type.
>
> Debian and Ubuntu usually build and run Tomcat with the same version of
> Java. For example Ubuntu 16.04 LTS and the upcoming Debian 9 default to
> Java 8 (Java 7 has been removed). Tomcat 7 is no longer supported for
> these versions (Ubuntu switched to Tomcat 8 and Debian will remove it in
> a few months, the general rule is to keep only one version of Java and
> Tomcat per major release). In the previous release Tomcat 7 was built
> with Java 7.
>
> This issue may arise if the user installs its own Java 7 and use it to
> run Tomcat instead of the JRE provided by the distribution. I can
> address that in Debian by ensuring the package dependencies are more
> strict (please file a bug against the tomcat8 package if it's affected too).
Hi,
i'd like to jump in as a user having such a use case.
In our jenkins systems we daily test our software against various java+tomcat versions we still (need to) support.
I.e. java 6..8 and tomcat 6..8
So far without planning we have kind of paired
1.) java6 + tomcat 6 (using Ubuntu 12.04 LTS)
2.) java7 + tomcat 7 (using Ubuntu 14.04 LTS)
3.) java8 + tomcat 7 (by using 16.04 LTS in future)
So never noticed that issue above.
However as system requirement of tomcat allowed seems to allow to mix it would be nice to keep that flexibility.
If not maybe we should add a note here:
http://tomcat.apache.org/whichversion.html
By adding the restriction there to let people know.
Note that was even possible inside distro as i.e. Ubuntu 14.04 shipped java 6 + 7 (if you enable universe part of the repo).
No big deal to us, but i think important to document.
Regards,
Stefan Hühner
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: tomcat 7 broken on java 7 for linux distro
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Not sure what happent, got the same it in one of my box (but was 15.10 so
can't explain the feedback i got with 14.04). Maybe a package update.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-04-25 21:41 GMT+02:00 Emmanuel Bourg <eb...@apache.org>:
> Le 25/04/2016 18:50, Romain Manni-Bucau a écrit :
> > Just to make it clearer: 14.04 had java 7 as expected but tomcat7 package
> > was compiled with java 8.
>
> This shouldn't be possible. Ubuntu packages are built in a clean
> environment with no packages or applications not in the distribution.
> Ubuntu 14.04 doesn't have Java 8 and therefore official packages can't
> be compiled with Java 8. If you look at the build log [1] for the
> version of Tomcat 7 currently distributed for Ubuntu 14.04 you'll see
> that Java 7 was used.
>
> Emmanuel Bourg
>
> [1]
>
> https://launchpadlibrarian.net/209543797/buildlog_ubuntu-trusty-i386.tomcat7_7.0.52-1ubuntu0.3_BUILDING.txt.gz
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: tomcat 7 broken on java 7 for linux distro
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 25/04/2016 18:50, Romain Manni-Bucau a écrit :
> Just to make it clearer: 14.04 had java 7 as expected but tomcat7 package
> was compiled with java 8.
This shouldn't be possible. Ubuntu packages are built in a clean
environment with no packages or applications not in the distribution.
Ubuntu 14.04 doesn't have Java 8 and therefore official packages can't
be compiled with Java 8. If you look at the build log [1] for the
version of Tomcat 7 currently distributed for Ubuntu 14.04 you'll see
that Java 7 was used.
Emmanuel Bourg
[1]
https://launchpadlibrarian.net/209543797/buildlog_ubuntu-trusty-i386.tomcat7_7.0.52-1ubuntu0.3_BUILDING.txt.gz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: tomcat 7 broken on java 7 for linux distro
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Just to make it clearer: 14.04 had java 7 as expected but tomcat7 package
was compiled with java 8.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-04-25 18:45 GMT+02:00 Emmanuel Bourg <eb...@apache.org>:
> Le 25/04/2016 18:32, Romain Manni-Bucau a écrit :
> > Only met it on previous LTS (16.04 is still fresh so was 14 one). So
> sounds
> > it was a no luck case.
>
> That's odd because Ubuntu 14.04 LTS doesn't have Java 8 [1]. It first
> appeared in Ubuntu 15.10. Tomcat 7 in Ubuntu 14.04 LTS is built with Java
> 7.
>
> Emmanuel Bourg
>
> http://packages.ubuntu.com/search?keywords=openjdk-8-jre-headless
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: tomcat 7 broken on java 7 for linux distro
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 25/04/2016 18:32, Romain Manni-Bucau a écrit :
> Only met it on previous LTS (16.04 is still fresh so was 14 one). So sounds
> it was a no luck case.
That's odd because Ubuntu 14.04 LTS doesn't have Java 8 [1]. It first
appeared in Ubuntu 15.10. Tomcat 7 in Ubuntu 14.04 LTS is built with Java 7.
Emmanuel Bourg
http://packages.ubuntu.com/search?keywords=openjdk-8-jre-headless
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: tomcat 7 broken on java 7 for linux distro
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Only met it on previous LTS (16.04 is still fresh so was 14 one). So sounds
it was a no luck case.
Maybe a page on tomcat website dealing with main integrations and things to
check (/etc/defaults/tomcatX JAVA_HOME etc...) can be enough for this
issue. What do you think?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-04-25 18:18 GMT+02:00 Emmanuel Bourg <eb...@apache.org>:
> Le 25/04/2016 17:42, Romain Manni-Bucau a écrit :
>
> > I know we could easily ask all linux distro to build using java 7 but at
> > least fedora/redhat/ubuntu are impacted and tomcat can easily without
> > loosing any feature make it passing for that case using the interface
> > instead of the implementation as field type.
>
> Debian and Ubuntu usually build and run Tomcat with the same version of
> Java. For example Ubuntu 16.04 LTS and the upcoming Debian 9 default to
> Java 8 (Java 7 has been removed). Tomcat 7 is no longer supported for
> these versions (Ubuntu switched to Tomcat 8 and Debian will remove it in
> a few months, the general rule is to keep only one version of Java and
> Tomcat per major release). In the previous release Tomcat 7 was built
> with Java 7.
>
> This issue may arise if the user installs its own Java 7 and use it to
> run Tomcat instead of the JRE provided by the distribution. I can
> address that in Debian by ensuring the package dependencies are more
> strict (please file a bug against the tomcat8 package if it's affected
> too).
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: tomcat 7 broken on java 7 for linux distro
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 25/04/2016 17:42, Romain Manni-Bucau a écrit :
> I know we could easily ask all linux distro to build using java 7 but at
> least fedora/redhat/ubuntu are impacted and tomcat can easily without
> loosing any feature make it passing for that case using the interface
> instead of the implementation as field type.
Debian and Ubuntu usually build and run Tomcat with the same version of
Java. For example Ubuntu 16.04 LTS and the upcoming Debian 9 default to
Java 8 (Java 7 has been removed). Tomcat 7 is no longer supported for
these versions (Ubuntu switched to Tomcat 8 and Debian will remove it in
a few months, the general rule is to keep only one version of Java and
Tomcat per major release). In the previous release Tomcat 7 was built
with Java 7.
This issue may arise if the user installs its own Java 7 and use it to
run Tomcat instead of the JRE provided by the distribution. I can
address that in Debian by ensuring the package dependencies are more
strict (please file a bug against the tomcat8 package if it's affected too).
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org