Re: Maven restructure

2017-07-24 Thread Nigel Jones

On 19/07/2017 16:45, David Radley wrote:


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.


It's probably worth creating a subtask, or separate JIRA for the 
specific data migration work.


Initially I think we can allow Janus only for new users, with existing 
users continuing to use titan 0.54 ... but at some point - in fact as 
soon as practical.. though this may be after hadoop 3 .. we should 
deprecate 0.54 & so need to get those customer's data forward migrated.


Additionally doing this even earlier than needed for hadoop helps to 
cement JanusGraph as the graph tech of choice in Atlas :-), though I'm 
unsure how many Atlas users there are currently, with production data, 
using titan 0.54 outside hadoop.


NIgel.



Re: Maven restructure

2017-07-19 Thread David Radley
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 <graham_wal...@uk.ibm.com>
To: dev@atlas.apache.org
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: graham_wal...@uk.ibm.com 
IBM Laboratories, Hursley Park, Hursley, Hampshire SO21 2JN
Tel: +44-1962-815356Tie: 7-245356




From:   Nigel L Jones <jon...@uk.ibm.com>
To: dev@atlas.apache.org
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 includ

Re: Maven restructure

2017-07-19 Thread Graham Wallis
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: graham_wal...@uk.ibm.com 
IBM Laboratories, Hursley Park, Hursley, Hampshire SO21 2JN
Tel: +44-1962-815356Tie: 7-245356




From:   Nigel L Jones <jon...@uk.ibm.com>
To: dev@atlas.apache.org
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 - jon...@uk.ibm.com



From:   David Radley <david_rad...@uk.ibm.com>
To: Graham Wallis <dev@atlas.apache.org>
Cc: dev@atlas.apache.org
Date:   19/07/2