Re: Maven restructure
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
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
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
