Hi Graham,
Thanks for your reply.
I guess this means that we will compile at Java 8 and hope that the
Hadoop libraries(compiled at Java 7) we call and the Hbase dependancies
will work - if not we may need to make some changes - we hope that any
changes we make will still allow the code to be compiled at java 7. It
seems that I misunderstood - can you confirm that we do not need to wait
for Hadoop 3 to bring in Java 8 and Janus? We should look to see what the
migration considerations are for Hadoop 2 customers to move to Janus.
all the best, David.
From: Graham Wallis <[email protected]>
To: [email protected]
Date: 19/07/2017 16:27
Subject: Re: Maven restructure
I think that specifying the -source and -target options won't help really.
For example, -target specifies the minimum runtime version - but we would
need to set it 1.8 as documented below.
I believe that JanusGraph requires Java 1.8.0 Update 40.
(BTW it also requires Maven 3.3.9, but I imagine that most of us are on at
least that version anyway and we would increase the version we specify in
requireMavenVersion).
Regarding Java 8 and Java 7 compatibility, the Oracle documentation says:
“Binary Compatibility: Java SE 8 is binary-compatible with Java SE 7
except for the incompatibilities listed below. Except for the noted
incompatibilities, class files built with the Java SE 7 compiler will run
correctly in Java SE 8. Class files built with the Java SE 8 compiler will
not run on earlier releases of Java SE.”
My para-phrasing: You should be able to run a class built with J7 in a J8
runtime, although there may be some patching required. You cannot run a
class built with J8 in a runtime less than J8.
“Source Compatibility: Java SE 8 includes new language features and
platform APIs. If these are used in a source file, that source file cannot
be compiled on an earlier version of the Java platform. In general, the
source compatibility policy is to avoid introducing source code
incompatibilities. However, implementation of some Java SE 8 features
required changes that could cause code that compiled with Java SE 7 to
fail to compile with Java SE 8."
My para-phrasing: Once a source module exploits any feature of Java 8 you
must build it with Java 8. Other existing code (that we could refer to
loosely as ‘java 7 code’) may fail to build; so introducing a Java 8 build
environment may require some patching to overcome any resulting compile
errors.
“Java Class Files: The Java class file format has been updated for the
Java SE 8 release. The class file version for Java SE 8 is 52.0 as per the
JVM Specification. Version 52.0 class files produced by a Java SE 8
compiler cannot be used in earlier releases of Java SE.”
My para-phrasing: anything built with Java 8 cannot run on anything less
than Java 8.
My interpretation of the above plus other parts of the Oracle
documentation:
It is expected that the majority of code that has been built and tested in
Java 7 will run in a Java 8 JVM (binary compatibility) and that the
majority of Java 7 code will compile under Java 8 (source compatibility).
However, there are a number of incompatibilities (binary and source)
between Java 7 and 8. Therefore some existing Atlas code that has built in
Java SE 7 may not compile under Java 8 – this should become obvious from
the build. Also, some Atlas code that has been built and run in Java 7 may
not run in a Java 8 runtime. However!! Even if a project could be sure to
avoid any of the binary and source compatibilities, a project built on
Java 8 will not run on Java 7 due to the 52.0 class file format change.
Therefore if we build Atlas with Java 8 – which we’ll need for JanusGraph
– we will then not be able to run that Atlas build on any other JRE lower
than 8.
In my view the safest and preferred option would be to build, test and run
with Java 8; and to spot and patch any source incompatibilities that
introduces. These would be obvious as compile failures. This option would
also enable all Atlas modules to exploit Java 8 features as needed.
The alternative (and less-preferred) option would be to run J7-built
classes in the J8-runtime and identify and patch any additional binary
compatibility issues. These may be harder to identify (than the compile
errors from the previous option) and would not enable any exploitation of
Java 8 features in the Atlas modules still built under ‘J7’.
Best regards,
Graham
Graham Wallis
IBM Analytics Emerging Technology Center
Internet: [email protected]
IBM Laboratories, Hursley Park, Hursley, Hampshire SO21 2JN
Tel: +44-1962-815356 Tie: 7-245356
From: Nigel L Jones <[email protected]>
To: [email protected]
Date: 19/07/2017 14:47
Subject: Re: Maven restructure
I also wanted to bring up the question of how we work with java8 when, for
example, we're building an Atlas stack including Janus. Whilst that code
requires Java 8 (is that for build, runtime or both?) in order to avoid
accidentally breaking the other code for java 7 do we use the "-source
1.7" option to only allow use of Java 1.7 features? Or in fact can we use
1.8 happily for all our code as long as we use "-target 1.7" which should
compile 1.7 compatible bytecode?
It's an area I'm not familar enough with, but just noting we need to
understand/decide on best practice for use of -source and -target.
Nigel.
----
Nigel Jones, Analytics CTO Office - [email protected]
From: David Radley <[email protected]>
To: Graham Wallis <[email protected]>
Cc: [email protected]
Date: 19/07/2017 14:10
Subject: Maven restructure
Hi Graham,
From our discussion yesterday with Hortonworks, ING and IBM, I wanted to
say that your proposal to clean up the Maven dependancies looks great - as
you said this means that we will be able to cleanly add in JanusGraph (the
replacement to Titan).
From what I took from yesterday, Atlas is tied to Hadoop (v2) because of
its dependance on some Hadoop libraries and HBase. Hadoop is tied to java
7. So the only Titan that we can easily use is
Titan 0.5.4 and TP 2. I wonder while you could look to split out the
Hadoop dependancies, as these seem key drivers as to what Java and graphdb
levels we can support. I wonder how compiling with Java 8 for Titan 1 /
Janus deals with the Hadoop libraries and HBase dependancy - are these
recompiled with Java 8 - how legitimate it this approach?
many thanks , David.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
