You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Olaf Flebbe <of...@oflebbe.de> on 2016/12/30 16:50:32 UTC
Major Updates
Hi,
just to make sure that everyone notices: My question about handling JDK7 vs. JDK8 raised concerns by Arnaud Launay. He likes to be able to compile the full stack with openjdk7, which is the only supported JDK in Debian-8.
I asked him in BIGTOP-2649 to propose changes to have a JDK switching vacility. Right now it is a singular workaround for this usecase, but I think it can be handy when JDK9 arrives.
If anyone has concerns please speak up here or subscribe to BIGTOP-2649.
Olaf
Re: Major Updates
Posted by "MrAsanjar ." <af...@gmail.com>.
Hi Olaf,
I misunderstood your original statement, it implied to me that there was no
workaround. sorry,
On Fri, Dec 30, 2016 at 11:03 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
> Hi Amir,
>
> what Do you want us to tell ? We are already doing this.
>
>
> Olaf
>
>
>
> > Am 30.12.2016 um 17:55 schrieb MrAsanjar . <af...@gmail.com>:
> >
> > https://www.linkedin.com/pulse/installing-openjdk-8-
> tomcat-debian-jessie-iga-made-muliarsa
> >
> > On Fri, Dec 30, 2016 at 10:50 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
> >
> >> Hi,
> >>
> >> just to make sure that everyone notices: My question about handling JDK7
> >> vs. JDK8 raised concerns by Arnaud Launay. He likes to be able to
> >> compile the full stack with openjdk7, which is the only supported JDK in
> >> Debian-8.
> >>
> >> I asked him in BIGTOP-2649 to propose changes to have a JDK switching
> >> vacility. Right now it is a singular workaround for this usecase, but I
> >> think it can be handy when JDK9 arrives.
> >>
> >> If anyone has concerns please speak up here or subscribe to
> BIGTOP-2649.
> >>
> >> Olaf
>
>
Re: Major Updates
Posted by Arnaud Launay <as...@launay.org>.
Le Tue, Jan 03, 2017 at 05:32:09PM -0800, Roman Shaposhnik a écrit:
> you're bringing up some good points. Let me ask you this, though:
> do you think your concerns would be take care of if we had a way
> to instruct whatever version of JDK we're using to generate 7
> bytecode via -target 7 -source 7 ?
IMHO, no: the whole point is to compile (and run) the whole stack
using the same JDK. This is the only way I'm sure things don't
get mixed up -- trying to use a JDK 8 with a different
target/source seems to me much more trouble and probably
more maintenance, too. Plus the fact that you'll never be 100%
sure that everything has the correct settings passed...
If you have a look at the patches I sent earlier, I hope you'll
find them non-intrusive, the default stays with java 8, and it
permits to choose a different one with a single environment variable.
I built the full bigtop stack, with those patches and
BIGTOP_JDK=7 defined (well, the full deb target at least), today,
without a glitch.
Arnaud.
Re: Major Updates
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
Hi Arnaud!
you're bringing up some good points. Let me ask you this, though:
do you think your concerns would be take care of if we had a way
to instruct whatever version of JDK we're using to generate 7
bytecode via -target 7 -source 7 ?
Thanks,
Roman.
On Fri, Dec 30, 2016 at 9:44 AM, Arnaud Launay <as...@launay.org> wrote:
> Hello,
>
>
> Le Fri, Dec 30, 2016 at 06:03:42PM +0100, Olaf Flebbe a écrit:
>> > https://www.linkedin.com/pulse/installing-openjdk-8-tomcat-debian-jessie-iga-made-muliarsa
>> what Do you want us to tell ? We are already doing this.
>
> For the record, my request to still be able to compile bigtop
> with JDK7 is based on the following elements:
>
> - JDK 8 is apparently less officially supported on 2.7:
> https://wiki.apache.org/hadoop/Roadmap
> hadoop-2.7: jdk7 at minima, jdk8 seems supported since october
> hadoop-2.8: supports both JDK 7 and 8
> hadoop-3: supports *only* jdk8
>
> - the second one is a bit more "company policy": we do not want
> to deploy backports, unless absolutely necessary. It does not
> matter if on the compiling server we have to use backports to
> add some stuff (maven 3.3 for example), BUT not on the
> production servers. Those are on Debian stable, using JDK7,
> with no backports, and thus we want (need...) to compile bigtop JDK7.
>
> - I saw some strange things here are there with code compiled
> with JDK8 and running under JDK7 that I absolutely do not want
> to see for our hadoop pile :)
>
> - last (but not least), the whole thing came from gradle being
> unable to download stuff using Cloudflare SSL: BIGTOP-2633
> Olaf used a nuclear device (upping to java8) to kill a fly:
> upgrading gradle to 2.12 was the only thing necessary. This is
> now done: BIGTOP-2648
>
> So, unless the whole thing is on hadoop 2.8, I'd vote to stay on
> JDK7. However, as Olaf stated, preparing for other jdk (8, 9,
> Windows^W) using a variable which unless defined would default to
> JDK8 (or 7, as you wish) might be a better long-term solution.
>
>
> Hence, what about something like
> BIGTOP_JDK=7
> ./gradlew deb
>
> and something like this in do-component-build:
>
> if [ "${BIGTOP_JDK:=8}" == "8" ]; then
> MAVEN_ADDITIONAL="-Dadditionalparam=-Xdoclint:none"
> fi
>
> and later
>
> mvn -DskipTests (...) \
> ${MAVEN_ADDITIONAL} \
> clean site install assembly:single "$@
>
>
>
> I have no idea how to manage bigtop.bom though:
> 'jdk' { version = '1.8'; version_base = version }
> nor build.gradle
> def final langLevel = "1.7"
> nor packages.gradle
> classpath 'org.eclipse.jgit:org.eclipse.jgit.java7:3.6.2.201501210735-r'
>
>
> Maybe a few sed's at the beginning of gradlew ?
>
>
> Arnaud.
Re: Major Updates
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi,
> Olaf used a nuclear device (upping to java8) to kill a fly:
> upgrading gradle to 2.12 was the only thing necessary. This is
> now done: BIGTOP-2648
openjdk-7 has other known problems regarding TLS. Glad that you figured out that this specific problem can be worked around by updating gradle, which was already on our agenda.
>Maybe a few sed's at the beginning of gradlew ?
No, please not.
Thanks!
Olaf
Re: Major Updates
Posted by Arnaud Launay <as...@launay.org>.
Hello,
Le Fri, Dec 30, 2016 at 06:03:42PM +0100, Olaf Flebbe a écrit:
> > https://www.linkedin.com/pulse/installing-openjdk-8-tomcat-debian-jessie-iga-made-muliarsa
> what Do you want us to tell ? We are already doing this.
For the record, my request to still be able to compile bigtop
with JDK7 is based on the following elements:
- JDK 8 is apparently less officially supported on 2.7:
https://wiki.apache.org/hadoop/Roadmap
hadoop-2.7: jdk7 at minima, jdk8 seems supported since october
hadoop-2.8: supports both JDK 7 and 8
hadoop-3: supports *only* jdk8
- the second one is a bit more "company policy": we do not want
to deploy backports, unless absolutely necessary. It does not
matter if on the compiling server we have to use backports to
add some stuff (maven 3.3 for example), BUT not on the
production servers. Those are on Debian stable, using JDK7,
with no backports, and thus we want (need...) to compile bigtop JDK7.
- I saw some strange things here are there with code compiled
with JDK8 and running under JDK7 that I absolutely do not want
to see for our hadoop pile :)
- last (but not least), the whole thing came from gradle being
unable to download stuff using Cloudflare SSL: BIGTOP-2633
Olaf used a nuclear device (upping to java8) to kill a fly:
upgrading gradle to 2.12 was the only thing necessary. This is
now done: BIGTOP-2648
So, unless the whole thing is on hadoop 2.8, I'd vote to stay on
JDK7. However, as Olaf stated, preparing for other jdk (8, 9,
Windows^W) using a variable which unless defined would default to
JDK8 (or 7, as you wish) might be a better long-term solution.
Hence, what about something like
BIGTOP_JDK=7
./gradlew deb
and something like this in do-component-build:
if [ "${BIGTOP_JDK:=8}" == "8" ]; then
MAVEN_ADDITIONAL="-Dadditionalparam=-Xdoclint:none"
fi
and later
mvn -DskipTests (...) \
${MAVEN_ADDITIONAL} \
clean site install assembly:single "$@
I have no idea how to manage bigtop.bom though:
'jdk' { version = '1.8'; version_base = version }
nor build.gradle
def final langLevel = "1.7"
nor packages.gradle
classpath 'org.eclipse.jgit:org.eclipse.jgit.java7:3.6.2.201501210735-r'
Maybe a few sed's at the beginning of gradlew ?
Arnaud.
Re: Major Updates
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi Amir,
what Do you want us to tell ? We are already doing this.
Olaf
> Am 30.12.2016 um 17:55 schrieb MrAsanjar . <af...@gmail.com>:
>
> https://www.linkedin.com/pulse/installing-openjdk-8-tomcat-debian-jessie-iga-made-muliarsa
>
> On Fri, Dec 30, 2016 at 10:50 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
>
>> Hi,
>>
>> just to make sure that everyone notices: My question about handling JDK7
>> vs. JDK8 raised concerns by Arnaud Launay. He likes to be able to
>> compile the full stack with openjdk7, which is the only supported JDK in
>> Debian-8.
>>
>> I asked him in BIGTOP-2649 to propose changes to have a JDK switching
>> vacility. Right now it is a singular workaround for this usecase, but I
>> think it can be handy when JDK9 arrives.
>>
>> If anyone has concerns please speak up here or subscribe to BIGTOP-2649.
>>
>> Olaf
Re: Major Updates
Posted by "MrAsanjar ." <af...@gmail.com>.
https://www.linkedin.com/pulse/installing-openjdk-8-tomcat-debian-jessie-iga-made-muliarsa
On Fri, Dec 30, 2016 at 10:50 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
> Hi,
>
> just to make sure that everyone notices: My question about handling JDK7
> vs. JDK8 raised concerns by Arnaud Launay. He likes to be able to
> compile the full stack with openjdk7, which is the only supported JDK in
> Debian-8.
>
> I asked him in BIGTOP-2649 to propose changes to have a JDK switching
> vacility. Right now it is a singular workaround for this usecase, but I
> think it can be handy when JDK9 arrives.
>
> If anyone has concerns please speak up here or subscribe to BIGTOP-2649.
>
> Olaf