[libvirt] (no subject)
The current code of libvirt-java does not build with Java 7. This patch updates the build.properties and INSTALL that we require Java 8 to build libvirt-java.
Signed-off-by: Wido den Hollander <wido@widodh.nl> --- INSTALL | 2 +- build.properties | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/INSTALL b/INSTALL index 581512d..2cdd829 100644 --- a/INSTALL +++ b/INSTALL @@ -11,7 +11,7 @@ main item you may need to change in this file is the jars.dir property. This property should point to a directory which contains the junit.jar and jna.jar files. -You will need a Java Development Kit accepting the version 1.6 +You will need a Java Development Kit accepting the version 1.8 of the language since the bindings use enums as well as the new for loop syntax diff --git a/build.properties b/build.properties index bcc7b8c..c7c1a43 100644 --- a/build.properties +++ b/build.properties @@ -1,8 +1,8 @@ version=0.5.1 release=1 libvirt.required=0.9.12 -java.required=1.6.0 -java.target=1.6 -java.source=1.6 +java.required=1.8.0 +java.target=1.8 +java.source=1.8 rpm.topdir=/home/veillard/rpms jar.dir=/usr/share/java -- 1.9.1
On 28.08.2015 13:12, Wido den Hollander wrote:
Signed-off-by: Wido den Hollander <wido@widodh.nl> --- INSTALL | 2 +- build.properties | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/INSTALL b/INSTALL index 581512d..2cdd829 100644 --- a/INSTALL +++ b/INSTALL @@ -11,7 +11,7 @@ main item you may need to change in this file is the jars.dir property. This property should point to a directory which contains the junit.jar and jna.jar files.
-You will need a Java Development Kit accepting the version 1.6 +You will need a Java Development Kit accepting the version 1.8 of the language since the bindings use enums as well as the new for loop syntax
diff --git a/build.properties b/build.properties index bcc7b8c..c7c1a43 100644 --- a/build.properties +++ b/build.properties @@ -1,8 +1,8 @@ version=0.5.1 release=1 libvirt.required=0.9.12 -java.required=1.6.0 -java.target=1.6 -java.source=1.6 +java.required=1.8.0 +java.target=1.8 +java.source=1.8 rpm.topdir=/home/veillard/rpms jar.dir=/usr/share/java
I know nothing about libvirt-java, but maybe you can be more verbose why this change is needed. Michal
On 02-09-15 13:11, Michal Privoznik wrote:
On 28.08.2015 13:12, Wido den Hollander wrote:
Signed-off-by: Wido den Hollander <wido@widodh.nl> --- INSTALL | 2 +- build.properties | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/INSTALL b/INSTALL index 581512d..2cdd829 100644 --- a/INSTALL +++ b/INSTALL @@ -11,7 +11,7 @@ main item you may need to change in this file is the jars.dir property. This property should point to a directory which contains the junit.jar and jna.jar files.
-You will need a Java Development Kit accepting the version 1.6 +You will need a Java Development Kit accepting the version 1.8 of the language since the bindings use enums as well as the new for loop syntax
diff --git a/build.properties b/build.properties index bcc7b8c..c7c1a43 100644 --- a/build.properties +++ b/build.properties @@ -1,8 +1,8 @@ version=0.5.1 release=1 libvirt.required=0.9.12 -java.required=1.6.0 -java.target=1.6 -java.source=1.6 +java.required=1.8.0 +java.target=1.8 +java.source=1.8 rpm.topdir=/home/veillard/rpms jar.dir=/usr/share/java
I know nothing about libvirt-java, but maybe you can be more verbose why this change is needed.
The current code doesn't compile under Java 7, but Java 7 is also EOL. Java 8 is the way forward since there won't be any security fixes for Java 7 anymore. Wido
Michal
On Wed, Sep 2, 2015 at 1:53 PM, Wido den Hollander <wido@widodh.nl> wrote:
I know nothing about libvirt-java, but maybe you can be more verbose why this change is needed.
The current code doesn't compile under Java 7, but Java 7 is also EOL.
That should not be the case. Can you provide the error messages or simply point to the place where Java 8 classes are used? Java 8 is the way forward since there won't be any security fixes for
Java 7 anymore.
Yes, but maybe there're some distributions / organizations which still depend on Java 7 or 6. I don't want to raise the bar without good reason. -- Claudio
On 02-09-15 14:57, Claudio Bley wrote:
On Wed, Sep 2, 2015 at 1:53 PM, Wido den Hollander <wido@widodh.nl <mailto:wido@widodh.nl>> wrote:
> I know nothing about libvirt-java, but maybe you can be more verbose why > this change is needed. >
The current code doesn't compile under Java 7, but Java 7 is also EOL.
That should not be the case. Can you provide the error messages or simply point to the place where Java 8 classes are used?
build: [javac] Compiling 98 source files to /home/wido/repos/libvirt-java/target/classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.7 [javac] /home/wido/repos/libvirt-java/src/main/java/org/libvirt/event/DomainEvent.java:63: error: incompatible types: inference variable T#1 has incompatible upper bounds Enum<T#2>,T#3 [javac] return this.type.obtain(this.detail); [javac] ^ [javac] where T#1,T#2,T#3 are type-variables: [javac] T#1 extends Enum<T#1> declared in method <T#1>obtain(int) [javac] T#2 extends T#3 [javac] T#3 extends Enum<T#3>,DomainEventDetail declared in method <T#3>getDetail() [javac] 1 error [javac] 1 warning
Java 8 is the way forward since there won't be any security fixes for Java 7 anymore.
Yes, but maybe there're some distributions / organizations which still depend on Java 7 or 6. I don't want to raise the bar without good reason.
Ok, fair enough. I think that Java 8 is fine since that is available in the major distributions. But if the compile issue can be fixed we can probably require at least Java 7. I think Java 6 is dangerous. Wido
-- Claudio
At Wed, 2 Sep 2015 17:38:03 +0200, Wido den Hollander wrote:
The current code doesn't compile under Java 7, but Java 7 is also EOL.
That should not be the case. Can you provide the error messages or simply point to the place where Java 8 classes are used?
build: [javac] Compiling 98 source files to /home/wido/repos/libvirt-java/target/classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.7 [javac] /home/wido/repos/libvirt-java/src/main/java/org/libvirt/event/DomainEvent.java:63: error: incompatible types: inference variable T#1 has incompatible upper bounds Enum<T#2>,T#3 [javac] return this.type.obtain(this.detail); [javac] ^ [javac] where T#1,T#2,T#3 are type-variables: [javac] T#1 extends Enum<T#1> declared in method <T#1>obtain(int) [javac] T#2 extends T#3 [javac] T#3 extends Enum<T#3>,DomainEventDetail declared in method <T#3>getDetail() [javac] 1 error [javac] 1 warning
This reminded me of a problem I once saw with the Java 7 (I think) compiler being unable to correctly infer the types when calling static generic methods. Since I always used the Java 7 compiler to compile the code and as I saw the javac warning above, I got curious. The thing is: the code compiles just fine with an actual Java 7 compiler (OpenJDK 1.7.0_85), but not when using a Java 8 compiler (OpenJDK 1.8.0_60) with the `-source 1.7` switch.
But if the compile issue can be fixed we can probably require at least Java 7. I think Java 6 is dangerous.
I'm still thinking about this. Maybe you're right. But still, the code is valid 1.7 source code. Should we prevent that code from compiling on Java 7 to protect users from using an obsolete JVM? I don't think this is the right place to control that. -- Claudio --
On 04-09-15 07:12, Claudio Bley wrote:
At Wed, 2 Sep 2015 17:38:03 +0200, Wido den Hollander wrote:
The current code doesn't compile under Java 7, but Java 7 is also EOL.
That should not be the case. Can you provide the error messages or simply point to the place where Java 8 classes are used?
build: [javac] Compiling 98 source files to /home/wido/repos/libvirt-java/target/classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.7 [javac] /home/wido/repos/libvirt-java/src/main/java/org/libvirt/event/DomainEvent.java:63: error: incompatible types: inference variable T#1 has incompatible upper bounds Enum<T#2>,T#3 [javac] return this.type.obtain(this.detail); [javac] ^ [javac] where T#1,T#2,T#3 are type-variables: [javac] T#1 extends Enum<T#1> declared in method <T#1>obtain(int) [javac] T#2 extends T#3 [javac] T#3 extends Enum<T#3>,DomainEventDetail declared in method <T#3>getDetail() [javac] 1 error [javac] 1 warning
This reminded me of a problem I once saw with the Java 7 (I think) compiler being unable to correctly infer the types when calling static generic methods.
Since I always used the Java 7 compiler to compile the code and as I saw the javac warning above, I got curious.
The thing is: the code compiles just fine with an actual Java 7 compiler (OpenJDK 1.7.0_85), but not when using a Java 8 compiler (OpenJDK 1.8.0_60) with the `-source 1.7` switch.
Ah, indeed. I'm using the Oracle Java 8 JDK and not OpenJDK.
But if the compile issue can be fixed we can probably require at least Java 7. I think Java 6 is dangerous.
I'm still thinking about this. Maybe you're right. But still, the code is valid 1.7 source code. Should we prevent that code from compiling on Java 7 to protect users from using an obsolete JVM? I don't think this is the right place to control that.
No, we can probably depend on Java 7, but we should update the README that it doesn't compile properly on Oracle's JDK and you should use OpenJDK. Wido
-- Claudio
At Mon, 7 Sep 2015 11:36:38 +0200, Wido den Hollander wrote:
On 04-09-15 07:12, Claudio Bley wrote:
The thing is: the code compiles just fine with an actual Java 7 compiler (OpenJDK 1.7.0_85), but not when using a Java 8 compiler (OpenJDK 1.8.0_60) with the `-source 1.7` switch.
Ah, indeed. I'm using the Oracle Java 8 JDK and not OpenJDK.
But if the compile issue can be fixed we can probably require at least Java 7. I think Java 6 is dangerous.
I'm still thinking about this. Maybe you're right. But still, the code is valid 1.7 source code. Should we prevent that code from compiling on Java 7 to protect users from using an obsolete JVM? I don't think this is the right place to control that.
we should update the README that it doesn't compile properly on Oracle's JDK and you should use OpenJDK.
But that's not the problem. The problem is that the JDK 1.8 compiler has a different understanding of what valid 1.7 (or 1.6) Java code is in regard to a real 1.7 (or 1.6) compiler. I resolved it differently[1] now and just simplified the code to make the 1.8 and 1.7 compiler happy when specifying a different Java source conformance level than the default of the compiler itself. Regards, Claudio [1]: http://www.redhat.com/archives/libvir-list/2015-September/msg00413.html --
participants (3)
-
Claudio Bley -
Michal Privoznik -
Wido den Hollander