You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2013/08/26 12:04:13 UTC
jena-jdbc : JDJK6->JDK7-ism?
I'm getting the following compile time error when building with maven.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project jena-jdbc-core: Compilation failure:
Compilation failure:
[ERROR]
/home/afs/Jena/jena-jdbc/jena-jdbc-core/src/main/java/org/apache/jena/jdbc/metadata/results/MetaResultSet.java:[51,8]
org.apache.jena.jdbc.metadata.results.MetaResultSet is not abstract and
does not override abstract method
<T>getObject(java.lang.String,java.lang.Class<T>) in java.sql.ResultSet
and then some others.
Maybe it's this:
http://stackoverflow.com/questions/7692320/is-there-really-resultset-getobjectstring-classt-in-jdk7
I'm using a Java7 compiler in Java6 mode so it's the JDK7 runtime.
If so, the fix is to add, without @Override but with suppressed warnings:
<T> T getObject(int columnIndex, Class<T> type) throws SQLException
<T> T getObject(String columnLabel, Class<T> type) throws SQLException
Andy
RE: jena-jdbc : JDJK6->JDK7-ism?
Posted by David Jordan <Da...@sas.com>.
Yes, I ran into the same issue and "fix" in some of my non-Jena work.
-----Original Message-----
From: Andy Seaborne [mailto:andy@apache.org]
Sent: Monday, August 26, 2013 6:04 AM
To: dev@jena.apache.org
Subject: jena-jdbc : JDJK6->JDK7-ism?
I'm getting the following compile time error when building with maven.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project jena-jdbc-core: Compilation failure:
Compilation failure:
[ERROR]
/home/afs/Jena/jena-jdbc/jena-jdbc-core/src/main/java/org/apache/jena/jdbc/metadata/results/MetaResultSet.java:[51,8]
org.apache.jena.jdbc.metadata.results.MetaResultSet is not abstract and does not override abstract method
<T>getObject(java.lang.String,java.lang.Class<T>) in java.sql.ResultSet
and then some others.
Maybe it's this:
http://stackoverflow.com/questions/7692320/is-there-really-resultset-getobjectstring-classt-in-jdk7
I'm using a Java7 compiler in Java6 mode so it's the JDK7 runtime.
If so, the fix is to add, without @Override but with suppressed warnings:
<T> T getObject(int columnIndex, Class<T> type) throws SQLException <T> T getObject(String columnLabel, Class<T> type) throws SQLException
Andy
Re: jena-jdbc : JDJK6->JDK7-ism?
Posted by Andy Seaborne <an...@apache.org>.
more info:
Load average minimal (just Thunderbird frantically indexing email)
"netstat --tcp" shows 579 connections all involving port 3535, the test
port.
And they don't all got away immediately when maven exits - things need
to timeout.
Andy
Sample (edited for email):
All are 0/1 except for the 2142 shown:
...
2142 0 localhost:3535 localhost:39332 ESTABLISHED
1 0 localhost:37927 localhost:3535 CLOSE_WAIT
0 0 localhost:3535 localhost:38990 ESTABLISHED
0 0 localhost:3535 localhost:39035 ESTABLISHED
1 0 localhost:37931 localhost:3535 CLOSE_WAIT
0 0 localhost:39238 localhost:3535 ESTABLISHED
1 0 localhost:37922 localhost:3535 CLOSE_WAIT
0 0 localhost:39040 localhost:3535 ESTABLISHED
0 0 localhost:39199 localhost:3535 ESTABLISHED
0 0 localhost:3535 localhost:39133 ESTABLISHED
0 0 localhost:39016 localhost:3535 ESTABLISHED
0 0 localhost:3535 localhost:39280 ESTABLISHED
0 0 localhost:39165 localhost:3535 ESTABLISHED
0 0 localhost:38993 localhost:3535 ESTABLISHED
0 0 localhost:39147 localhost:3535 ESTABLISHED
0 0 localhost:39071 localhost:3535 ESTABLISHED
...
> I was using:
>
> java version "1.6.0_27"
> OpenJDK Runtime Environment (IcedTea6 1.12.6)
> (6b27-1.12.6-1ubuntu0.13.04.2)
> OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
>
> I have now tried with
>
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>
> and get the same hang.
>
> Andy
RE: jena-jdbc : JDJK6->JDK7-ism?
Posted by Rob Vesse <rv...@yarcdata.com>.
Sounds sensible, I will try and take a look Monday
Rob
________________________________________
From: Andy Seaborne [andy@apache.org]
Sent: 31 August 2013 04:28
To: dev@jena.apache.org
Subject: Re: jena-jdbc : JDJK6->JDK7-ism?
Some progress.
I have a version of the test suite that runs, without inserted pauses,
in Java6 and Java7.
It's not perfect - you can't always run the test suite immediately after
it's just run. It may need a couple of minutes between runs for all the
sockets in TIME_WAIT timeout (the JVM has exited - this is kernel
resources). Sometimes, just the later tests (mem, TDB) is long enough
and test can be run back-to-back.
The change is that there are now operations in HttpOp to get/set the
default HttpClient.
Hackery in AbstractRemoteEndpointResultSetTests sets a single default
caching HttpClient used for all non-auth tests (HttpOp does not use the
default HttpClient for auth requests so as to get containment).
I was confused by the fact that TS_JdbcDriverRemote isn't called by maven.
I have created
https://issues.apache.org/jira/browse/JENA-527
and attached a patch.
The entire "mvn clean test" of jena-jdbc takes 5m15s. The longest part
is the TDB tests (4m30s).
This needs reviewing in case I have compromised testing, and also
testing on other machines.
Rob - is this an acceptable/useful thing to do for the jena-jdbc tests?
Andy
Re: jena-jdbc : JDJK6->JDK7-ism?
Posted by Andy Seaborne <an...@apache.org>.
Some progress.
I have a version of the test suite that runs, without inserted pauses,
in Java6 and Java7.
It's not perfect - you can't always run the test suite immediately after
it's just run. It may need a couple of minutes between runs for all the
sockets in TIME_WAIT timeout (the JVM has exited - this is kernel
resources). Sometimes, just the later tests (mem, TDB) is long enough
and test can be run back-to-back.
The change is that there are now operations in HttpOp to get/set the
default HttpClient.
Hackery in AbstractRemoteEndpointResultSetTests sets a single default
caching HttpClient used for all non-auth tests (HttpOp does not use the
default HttpClient for auth requests so as to get containment).
I was confused by the fact that TS_JdbcDriverRemote isn't called by maven.
I have created
https://issues.apache.org/jira/browse/JENA-527
and attached a patch.
The entire "mvn clean test" of jena-jdbc takes 5m15s. The longest part
is the TDB tests (4m30s).
This needs reviewing in case I have compromised testing, and also
testing on other machines.
Rob - is this an acceptable/useful thing to do for the jena-jdbc tests?
Andy
Re: jena-jdbc : JDJK6->JDK7-ism?
Posted by Andy Seaborne <an...@apache.org>.
Rob,
I've tried to investigate the remote testing.
No conclusion I'm afraid.
I made two changes locally:
* removed the Thread.sleep(250)'s
* put ServerTest.freeServer(); / server.stop after closing the
connection in each @AfterClass
The test pass fast on java7 but lock up on java6.
For java6, there are 506 sockets (253 TCP connections) in state
ESTABLISHED.
506 is the critical number.
Putting the Thread.sleep's does not make any difference (excpet it's
slower :-) -- freezes with 506 sockets ESTABLISHED.
For java7, it climbs but I did see it over 400 and it was always
changing - tests making progress.
I tried tracing TCP connections by using "netstat -n" with debug
breakpoints.
In TestRemoteEndpointResults
** public void results_select_numeric_01()
# netstat : Zero connections at this point
ResultSet rset = this.createResults(ds, ..)
# netstat : a pair of sockets (one TCP connection)
rset.close()
# netstat : no sockets ESTABLISHED
# sometimes in TIME_WAIT but that delay is quite short before they go.
ServerTest.resetServer();
afterwards two connections ESTABLISHED : this is bad!
** public void results_select_numeric_02()
# netstat : Two sockets / 1 TCP conenction
ResultSet rset = this.createResults(
# netstat : Six sockets / 3 TCP connections (this is odd! why not 4?)
rset.close()
# netstat : Four sockets / 2 TCP connections
ServerTest.resetServer();
now 3 TCP conenctions: this is bad^2!
So I tried to the sequence of actions in a standalone program:
String service = "http://localhost:3535/dataset/data" ;
ServerTest.allocServer();
DatasetAccessor dacc = DatasetAccessorFactory.createHTTP(service) ;
Model m = RDFDataMgr.loadModel("file:D.ttl") ;
dacc.add(m);
ServerTest.resetServer();
dacc = DatasetAccessorFactory.createHTTP(service) ;
dacc.add(m);
ServerTest.resetServer();
ServerTest.freeServer();
but at no point did I see any ESTABLISHED connections remaining.
Other::
I noticed that SelectResults does not close the innerResults object -
it's a ResultSetPeekable which is not closeable.
Adding debugging code to exhaust the stream:
public void closeStreamInternal() throws SQLException {
if (this.innerResults != null) {
int i = 0 ;
try {
for ( ; innerResults.hasNext() ; ) {
innerResults.next();
i++ ;
}
} catch (Exception ex) {
System.err.println(ex) ;
}
System.err.println("i = "+i) ;
if (this.innerResults instanceof Closeable) {
((Closeable) this.innerResults).close();
}
this.innerResults = null;
}
}
Sometimes "i" is not zero (it's 12).
And when it isn't zero, there is an exception : somewhere in XML
processing via XMLInputStAX.
It looks like the stream is getting closed early, maybe aynchronously
(or far end?). The XMLInputStAX code has seen a tag and is reading the
content so it's an incomplete result set.
Andy
Re: jena-jdbc : JDJK6->JDK7-ism?
Posted by Andy Seaborne <an...@apache.org>.
On 29/08/13 01:09, Rob Vesse wrote:
> Andy
>
> If you can commit your changes that would be great, then I can go over
> them and see which if any we can implement properly.
Already done.
> The part of the build that was messy explicitly is testing that
> configuring logging via driver parameters works, I have modified that
> portion of the tests to redirect stdout to a ByteArrayOutputStream so I
> can verify that the logging output gets enabled without polluting the mvn
> build output. Some of the tests are explicit negative tests looking for
> error conditions being properly propagated hence why all the logging noise
> on that part of the test run. This should however now be hidden from the
> build.
>
> The remote endpoint results tests seem to be the prime culprits for hangs,
It's always TestRemoteEndpointResults for me.
> those are the tests that do the most bringing up and tearing down of
> Fuseki instances with associated HTTP traffic and seems to be the ones
> that most often hang on Jenkins. They should maintain a single Fuseki
> instance for each class so the problem may lie more in the volume of HTTP
> traffic involved, that's why there is the Thread.sleep() in those tests
> which mitigates the problem some of the time.
Could we group the tests together and have one server for the sub-suite?
> Which version of Java 6 causes hangs for you? We run 1.6.0_51 (Oracle
> standard Hotspot JVM)
I was using:
java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1ubuntu0.13.04.2)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
I have now tried with
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
and get the same hang.
Andy
>
> Rob
>
>
> On 8/28/13 3:34 PM, "Andy Seaborne" <an...@apache.org> wrote:
>
>> Rob -
>>
>> I have had a go at fixing them so jena-jdbc compiles on Java7. This is
>> done by adding missing operations, with no @Override, to the highest
>> abstract class I could find, usually JenaXYZ.java
>>
>> All call SQLFeatureNotSupportedException
>>
>> I've compiled with java6 and java7 compilers and runtimes, running "mvn
>> clean install".
>>
>> I encountered problems running the tests -
>> with java6, the tests hang at:
>> org.apache.jena.jdbc.remote.results.TestRemoteEndpointResults
>>
>> It completes on Java7.
>>
>> Total time: Java7: 11:10.239s
>> Apache Jena - JDBC Parent ................[2.371s]
>> Apache Jena - JDBC Core API ..............[18.622s]
>> Apache Jena - JDBC Remote Endpoint Driver [4:32.039s]
>> Apache Jena - JDBC In-Memory Driver ......[11.076s]
>> Apache Jena - JDBC TDB Driver ............[5:52.688s]
>> Apache Jena - JDBC Driver Bundle .........[13.157s]
>>
>>
>> The build (mvn clean install in jena-jdbc having rebuild jena) is messy;
>>
>> It's not finding a log4j setup which might be related to the output that
>> is Exceptions printed e.g.
>>
>> 22:35:01 ERROR JenaStatement :: Invalid SPARQL update
>> com.hp.hpl.jena.query.QueryParseException: Encountered " "select"
>> "SELECT "" at line 1, column 1.
>> and a long trace.
>>
>> There are enough of these that my terminal buffer lost the top of the
>> output so I don't know how many there were.
>>
>> and many like:
>>
>> 5602 [main] ERROR org.apache.jena.jdbc.JenaDriver - Invalid value for
>> post-processor parameter, references a class that did not exist
>> java.lang.ClassNotFoundException: NoSuchClass
>>
>>
>> 5601 [main] ERROR org.apache.jena.jdbc.JenaDriver - Invalid value for
>> pre-processor parameter, references a class that exists but does not
>> have an appropriate constructor
>> java.lang.InstantiationException: com.hp.hpl.jena.graph.Node
>>
>> Andy
>>
>> On 26/08/13 18:21, Rob Vesse wrote:
>>> Yeah we use JDK6 exclusively here at YarcData
>>>
>>> The fix is either to make the change or I think we can use the compiler
>>> plugin to restrict these modules to JDK 6 for the time being?
>>>
>>> Rob
>>>
>>>
>>> On 8/26/13 3:04 AM, "Andy Seaborne" <an...@apache.org> wrote:
>>>
>>>> I'm getting the following compile time error when building with maven.
>>>>
>>>> [ERROR] Failed to execute goal
>>>> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
>>>> (default-compile) on project jena-jdbc-core: Compilation failure:
>>>> Compilation failure:
>>>> [ERROR]
>>>>
>>>> /home/afs/Jena/jena-jdbc/jena-jdbc-core/src/main/java/org/apache/jena/jd
>>>> bc
>>>> /metadata/results/MetaResultSet.java:[51,8]
>>>> org.apache.jena.jdbc.metadata.results.MetaResultSet is not abstract and
>>>> does not override abstract method
>>>> <T>getObject(java.lang.String,java.lang.Class<T>) in java.sql.ResultSet
>>>>
>>>> and then some others.
>>>>
>>>> Maybe it's this:
>>>>
>>>>
>>>> http://stackoverflow.com/questions/7692320/is-there-really-resultset-get
>>>> ob
>>>> jectstring-classt-in-jdk7
>>>>
>>>> I'm using a Java7 compiler in Java6 mode so it's the JDK7 runtime.
>>>>
>>>> If so, the fix is to add, without @Override but with suppressed
>>>> warnings:
>>>>
>>>> <T> T getObject(int columnIndex, Class<T> type) throws SQLException
>>>> <T> T getObject(String columnLabel, Class<T> type) throws SQLException
>>>>
>>>> Andy
>>>
>>
>
Re: jena-jdbc : JDJK6->JDK7-ism?
Posted by Rob Vesse <rv...@yarcdata.com>.
Andy
If you can commit your changes that would be great, then I can go over
them and see which if any we can implement properly.
The part of the build that was messy explicitly is testing that
configuring logging via driver parameters works, I have modified that
portion of the tests to redirect stdout to a ByteArrayOutputStream so I
can verify that the logging output gets enabled without polluting the mvn
build output. Some of the tests are explicit negative tests looking for
error conditions being properly propagated hence why all the logging noise
on that part of the test run. This should however now be hidden from the
build.
The remote endpoint results tests seem to be the prime culprits for hangs,
those are the tests that do the most bringing up and tearing down of
Fuseki instances with associated HTTP traffic and seems to be the ones
that most often hang on Jenkins. They should maintain a single Fuseki
instance for each class so the problem may lie more in the volume of HTTP
traffic involved, that's why there is the Thread.sleep() in those tests
which mitigates the problem some of the time.
Which version of Java 6 causes hangs for you? We run 1.6.0_51 (Oracle
standard Hotspot JVM)
Rob
On 8/28/13 3:34 PM, "Andy Seaborne" <an...@apache.org> wrote:
>Rob -
>
>I have had a go at fixing them so jena-jdbc compiles on Java7. This is
>done by adding missing operations, with no @Override, to the highest
>abstract class I could find, usually JenaXYZ.java
>
>All call SQLFeatureNotSupportedException
>
>I've compiled with java6 and java7 compilers and runtimes, running "mvn
>clean install".
>
>I encountered problems running the tests -
>with java6, the tests hang at:
>org.apache.jena.jdbc.remote.results.TestRemoteEndpointResults
>
>It completes on Java7.
>
>Total time: Java7: 11:10.239s
>Apache Jena - JDBC Parent ................[2.371s]
>Apache Jena - JDBC Core API ..............[18.622s]
>Apache Jena - JDBC Remote Endpoint Driver [4:32.039s]
>Apache Jena - JDBC In-Memory Driver ......[11.076s]
>Apache Jena - JDBC TDB Driver ............[5:52.688s]
>Apache Jena - JDBC Driver Bundle .........[13.157s]
>
>
>The build (mvn clean install in jena-jdbc having rebuild jena) is messy;
>
>It's not finding a log4j setup which might be related to the output that
>is Exceptions printed e.g.
>
>22:35:01 ERROR JenaStatement :: Invalid SPARQL update
>com.hp.hpl.jena.query.QueryParseException: Encountered " "select"
>"SELECT "" at line 1, column 1.
>and a long trace.
>
>There are enough of these that my terminal buffer lost the top of the
>output so I don't know how many there were.
>
>and many like:
>
>5602 [main] ERROR org.apache.jena.jdbc.JenaDriver - Invalid value for
>post-processor parameter, references a class that did not exist
>java.lang.ClassNotFoundException: NoSuchClass
>
>
>5601 [main] ERROR org.apache.jena.jdbc.JenaDriver - Invalid value for
>pre-processor parameter, references a class that exists but does not
>have an appropriate constructor
>java.lang.InstantiationException: com.hp.hpl.jena.graph.Node
>
> Andy
>
>On 26/08/13 18:21, Rob Vesse wrote:
>> Yeah we use JDK6 exclusively here at YarcData
>>
>> The fix is either to make the change or I think we can use the compiler
>> plugin to restrict these modules to JDK 6 for the time being?
>>
>> Rob
>>
>>
>> On 8/26/13 3:04 AM, "Andy Seaborne" <an...@apache.org> wrote:
>>
>>> I'm getting the following compile time error when building with maven.
>>>
>>> [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
>>> (default-compile) on project jena-jdbc-core: Compilation failure:
>>> Compilation failure:
>>> [ERROR]
>>>
>>>/home/afs/Jena/jena-jdbc/jena-jdbc-core/src/main/java/org/apache/jena/jd
>>>bc
>>> /metadata/results/MetaResultSet.java:[51,8]
>>> org.apache.jena.jdbc.metadata.results.MetaResultSet is not abstract and
>>> does not override abstract method
>>> <T>getObject(java.lang.String,java.lang.Class<T>) in java.sql.ResultSet
>>>
>>> and then some others.
>>>
>>> Maybe it's this:
>>>
>>>
>>>http://stackoverflow.com/questions/7692320/is-there-really-resultset-get
>>>ob
>>> jectstring-classt-in-jdk7
>>>
>>> I'm using a Java7 compiler in Java6 mode so it's the JDK7 runtime.
>>>
>>> If so, the fix is to add, without @Override but with suppressed
>>>warnings:
>>>
>>> <T> T getObject(int columnIndex, Class<T> type) throws SQLException
>>> <T> T getObject(String columnLabel, Class<T> type) throws SQLException
>>>
>>> Andy
>>
>
Re: jena-jdbc : JDJK6->JDK7-ism?
Posted by Andy Seaborne <an...@apache.org>.
Rob -
I have had a go at fixing them so jena-jdbc compiles on Java7. This is
done by adding missing operations, with no @Override, to the highest
abstract class I could find, usually JenaXYZ.java
All call SQLFeatureNotSupportedException
I've compiled with java6 and java7 compilers and runtimes, running "mvn
clean install".
I encountered problems running the tests -
with java6, the tests hang at:
org.apache.jena.jdbc.remote.results.TestRemoteEndpointResults
It completes on Java7.
Total time: Java7: 11:10.239s
Apache Jena - JDBC Parent ................[2.371s]
Apache Jena - JDBC Core API ..............[18.622s]
Apache Jena - JDBC Remote Endpoint Driver [4:32.039s]
Apache Jena - JDBC In-Memory Driver ......[11.076s]
Apache Jena - JDBC TDB Driver ............[5:52.688s]
Apache Jena - JDBC Driver Bundle .........[13.157s]
The build (mvn clean install in jena-jdbc having rebuild jena) is messy;
It's not finding a log4j setup which might be related to the output that
is Exceptions printed e.g.
22:35:01 ERROR JenaStatement :: Invalid SPARQL update
com.hp.hpl.jena.query.QueryParseException: Encountered " "select"
"SELECT "" at line 1, column 1.
and a long trace.
There are enough of these that my terminal buffer lost the top of the
output so I don't know how many there were.
and many like:
5602 [main] ERROR org.apache.jena.jdbc.JenaDriver - Invalid value for
post-processor parameter, references a class that did not exist
java.lang.ClassNotFoundException: NoSuchClass
5601 [main] ERROR org.apache.jena.jdbc.JenaDriver - Invalid value for
pre-processor parameter, references a class that exists but does not
have an appropriate constructor
java.lang.InstantiationException: com.hp.hpl.jena.graph.Node
Andy
On 26/08/13 18:21, Rob Vesse wrote:
> Yeah we use JDK6 exclusively here at YarcData
>
> The fix is either to make the change or I think we can use the compiler
> plugin to restrict these modules to JDK 6 for the time being?
>
> Rob
>
>
> On 8/26/13 3:04 AM, "Andy Seaborne" <an...@apache.org> wrote:
>
>> I'm getting the following compile time error when building with maven.
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
>> (default-compile) on project jena-jdbc-core: Compilation failure:
>> Compilation failure:
>> [ERROR]
>> /home/afs/Jena/jena-jdbc/jena-jdbc-core/src/main/java/org/apache/jena/jdbc
>> /metadata/results/MetaResultSet.java:[51,8]
>> org.apache.jena.jdbc.metadata.results.MetaResultSet is not abstract and
>> does not override abstract method
>> <T>getObject(java.lang.String,java.lang.Class<T>) in java.sql.ResultSet
>>
>> and then some others.
>>
>> Maybe it's this:
>>
>> http://stackoverflow.com/questions/7692320/is-there-really-resultset-getob
>> jectstring-classt-in-jdk7
>>
>> I'm using a Java7 compiler in Java6 mode so it's the JDK7 runtime.
>>
>> If so, the fix is to add, without @Override but with suppressed warnings:
>>
>> <T> T getObject(int columnIndex, Class<T> type) throws SQLException
>> <T> T getObject(String columnLabel, Class<T> type) throws SQLException
>>
>> Andy
>
Re: jena-jdbc : JDJK6->JDK7-ism?
Posted by Andy Seaborne <an...@apache.org>.
On 26/08/13 18:21, Rob Vesse wrote:
> Yeah we use JDK6 exclusively here at YarcData
>
> The fix is either to make the change or I think we can use the compiler
> plugin to restrict these modules to JDK 6 for the time being?
>
> Rob
I'd prefer the change if it has no effect on Java6 - I'm not sure what's
going to happen to the signatures of the abstract class between java6
and java7 runtimes. Presumably that works otherwise there would be lots
fo focums/stackoverflow items.
Does it get in the way in Java6?
Andy
>
>
> On 8/26/13 3:04 AM, "Andy Seaborne" <an...@apache.org> wrote:
>
>> I'm getting the following compile time error when building with maven.
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
>> (default-compile) on project jena-jdbc-core: Compilation failure:
>> Compilation failure:
>> [ERROR]
>> /home/afs/Jena/jena-jdbc/jena-jdbc-core/src/main/java/org/apache/jena/jdbc
>> /metadata/results/MetaResultSet.java:[51,8]
>> org.apache.jena.jdbc.metadata.results.MetaResultSet is not abstract and
>> does not override abstract method
>> <T>getObject(java.lang.String,java.lang.Class<T>) in java.sql.ResultSet
>>
>> and then some others.
>>
>> Maybe it's this:
>>
>> http://stackoverflow.com/questions/7692320/is-there-really-resultset-getob
>> jectstring-classt-in-jdk7
>>
>> I'm using a Java7 compiler in Java6 mode so it's the JDK7 runtime.
>>
>> If so, the fix is to add, without @Override but with suppressed warnings:
>>
>> <T> T getObject(int columnIndex, Class<T> type) throws SQLException
>> <T> T getObject(String columnLabel, Class<T> type) throws SQLException
>>
>> Andy
>
Re: jena-jdbc : JDJK6->JDK7-ism?
Posted by Rob Vesse <rv...@yarcdata.com>.
Yeah we use JDK6 exclusively here at YarcData
The fix is either to make the change or I think we can use the compiler
plugin to restrict these modules to JDK 6 for the time being?
Rob
On 8/26/13 3:04 AM, "Andy Seaborne" <an...@apache.org> wrote:
>I'm getting the following compile time error when building with maven.
>
>[ERROR] Failed to execute goal
>org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
>(default-compile) on project jena-jdbc-core: Compilation failure:
>Compilation failure:
>[ERROR]
>/home/afs/Jena/jena-jdbc/jena-jdbc-core/src/main/java/org/apache/jena/jdbc
>/metadata/results/MetaResultSet.java:[51,8]
>org.apache.jena.jdbc.metadata.results.MetaResultSet is not abstract and
>does not override abstract method
><T>getObject(java.lang.String,java.lang.Class<T>) in java.sql.ResultSet
>
>and then some others.
>
>Maybe it's this:
>
>http://stackoverflow.com/questions/7692320/is-there-really-resultset-getob
>jectstring-classt-in-jdk7
>
>I'm using a Java7 compiler in Java6 mode so it's the JDK7 runtime.
>
>If so, the fix is to add, without @Override but with suppressed warnings:
>
><T> T getObject(int columnIndex, Class<T> type) throws SQLException
><T> T getObject(String columnLabel, Class<T> type) throws SQLException
>
> Andy