[Monetdb-developers] XRPCwrapper fails to compile with java 1.4
Hoi,
apparently, the new XPRCwrapper code fails to compile with java 1.4 (our RedHat 4 WS machine, titan, is the only testing machine that still has only java 1.4, all others have java 1.5); for details see below and/or http://monetdb.cwi.nl/testing/projects/monetdb/Stable/pathfinder/.ntv.64.64....
Question: Assuming that there is no easy way to make the new XRPC warpper code java 1.4 compliant: should we modify (tighten) our requirements accordingly, i.e., requiring (only) java 1.5 instead of (at least) java 1.4 to build MonetDB* (java 1.6 is not (yet?) supported)?
Stefan
======== "/usr/local/bin/ant" -f "`readlink -f /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/build.xml" -Dbuilddir="`readlink -f /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/RedHat4WS/src/tools/java" -Djardir="`readlink -f /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/RedHat4WS/src/tools/java" -Dbasedir="`readlink -f /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java" distall
Buildfile: /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/build.xml
distall:
prepare: [echo] Debug is true, optimise is true
compile_util: [echo] Compiling Utilities [javac] Compiling 9 source files to /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/RedHat4WS/src/tools/java [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/NamespaceContextImpl.java:22: package javax.xml.namespace does not exist [javac] import javax.xml.namespace.*; [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/NamespaceContextImpl.java:29: cannot resolve symbol [javac] symbol : class NamespaceContext [javac] location: class nl.cwi.monetdb.xquery.util.NamespaceContextImpl [javac] public class NamespaceContextImpl implements NamespaceContext{ [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:23: package javax.xml.namespace does not exist [javac] import javax.xml.namespace.*; [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:24: package javax.xml.xpath does not exist [javac] import javax.xml.xpath.*; [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:28: package com.sun.org.apache.xml.internal.dtm.ref does not exist [javac] import com.sun.org.apache.xml.internal.dtm.ref.DTMNodeList; [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:372: cannot resolve symbol [javac] symbol : class XPath [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] XPath xPath, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:409: cannot resolve symbol [javac] symbol : class XPath [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] public static NamedNodeMap getNodeAttributes(XPath xPath, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:432: cannot resolve symbol [javac] symbol : class XPath [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] public static String[] getNodeListAttribute(XPath xPath, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:415: cannot resolve symbol [javac] symbol : class DTMNodeList [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] DTMNodeList nodeList = (DTMNodeList) xPath.evaluate(xPathExpr, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:415: cannot resolve symbol [javac] symbol : class DTMNodeList [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] DTMNodeList nodeList = (DTMNodeList) xPath.evaluate(xPathExpr, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:416: cannot resolve symbol [javac] symbol : variable XPathConstants [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] inputSource, XPathConstants.NODESET); [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:439: cannot resolve symbol [javac] symbol : class DTMNodeList [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] DTMNodeList nodeList = (DTMNodeList) xPath.evaluate(xPathExpr, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:439: cannot resolve symbol [javac] symbol : class DTMNodeList [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] DTMNodeList nodeList = (DTMNodeList) xPath.evaluate(xPathExpr, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:440: cannot resolve symbol [javac] symbol : variable XPathConstants [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] inputSource, XPathConstants.NODESET); [javac] ^ [javac] 14 errors
BUILD FAILED /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/build.xml:55: The following error occurred while executing this line: /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/build.xml:107: Compile failed; see the compiler error output for details.
Total time: 6 seconds make[7]: *** [distall_ant_target] Error 1 ========
On 15-10-2007 09:29:29 +0200, Stefan Manegold wrote:
Hoi,
apparently, the new XPRCwrapper code fails to compile with java 1.4 (our RedHat 4 WS machine, titan, is the only testing machine that still has only java 1.4, all others have java 1.5); for details see below and/or http://monetdb.cwi.nl/testing/projects/monetdb/Stable/pathfinder/.ntv.64.64....
Question: Assuming that there is no easy way to make the new XRPC warpper code java 1.4 compliant: should we modify (tighten) our requirements accordingly, i.e., requiring (only) java 1.5 instead of (at least) java 1.4 to build MonetDB* (java 1.6 is not (yet?) supported)?
My analysis:
JDBC needs 1.4<=java<~1.5 XRPCwrapper needs java>=1.5 due to usage of XML standard libraries introduced in Java 1.5 (See the API, which has @since.)
Jennie's build file doesn't correctly state this dependency, but also the JDBC configure check is invalid for XRPCwrapper.
JDBC can't use java>=1.6 (yet) because 1.6 introduced a new interface version of JDBC, v4, which backwards incompatible with the currently implemented interface v3. I once started on a branch to work around this a bit, but it is just a lot of work and I guess my code changes out of date by now given the code was fixed in some points.
Fabian Groffen wrote:
On 15-10-2007 09:29:29 +0200, Stefan Manegold wrote:
Hoi,
apparently, the new XPRCwrapper code fails to compile with java 1.4 (our RedHat 4 WS machine, titan, is the only testing machine that still has only java 1.4, all others have java 1.5); for details see below and/or http://monetdb.cwi.nl/testing/projects/monetdb/Stable/pathfinder/.ntv.64.64....
Question: Assuming that there is no easy way to make the new XRPC warpper code java 1.4 compliant: should we modify (tighten) our requirements accordingly, i.e., requiring (only) java 1.5 instead of (at least) java 1.4 to build MonetDB* (java 1.6 is not (yet?) supported)?
My analysis:
JDBC needs 1.4<=java<~1.5 XRPCwrapper needs java>=1.5 due to usage of XML standard libraries
Intersection is 1.5 ? and sufficient to work?
introduced in Java 1.5 (See the API, which has @since.)
Jennie's build file doesn't correctly state this dependency, but also the JDBC configure check is invalid for XRPCwrapper.
JDBC can't use java>=1.6 (yet) because 1.6 introduced a new interface version of JDBC, v4, which backwards incompatible with the currently implemented interface v3. I once started on a branch to work around this a bit, but it is just a lot of work and I guess my code changes out of date by now given the code was fixed in some points.
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
On 15-10-2007 10:11:51 +0200, Martin Kersten wrote:
My analysis:
JDBC needs 1.4<=java<~1.5 XRPCwrapper needs java>=1.5 due to usage of XML standard libraries
Intersection is 1.5 ? and sufficient to work?
You suggest to force XRPC users to have 1.5 for no reason?
XRPC is pulled out of the clients repo now, so I don't see any reason why it should be tied to the same configure check as we do for clients.
On Mon, Oct 15, 2007 at 10:14:56AM +0200, Fabian Groffen wrote:
On 15-10-2007 10:11:51 +0200, Martin Kersten wrote:
My analysis:
JDBC needs 1.4<=java<~1.5 XRPCwrapper needs java>=1.5 due to usage of XML standard libraries
Intersection is 1.5 ? and sufficient to work?
You suggest to force XRPC users to have 1.5 for no reason?
Did you mean "to force JDBC users to have 1.5 for no reason"? Because XRPC wrapper users will certainly have to use 1.5
XRPC is pulled out of the clients repo now, so I don't see any reason why it should be tied to the same configure check as we do for clients.
You are right. In the bug-fix release, I would like to add a check for Java version, but this doesn't affect JDBC. Making XRPC wrapper Java 1.4 compatable is not a (good) option...
Why is the Redhat machine not upgraded to Java 1.5?
Regards,
Jennie
On 15-10-2007 11:02:09 +0200, Ying Zhang wrote:
On Mon, Oct 15, 2007 at 10:14:56AM +0200, Fabian Groffen wrote:
On 15-10-2007 10:11:51 +0200, Martin Kersten wrote:
My analysis:
JDBC needs 1.4<=java<~1.5 XRPCwrapper needs java>=1.5 due to usage of XML standard libraries
Intersection is 1.5 ? and sufficient to work?
You suggest to force XRPC users to have 1.5 for no reason?
Did you mean "to force JDBC users to have 1.5 for no reason"? Because XRPC wrapper users will certainly have to use 1.5
You force JDBC users to use 1.5, and you force XRPC users to use 1.5. The former could have been satisfied with 1.4 (industrial settings may have this still as the latest "reliable" version), whereas the latter could have been satisfied with 1.6 or 1.7. As Sjoerd pointed out, 1.4 is anchient, so people having 1.6 these days is quite normal.
XRPC is pulled out of the clients repo now, so I don't see any reason why it should be tied to the same configure check as we do for clients.
You are right. In the bug-fix release, I would like to add a check for Java version, but this doesn't affect JDBC. Making XRPC wrapper Java 1.4 compatable is not a (good) option...
your build.properties says you minimally require 1.4 iirc.
Why is the Redhat machine not upgraded to Java 1.5?
That is a workaround ;) But there is a 1.5 installed for the Bond demo. It isn't upgraded, because Sun doesn't provide an 1.5 for Itanium.
Hoi,
I don't consider the fact that our RedHat 4WS machine (titan) has only Java 1.4 a limiting factor and/or reason to for the support of anchient Java 1.4. My main point was to make the software requirements for MonetDB quite clear. Apparently, Java 1.4 is no longer sufficient to compile all part of the MonetDB SW collection. Hence, we should tighten the requirements accordingly. Apparently, Java 1.5 seems to be the only version that allows to compile all MonetDB relates Java code successfully. On systems that do not have Java 1.5, but only Java <= 1.4 (e.g., RedHat 4WS on Itanium) or only Java >= 1.6, the MonetDB-related Java code can hence not be compiled. Since we know this, configure should say so instead of make failing with some strange error. Unfortunately, it's too late for this release, but the will be a next (bug-fix) release.
Stefan
On Mon, Oct 15, 2007 at 11:12:47AM +0200, Fabian Groffen wrote:
On 15-10-2007 11:02:09 +0200, Ying Zhang wrote:
On Mon, Oct 15, 2007 at 10:14:56AM +0200, Fabian Groffen wrote:
On 15-10-2007 10:11:51 +0200, Martin Kersten wrote:
My analysis:
JDBC needs 1.4<=java<~1.5 XRPCwrapper needs java>=1.5 due to usage of XML standard libraries
Intersection is 1.5 ? and sufficient to work?
You suggest to force XRPC users to have 1.5 for no reason?
Did you mean "to force JDBC users to have 1.5 for no reason"? Because XRPC wrapper users will certainly have to use 1.5
You force JDBC users to use 1.5, and you force XRPC users to use 1.5. The former could have been satisfied with 1.4 (industrial settings may have this still as the latest "reliable" version), whereas the latter could have been satisfied with 1.6 or 1.7. As Sjoerd pointed out, 1.4 is anchient, so people having 1.6 these days is quite normal.
XRPC is pulled out of the clients repo now, so I don't see any reason why it should be tied to the same configure check as we do for clients.
You are right. In the bug-fix release, I would like to add a check for Java version, but this doesn't affect JDBC. Making XRPC wrapper Java 1.4 compatable is not a (good) option...
your build.properties says you minimally require 1.4 iirc.
Why is the Redhat machine not upgraded to Java 1.5?
That is a workaround ;) But there is a 1.5 installed for the Bond demo. It isn't upgraded, because Sun doesn't provide an 1.5 for Itanium.
On 16-10-2007 07:44:47 +0200, Stefan Manegold wrote:
Hoi,
Hi,
I don't consider the fact that our RedHat 4WS machine (titan) has only Java 1.4 a limiting factor and/or reason to for the support of anchient Java 1.4. My main point was to make the software requirements for MonetDB quite clear. Apparently, Java 1.4 is no longer sufficient to compile all part of the MonetDB SW collection. Hence, we should tighten the requirements accordingly. Apparently, Java 1.5 seems to be the only version that allows to compile all MonetDB relates Java code successfully. On systems that do not have Java 1.5, but only Java <= 1.4 (e.g., RedHat 4WS on Itanium) or only Java >= 1.6, the MonetDB-related Java code can hence not be compiled. Since we know this, configure should say so instead of make failing with some strange error.
Yeah, and my main point is that it seems unreasonable to me to *have* to use *one* configure check for all sub-projects involved. clients can remain as-is. pathfinder just needs a check for 1.5 and up. Forcing 1.5 for all sub-projects sounds unreasonable and pointless to me.
Unfortunately, it's too late for this release, but the will be a next (bug-fix) release.
Neither did I want to suggest so.
Hoi,
for after the release, I have the attached patch ready.
Stefan
On Tue, Oct 16, 2007 at 08:08:36AM +0200, Fabian Groffen wrote:
On 16-10-2007 07:44:47 +0200, Stefan Manegold wrote:
Hoi,
Hi,
I don't consider the fact that our RedHat 4WS machine (titan) has only Java 1.4 a limiting factor and/or reason to for the support of anchient Java 1.4. My main point was to make the software requirements for MonetDB quite clear. Apparently, Java 1.4 is no longer sufficient to compile all part of the MonetDB SW collection. Hence, we should tighten the requirements accordingly. Apparently, Java 1.5 seems to be the only version that allows to compile all MonetDB relates Java code successfully. On systems that do not have Java 1.5, but only Java <= 1.4 (e.g., RedHat 4WS on Itanium) or only Java >= 1.6, the MonetDB-related Java code can hence not be compiled. Since we know this, configure should say so instead of make failing with some strange error.
Yeah, and my main point is that it seems unreasonable to me to *have* to use *one* configure check for all sub-projects involved. clients can remain as-is. pathfinder just needs a check for 1.5 and up. Forcing 1.5 for all sub-projects sounds unreasonable and pointless to me.
Unfortunately, it's too late for this release, but the will be a next (bug-fix) release.
Neither did I want to suggest so.
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
On 16-10-2007 08:32:49 +0200, Stefan Manegold wrote:
Hoi,
for after the release, I have the attached patch ready.
I have included some comments on your patch.
Index: buildtools/conf/MonetDB.m4
RCS file: /cvsroot/monetdb/buildtools/conf/MonetDB.m4,v retrieving revision 1.37.2.6 diff -u -r1.37.2.6 MonetDB.m4 --- buildtools/conf/MonetDB.m4 14 Oct 2007 09:09:40 -0000 1.37.2.6 +++ buildtools/conf/MonetDB.m4 16 Oct 2007 06:30:22 -0000 @@ -437,6 +437,12 @@ AC_DEFUN([AM_MONETDB_COMPILER], [
+if test "x$1" = "x"; then
- JAVA_REQUIRED_VERSION="1.4"
+else
- JAVA_REQUIRED_VERSION="$1"
+fi
(pseudo) JAVA_REQ_MIN_VERSION=${JAVA_REQ_MIN_VERSION:-1.4} unset JAVA_REQ_MAX_VERSION
AC_PROG_CPP() dnl check for compiler (also set GCC (yes/no)). AC_PROG_CC() @@ -954,23 +960,23 @@ if test "x$have_java" != xno; then AC_PATH_PROG(JAVA,java,,$JPATH) if test "x$JAVA" != "x"; then
- AC_MSG_CHECKING([for Java >= 1.4, but < 1.6])
- AC_MSG_CHECKING([for Java >= $JAVA_REQUIRED_VERSION, but < 1.6])
if test "x$JAVA_REQ_MAX_VERSION" = "x" ; then AC_MSG_CHECKING([for Java >= $JAVA_REQ_MIN_VERSION]) do_logic else AC_MSG_CHECKING([for Java >= $JAVA_REQ_MIN_VERSION, but <= $JAVA_REQ_MAX_VERSION]) do_logic fi
[snip]
Index: pathfinder/configure.ag
RCS file: /cvsroot/monetdb/pathfinder/configure.ag,v retrieving revision 1.116.2.2 diff -u -r1.116.2.2 configure.ag --- pathfinder/configure.ag 20 Sep 2007 11:42:54 -0000 1.116.2.2 +++ pathfinder/configure.ag 16 Oct 2007 06:30:22 -0000 @@ -72,7 +72,8 @@
dnl must check for compiler before checking for MonetDB4 AM_MONETDB_DEFAULTS() -AM_MONETDB_COMPILER() +req_java_ver=1.5 +AM_MONETDB_COMPILER($req_java_ver)
req_min_java_ver="1.5" AM_MONETDB_COMPILER($req_min_java_ver)
Index: clients/configure.ag ============================
req_min_java_ver="1.4" req_max_java_ver="1.5" AM_MONETDB_COMPILER($req_min_java_ver $req_max_java_ver)
Stefan Manegold wrote:
Hoi,
for after the release, I have the attached patch ready.
I fear this may not be enough.
Both JDBC and XRPCwrapper only work (the latter only compiles) with Sun Java, not with gcj. So we should also test for that.
As a case in point, at home I couldn't compile xrpcwrapper since I don't have Sun Java installed.
Stefan
On Tue, Oct 16, 2007 at 08:08:36AM +0200, Fabian Groffen wrote:
On 16-10-2007 07:44:47 +0200, Stefan Manegold wrote:
Hoi,
Hi,
I don't consider the fact that our RedHat 4WS machine (titan) has only Java 1.4 a limiting factor and/or reason to for the support of anchient Java 1.4. My main point was to make the software requirements for MonetDB quite clear. Apparently, Java 1.4 is no longer sufficient to compile all part of the MonetDB SW collection. Hence, we should tighten the requirements accordingly. Apparently, Java 1.5 seems to be the only version that allows to compile all MonetDB relates Java code successfully. On systems that do not have Java 1.5, but only Java <= 1.4 (e.g., RedHat 4WS on Itanium) or only Java >= 1.6, the MonetDB-related Java code can hence not be compiled. Since we know this, configure should say so instead of make failing with some strange error.
Yeah, and my main point is that it seems unreasonable to me to *have* to use *one* configure check for all sub-projects involved. clients can remain as-is. pathfinder just needs a check for 1.5 and up. Forcing 1.5 for all sub-projects sounds unreasonable and pointless to me.
Unfortunately, it's too late for this release, but the will be a next (bug-fix) release.
Neither did I want to suggest so.
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
On Tue, Oct 16, 2007 at 09:48:58AM +0200, Sjoerd Mullender wrote:
Stefan Manegold wrote:
Hoi,
for after the release, I have the attached patch ready.
I fear this may not be enough.
Both JDBC and XRPCwrapper only work (the latter only compiles) with Sun Java, not with gcj. So we should also test for that.
As a case in point, at home I couldn't compile xrpcwrapper since I don't have Sun Java installed.
XRPC wrapper should at least compile with gcj. This will be fixed in the next bug-release. I will also try to get it work with gcj as well.
Jennie
Stefan
On Tue, Oct 16, 2007 at 08:08:36AM +0200, Fabian Groffen wrote:
On 16-10-2007 07:44:47 +0200, Stefan Manegold wrote:
Hoi,
Hi,
I don't consider the fact that our RedHat 4WS machine (titan) has only Java 1.4 a limiting factor and/or reason to for the support of anchient Java 1.4. My main point was to make the software requirements for MonetDB quite clear. Apparently, Java 1.4 is no longer sufficient to compile all part of the MonetDB SW collection. Hence, we should tighten the requirements accordingly. Apparently, Java 1.5 seems to be the only version that allows to compile all MonetDB relates Java code successfully. On systems that do not have Java 1.5, but only Java <= 1.4 (e.g., RedHat 4WS on Itanium) or only Java >= 1.6, the MonetDB-related Java code can hence not be compiled. Since we know this, configure should say so instead of make failing with some strange error.
Yeah, and my main point is that it seems unreasonable to me to *have* to use *one* configure check for all sub-projects involved. clients can remain as-is. pathfinder just needs a check for 1.5 and up. Forcing 1.5 for all sub-projects sounds unreasonable and pointless to me.
Unfortunately, it's too late for this release, but the will be a next (bug-fix) release.
Neither did I want to suggest so.
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
-- Sjoerd Mullender
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
Stefan Manegold wrote:
Hoi,
apparently, the new XPRCwrapper code fails to compile with java 1.4 (our RedHat 4 WS machine, titan, is the only testing machine that still has only java 1.4, all others have java 1.5); for details see below and/or http://monetdb.cwi.nl/testing/projects/monetdb/Stable/pathfinder/.ntv.64.64....
Question: Assuming that there is no easy way to make the new XRPC warpper code java 1.4 compliant: should we modify (tighten) our requirements accordingly, i.e., requiring (only) java 1.5 instead of (at least) java 1.4 to build MonetDB* (java 1.6 is not (yet?) supported)?
I'd say, whatever we do, we do it after the release.
I can't comment on the actual issue: I don't know how difficult it is to support Java 1.4. On the other hand, Java 1.4 is ancient, so we don't really need to support it, so I'm also happy with tightening the requirements.
Stefan
======== "/usr/local/bin/ant" -f "`readlink -f /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/build.xml" -Dbuilddir="`readlink -f /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/RedHat4WS/src/tools/java" -Djardir="`readlink -f /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/RedHat4WS/src/tools/java" -Dbasedir="`readlink -f /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java" distall
Buildfile: /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/build.xml
distall:
prepare: [echo] Debug is true, optimise is true
compile_util: [echo] Compiling Utilities [javac] Compiling 9 source files to /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/RedHat4WS/src/tools/java [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/NamespaceContextImpl.java:22: package javax.xml.namespace does not exist [javac] import javax.xml.namespace.*; [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/NamespaceContextImpl.java:29: cannot resolve symbol [javac] symbol : class NamespaceContext [javac] location: class nl.cwi.monetdb.xquery.util.NamespaceContextImpl [javac] public class NamespaceContextImpl implements NamespaceContext{ [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:23: package javax.xml.namespace does not exist [javac] import javax.xml.namespace.*; [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:24: package javax.xml.xpath does not exist [javac] import javax.xml.xpath.*; [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:28: package com.sun.org.apache.xml.internal.dtm.ref does not exist [javac] import com.sun.org.apache.xml.internal.dtm.ref.DTMNodeList; [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:372: cannot resolve symbol [javac] symbol : class XPath [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] XPath xPath, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:409: cannot resolve symbol [javac] symbol : class XPath [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] public static NamedNodeMap getNodeAttributes(XPath xPath, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:432: cannot resolve symbol [javac] symbol : class XPath [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] public static String[] getNodeListAttribute(XPath xPath, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:415: cannot resolve symbol [javac] symbol : class DTMNodeList [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] DTMNodeList nodeList = (DTMNodeList) xPath.evaluate(xPathExpr, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:415: cannot resolve symbol [javac] symbol : class DTMNodeList [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] DTMNodeList nodeList = (DTMNodeList) xPath.evaluate(xPathExpr, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:416: cannot resolve symbol [javac] symbol : variable XPathConstants [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] inputSource, XPathConstants.NODESET); [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:439: cannot resolve symbol [javac] symbol : class DTMNodeList [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] DTMNodeList nodeList = (DTMNodeList) xPath.evaluate(xPathExpr, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:439: cannot resolve symbol [javac] symbol : class DTMNodeList [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] DTMNodeList nodeList = (DTMNodeList) xPath.evaluate(xPathExpr, [javac] ^ [javac] /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/src/nl/cwi/monetdb/xquery/util/XRPCMessage.java:440: cannot resolve symbol [javac] symbol : variable XPathConstants [javac] location: class nl.cwi.monetdb.xquery.util.XRPCMessage [javac] inputSource, XPathConstants.NODESET); [javac] ^ [javac] 14 errors
BUILD FAILED /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/build.xml:55: The following error occurred while executing this line: /export/scratch1/monet/monet.ntv.64.64.d.8915/pathfinder/src/tools/java/build.xml:107: Compile failed; see the compiler error output for details.
Total time: 6 seconds make[7]: *** [distall_ant_target] Error 1 ========
participants (5)
-
Fabian Groffen -
Martin Kersten -
Sjoerd Mullender -
Stefan Manegold -
Ying Zhang