[Lift] Re: Java 5 support?
OK, here it is:
http://reviewboard.liftweb.net/r/18/
Derek
On Tue, Sep 29, 2009 at 10:10 AM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
I'll take a stab at it. I'm familiar with Dynamic Proxies but I've never
implemented one before, so this would be a good experience. The only
drawback is that I think I'm going to have to use reflection on the wrapped
Statement/PreparedStatement since we won't know ahead of time which JDBC
version the person is going to want to use. It's going to have ugly guts,
but hopefully it will remain clean to the user other than the performance
impact of double dynamic dispatch.
Derek
On Tue, Sep 29, 2009 at 9:57 AM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Tue, Sep 29, 2009 at 8:32 AM, Naftoli Gugenheim
naftoli...@gmail.comwrote:
Exactly. Thanks.
Is that an opton?
I think DynamicProxy is the way to go.
Derek -- if you want, I can take a crack at getting to code working.
-
Viktor Klangviktor.kl...@gmail.com wrote:
On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim naftoli...@gmail.com
wrote:
Another option: Java has a way to dynamically implement an interface. I
forgot what the classes are called. You supply a delegate and you can
pattern match on which method is being invoked. In Java 5 the
nonexistent
method will simply never be invoked, but it won't break code.
Dynamic proxy?
-
Viktor Klangviktor.kl...@gmail.com wrote:
On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker
dchenbec...@gmail.com
wrote:
Can you elaborate on what you mean? I was actually going to look at
how
log4jdbc does it and see if I could replicate it.
I haven't really tried this, but if you do:
if you implement methods with the correct signatures in the
LoggedStatement
and LoggedPreparedStatement, then wrap the invocations to the wrapped
instances in a try-catch, and if there's an NoSuchMethodException,
return
some default value?
Derek
On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang
viktor.kl...@gmail.com
wrote:
Is it possible to have a bridge trait for the Statement interface?
On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
No. I hadn't foreseen this issue, but I understand the importance
of
have
Java 5 support. I'm fine with writing and maintaining multiple
versions
of
the impls for the various versions, but I wonder if there's any
clean
way to
manage this with Maven.
Derek
On Mon, Sep 28, 2009 at 4:00 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
Crud. This just isn't going to be easy, is it?
On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
Another issue, which may be more problematic, is that in my case
I'm
compiling against the java.sql.Statement interface. If I remove
the
troublesome methods so that it compiles for 1.5, it no longer
compiles for
1.6 because of the missing methods:
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
error: class LoggedStatement needs to be abstract, since method
isPoolable
in trait Statement of type ()Boolean is not defined
[WARNING] class LoggedStatement(underlying : Statement) extends
Statement with DBLog {
[WARNING] ^
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
error: class LoggedPreparedStatement needs to be abstract, since
method
setNClob in trait PreparedStatement of type
(Int,java.io.Reader)Unit
is not
defined
[WARNING] class LoggedPreparedStatement (stmt : String,
underlying :
PreparedStatement) extends LoggedStatement(underlying) with
PreparedStatement {
[WARNING] ^
Derek
On Mon, Sep 28, 2009 at 2:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
The issue (and I may be overthinking this) is that we need 1.5
class
libraries to compile against if we want to be able to verify
that
the code
compiles under 1.5. If I, say, delete my JDK 5 install and
decide
to
reinstall it down the road, it's not going to be available
without
a
purchased license.
I can stash away a bunch of different copies of the JDK and give
them
to you when you need them.
A 32 bit Linux JDK 1.5 should be enough to at least do smoke
test
builds with.
Derek
On Mon, Sep 28, 2009 at 1:33 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
My main concern is that after October 30, Java 5 costs money
(I'm
guessing not
[Lift] Re: Java 5 support?
Is it possible to have a bridge trait for the Statement interface?
On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
No. I hadn't foreseen this issue, but I understand the importance of have
Java 5 support. I'm fine with writing and maintaining multiple versions of
the impls for the various versions, but I wonder if there's any clean way to
manage this with Maven.
Derek
On Mon, Sep 28, 2009 at 4:00 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
Crud. This just isn't going to be easy, is it?
On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
Another issue, which may be more problematic, is that in my case I'm
compiling against the java.sql.Statement interface. If I remove the
troublesome methods so that it compiles for 1.5, it no longer compiles for
1.6 because of the missing methods:
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
error: class LoggedStatement needs to be abstract, since method isPoolable
in trait Statement of type ()Boolean is not defined
[WARNING] class LoggedStatement(underlying : Statement) extends Statement
with DBLog {
[WARNING] ^
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
error: class LoggedPreparedStatement needs to be abstract, since method
setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit is not
defined
[WARNING] class LoggedPreparedStatement (stmt : String, underlying :
PreparedStatement) extends LoggedStatement(underlying) with
PreparedStatement {
[WARNING] ^
Derek
On Mon, Sep 28, 2009 at 2:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
The issue (and I may be overthinking this) is that we need 1.5 class
libraries to compile against if we want to be able to verify that the code
compiles under 1.5. If I, say, delete my JDK 5 install and decide to
reinstall it down the road, it's not going to be available without a
purchased license.
I can stash away a bunch of different copies of the JDK and give them to
you when you need them.
A 32 bit Linux JDK 1.5 should be enough to at least do smoke test builds
with.
Derek
On Mon, Sep 28, 2009 at 1:33 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
My main concern is that after October 30, Java 5 costs money (I'm
guessing not a trivial amount, either). I can get the JDK right now,
but if
some bug in the Java libraries pops up that would prevent things from
working, I don't know how we'll work around that.
I don't see the condition under which that could happen. When we
compile against Java 1.5, we are simply defining the contract between our
classes and the library classes. None of the library seeps into our
code
(this is not true of Scala traits). So, as long as the running library
has
the classes/methods that we are calling, we're fine. Compiling against
1.5
simply means that we have fewer calls that we can make. If there is an
issue in 1.5 that a user is experiencing, that is the user's issue, not
ours. If the code compiles (and runs tests) against 1.5 and does not
generate the particular issue that the user is seeing under 1.6, then
that
use has to contact Sun, not us.
Derek
On Mon, Sep 28, 2009 at 12:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
I was just about to work on issue #67 (build breaks on Java 5), but
when I went to get a Java 5 JDK to compile/test with, Sun says that
it's EOL
as of October 30, 2009. I don't have a problem fixing things to work
with
Java 5, but I don't want to do work that's going to be tossed out in a
month.
Lift will be JDK 1.5 compatible for at least 1 year (and probably
longer). LinkedIn and SAP are both 1.5 shops. There are tons of
other Bay
Area companies (Wells Fargo, Kaiser, etc.) that are also 1.5 shops.
For the
next 2-3 years, OS X 10.5 will be common and 10.5 + old MacBooks ==
1.5.
It will not be lost work.
Derek
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
Lift, the simply functional web framework http://liftweb.net
[Lift] Re: Java 5 support?
Argh. log4jdbc has two source trees, one for JDK 1.4 and one for JDK 6 :(
On Tue, Sep 29, 2009 at 7:47 AM, Derek Chen-Becker dchenbec...@gmail.comwrote:
Can you elaborate on what you mean? I was actually going to look at how
log4jdbc does it and see if I could replicate it.
Derek
On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang viktor.kl...@gmail.comwrote:
Is it possible to have a bridge trait for the Statement interface?
On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
No. I hadn't foreseen this issue, but I understand the importance of have
Java 5 support. I'm fine with writing and maintaining multiple versions of
the impls for the various versions, but I wonder if there's any clean way to
manage this with Maven.
Derek
On Mon, Sep 28, 2009 at 4:00 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
Crud. This just isn't going to be easy, is it?
On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
Another issue, which may be more problematic, is that in my case I'm
compiling against the java.sql.Statement interface. If I remove the
troublesome methods so that it compiles for 1.5, it no longer compiles for
1.6 because of the missing methods:
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
error: class LoggedStatement needs to be abstract, since method isPoolable
in trait Statement of type ()Boolean is not defined
[WARNING] class LoggedStatement(underlying : Statement) extends
Statement with DBLog {
[WARNING] ^
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
error: class LoggedPreparedStatement needs to be abstract, since method
setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit is
not
defined
[WARNING] class LoggedPreparedStatement (stmt : String, underlying :
PreparedStatement) extends LoggedStatement(underlying) with
PreparedStatement {
[WARNING] ^
Derek
On Mon, Sep 28, 2009 at 2:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
The issue (and I may be overthinking this) is that we need 1.5 class
libraries to compile against if we want to be able to verify that the
code
compiles under 1.5. If I, say, delete my JDK 5 install and decide to
reinstall it down the road, it's not going to be available without a
purchased license.
I can stash away a bunch of different copies of the JDK and give them
to you when you need them.
A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
builds with.
Derek
On Mon, Sep 28, 2009 at 1:33 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
My main concern is that after October 30, Java 5 costs money (I'm
guessing not a trivial amount, either). I can get the JDK right now,
but if
some bug in the Java libraries pops up that would prevent things from
working, I don't know how we'll work around that.
I don't see the condition under which that could happen. When we
compile against Java 1.5, we are simply defining the contract between
our
classes and the library classes. None of the library seeps into our
code
(this is not true of Scala traits). So, as long as the running
library has
the classes/methods that we are calling, we're fine. Compiling
against 1.5
simply means that we have fewer calls that we can make. If there is an
issue in 1.5 that a user is experiencing, that is the user's issue, not
ours. If the code compiles (and runs tests) against 1.5 and does not
generate the particular issue that the user is seeing under 1.6, then
that
use has to contact Sun, not us.
Derek
On Mon, Sep 28, 2009 at 12:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
I was just about to work on issue #67 (build breaks on Java 5),
but when I went to get a Java 5 JDK to compile/test with, Sun says
that it's
EOL as of October 30, 2009. I don't have a problem fixing things to
work
with Java 5, but I don't want to do work that's going to be tossed
out in a
month.
Lift will be JDK 1.5 compatible for at least 1 year (and probably
longer). LinkedIn and SAP are both 1.5 shops. There are tons of
other Bay
Area companies (Wells Fargo, Kaiser, etc.) that are also 1.5 shops.
For the
next 2-3 years, OS X 10.5 will be common and 10.5 + old MacBooks ==
1.5.
It will not be lost work.
Derek
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
Lift, the simply functional web framework http://liftweb.net
[Lift] Re: Java 5 support?
On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:
Can you elaborate on what you mean? I was actually going to look at how
log4jdbc does it and see if I could replicate it.
I haven't really tried this, but if you do:
if you implement methods with the correct signatures in the LoggedStatement
and LoggedPreparedStatement, then wrap the invocations to the wrapped
instances in a try-catch, and if there's an NoSuchMethodException, return
some default value?
Derek
On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang viktor.kl...@gmail.comwrote:
Is it possible to have a bridge trait for the Statement interface?
On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
No. I hadn't foreseen this issue, but I understand the importance of have
Java 5 support. I'm fine with writing and maintaining multiple versions of
the impls for the various versions, but I wonder if there's any clean way to
manage this with Maven.
Derek
On Mon, Sep 28, 2009 at 4:00 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
Crud. This just isn't going to be easy, is it?
On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
Another issue, which may be more problematic, is that in my case I'm
compiling against the java.sql.Statement interface. If I remove the
troublesome methods so that it compiles for 1.5, it no longer compiles for
1.6 because of the missing methods:
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
error: class LoggedStatement needs to be abstract, since method isPoolable
in trait Statement of type ()Boolean is not defined
[WARNING] class LoggedStatement(underlying : Statement) extends
Statement with DBLog {
[WARNING] ^
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
error: class LoggedPreparedStatement needs to be abstract, since method
setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit is
not
defined
[WARNING] class LoggedPreparedStatement (stmt : String, underlying :
PreparedStatement) extends LoggedStatement(underlying) with
PreparedStatement {
[WARNING] ^
Derek
On Mon, Sep 28, 2009 at 2:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
The issue (and I may be overthinking this) is that we need 1.5 class
libraries to compile against if we want to be able to verify that the
code
compiles under 1.5. If I, say, delete my JDK 5 install and decide to
reinstall it down the road, it's not going to be available without a
purchased license.
I can stash away a bunch of different copies of the JDK and give them
to you when you need them.
A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
builds with.
Derek
On Mon, Sep 28, 2009 at 1:33 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
My main concern is that after October 30, Java 5 costs money (I'm
guessing not a trivial amount, either). I can get the JDK right now,
but if
some bug in the Java libraries pops up that would prevent things from
working, I don't know how we'll work around that.
I don't see the condition under which that could happen. When we
compile against Java 1.5, we are simply defining the contract between
our
classes and the library classes. None of the library seeps into our
code
(this is not true of Scala traits). So, as long as the running
library has
the classes/methods that we are calling, we're fine. Compiling
against 1.5
simply means that we have fewer calls that we can make. If there is an
issue in 1.5 that a user is experiencing, that is the user's issue, not
ours. If the code compiles (and runs tests) against 1.5 and does not
generate the particular issue that the user is seeing under 1.6, then
that
use has to contact Sun, not us.
Derek
On Mon, Sep 28, 2009 at 12:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
I was just about to work on issue #67 (build breaks on Java 5),
but when I went to get a Java 5 JDK to compile/test with, Sun says
that it's
EOL as of October 30, 2009. I don't have a problem fixing things to
work
with Java 5, but I don't want to do work that's going to be tossed
out in a
month.
Lift will be JDK 1.5 compatible for at least 1 year (and probably
longer). LinkedIn and SAP are both 1.5 shops. There are tons of
other Bay
Area companies (Wells Fargo, Kaiser, etc.) that are also 1.5 shops.
For the
next 2-3 years, OS X 10.5 will be common and 10.5 + old MacBooks ==
1.5.
It will not be lost work.
Derek
--
Lift, the simply functional web
[Lift] Re: Java 5 support?
On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:
Another option: Java has a way to dynamically implement an interface. I
forgot what the classes are called. You supply a delegate and you can
pattern match on which method is being invoked. In Java 5 the nonexistent
method will simply never be invoked, but it won't break code.
Dynamic proxy?
-
Viktor Klangviktor.kl...@gmail.com wrote:
On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
Can you elaborate on what you mean? I was actually going to look at how
log4jdbc does it and see if I could replicate it.
I haven't really tried this, but if you do:
if you implement methods with the correct signatures in the LoggedStatement
and LoggedPreparedStatement, then wrap the invocations to the wrapped
instances in a try-catch, and if there's an NoSuchMethodException, return
some default value?
Derek
On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang viktor.kl...@gmail.com
wrote:
Is it possible to have a bridge trait for the Statement interface?
On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
No. I hadn't foreseen this issue, but I understand the importance of
have
Java 5 support. I'm fine with writing and maintaining multiple versions
of
the impls for the various versions, but I wonder if there's any clean
way to
manage this with Maven.
Derek
On Mon, Sep 28, 2009 at 4:00 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
Crud. This just isn't going to be easy, is it?
On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
Another issue, which may be more problematic, is that in my case I'm
compiling against the java.sql.Statement interface. If I remove the
troublesome methods so that it compiles for 1.5, it no longer
compiles for
1.6 because of the missing methods:
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
error: class LoggedStatement needs to be abstract, since method
isPoolable
in trait Statement of type ()Boolean is not defined
[WARNING] class LoggedStatement(underlying : Statement) extends
Statement with DBLog {
[WARNING] ^
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
error: class LoggedPreparedStatement needs to be abstract, since
method
setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit
is not
defined
[WARNING] class LoggedPreparedStatement (stmt : String, underlying :
PreparedStatement) extends LoggedStatement(underlying) with
PreparedStatement {
[WARNING] ^
Derek
On Mon, Sep 28, 2009 at 2:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
The issue (and I may be overthinking this) is that we need 1.5
class
libraries to compile against if we want to be able to verify that
the code
compiles under 1.5. If I, say, delete my JDK 5 install and decide
to
reinstall it down the road, it's not going to be available without
a
purchased license.
I can stash away a bunch of different copies of the JDK and give
them
to you when you need them.
A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
builds with.
Derek
On Mon, Sep 28, 2009 at 1:33 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
My main concern is that after October 30, Java 5 costs money (I'm
guessing not a trivial amount, either). I can get the JDK right
now, but if
some bug in the Java libraries pops up that would prevent things
from
working, I don't know how we'll work around that.
I don't see the condition under which that could happen. When we
compile against Java 1.5, we are simply defining the contract
between our
classes and the library classes. None of the library seeps into
our code
(this is not true of Scala traits). So, as long as the running
library has
the classes/methods that we are calling, we're fine. Compiling
against 1.5
simply means that we have fewer calls that we can make. If there
is an
issue in 1.5 that a user is experiencing, that is the user's
issue, not
ours. If the code compiles (and runs tests) against 1.5 and does
not
generate the particular issue that the user is seeing under 1.6,
then that
use has to contact Sun, not us.
Derek
On Mon, Sep 28, 2009 at 12:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
I was just about to work on issue #67 (build breaks on Java 5),
but when I went to get a
[Lift] Re: Java 5 support?
On Tue, Sep 29, 2009 at 8:32 AM, Naftoli Gugenheim naftoli...@gmail.comwrote:
Exactly. Thanks.
Is that an opton?
I think DynamicProxy is the way to go.
Derek -- if you want, I can take a crack at getting to code working.
-
Viktor Klangviktor.kl...@gmail.com wrote:
On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim naftoli...@gmail.com
wrote:
Another option: Java has a way to dynamically implement an interface. I
forgot what the classes are called. You supply a delegate and you can
pattern match on which method is being invoked. In Java 5 the nonexistent
method will simply never be invoked, but it won't break code.
Dynamic proxy?
-
Viktor Klangviktor.kl...@gmail.com wrote:
On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker
dchenbec...@gmail.com
wrote:
Can you elaborate on what you mean? I was actually going to look at how
log4jdbc does it and see if I could replicate it.
I haven't really tried this, but if you do:
if you implement methods with the correct signatures in the
LoggedStatement
and LoggedPreparedStatement, then wrap the invocations to the wrapped
instances in a try-catch, and if there's an NoSuchMethodException,
return
some default value?
Derek
On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang viktor.kl...@gmail.com
wrote:
Is it possible to have a bridge trait for the Statement interface?
On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
No. I hadn't foreseen this issue, but I understand the importance of
have
Java 5 support. I'm fine with writing and maintaining multiple
versions
of
the impls for the various versions, but I wonder if there's any clean
way to
manage this with Maven.
Derek
On Mon, Sep 28, 2009 at 4:00 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
Crud. This just isn't going to be easy, is it?
On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
Another issue, which may be more problematic, is that in my case
I'm
compiling against the java.sql.Statement interface. If I remove the
troublesome methods so that it compiles for 1.5, it no longer
compiles for
1.6 because of the missing methods:
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
error: class LoggedStatement needs to be abstract, since method
isPoolable
in trait Statement of type ()Boolean is not defined
[WARNING] class LoggedStatement(underlying : Statement) extends
Statement with DBLog {
[WARNING] ^
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
error: class LoggedPreparedStatement needs to be abstract, since
method
setNClob in trait PreparedStatement of type
(Int,java.io.Reader)Unit
is not
defined
[WARNING] class LoggedPreparedStatement (stmt : String, underlying
:
PreparedStatement) extends LoggedStatement(underlying) with
PreparedStatement {
[WARNING] ^
Derek
On Mon, Sep 28, 2009 at 2:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
The issue (and I may be overthinking this) is that we need 1.5
class
libraries to compile against if we want to be able to verify that
the code
compiles under 1.5. If I, say, delete my JDK 5 install and decide
to
reinstall it down the road, it's not going to be available
without
a
purchased license.
I can stash away a bunch of different copies of the JDK and give
them
to you when you need them.
A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
builds with.
Derek
On Mon, Sep 28, 2009 at 1:33 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
My main concern is that after October 30, Java 5 costs money
(I'm
guessing not a trivial amount, either). I can get the JDK right
now, but if
some bug in the Java libraries pops up that would prevent
things
from
working, I don't know how we'll work around that.
I don't see the condition under which that could happen. When
we
compile against Java 1.5, we are simply defining the contract
between our
classes and the library classes. None of the library seeps
into
our code
(this is not true of Scala traits). So, as long as the running
library has
the classes/methods that we are calling, we're fine. Compiling
against 1.5
simply means that we have fewer calls that we can make. If
there
is an
issue in 1.5 that a user is experiencing, that is the user's
[Lift] Re: Java 5 support?
I'll take a stab at it. I'm familiar with Dynamic Proxies but I've never
implemented one before, so this would be a good experience. The only
drawback is that I think I'm going to have to use reflection on the wrapped
Statement/PreparedStatement since we won't know ahead of time which JDBC
version the person is going to want to use. It's going to have ugly guts,
but hopefully it will remain clean to the user other than the performance
impact of double dynamic dispatch.
Derek
On Tue, Sep 29, 2009 at 9:57 AM, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Tue, Sep 29, 2009 at 8:32 AM, Naftoli Gugenheim
naftoli...@gmail.comwrote:
Exactly. Thanks.
Is that an opton?
I think DynamicProxy is the way to go.
Derek -- if you want, I can take a crack at getting to code working.
-
Viktor Klangviktor.kl...@gmail.com wrote:
On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim naftoli...@gmail.com
wrote:
Another option: Java has a way to dynamically implement an interface. I
forgot what the classes are called. You supply a delegate and you can
pattern match on which method is being invoked. In Java 5 the
nonexistent
method will simply never be invoked, but it won't break code.
Dynamic proxy?
-
Viktor Klangviktor.kl...@gmail.com wrote:
On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker
dchenbec...@gmail.com
wrote:
Can you elaborate on what you mean? I was actually going to look at
how
log4jdbc does it and see if I could replicate it.
I haven't really tried this, but if you do:
if you implement methods with the correct signatures in the
LoggedStatement
and LoggedPreparedStatement, then wrap the invocations to the wrapped
instances in a try-catch, and if there's an NoSuchMethodException,
return
some default value?
Derek
On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang viktor.kl...@gmail.com
wrote:
Is it possible to have a bridge trait for the Statement interface?
On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
No. I hadn't foreseen this issue, but I understand the importance of
have
Java 5 support. I'm fine with writing and maintaining multiple
versions
of
the impls for the various versions, but I wonder if there's any
clean
way to
manage this with Maven.
Derek
On Mon, Sep 28, 2009 at 4:00 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
Crud. This just isn't going to be easy, is it?
On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
Another issue, which may be more problematic, is that in my case
I'm
compiling against the java.sql.Statement interface. If I remove
the
troublesome methods so that it compiles for 1.5, it no longer
compiles for
1.6 because of the missing methods:
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
error: class LoggedStatement needs to be abstract, since method
isPoolable
in trait Statement of type ()Boolean is not defined
[WARNING] class LoggedStatement(underlying : Statement) extends
Statement with DBLog {
[WARNING] ^
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
error: class LoggedPreparedStatement needs to be abstract, since
method
setNClob in trait PreparedStatement of type
(Int,java.io.Reader)Unit
is not
defined
[WARNING] class LoggedPreparedStatement (stmt : String, underlying
:
PreparedStatement) extends LoggedStatement(underlying) with
PreparedStatement {
[WARNING] ^
Derek
On Mon, Sep 28, 2009 at 2:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
The issue (and I may be overthinking this) is that we need 1.5
class
libraries to compile against if we want to be able to verify
that
the code
compiles under 1.5. If I, say, delete my JDK 5 install and
decide
to
reinstall it down the road, it's not going to be available
without
a
purchased license.
I can stash away a bunch of different copies of the JDK and give
them
to you when you need them.
A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
builds with.
Derek
On Mon, Sep 28, 2009 at 1:33 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
My main concern is that after October 30, Java 5 costs money
(I'm
guessing not a trivial amount, either). I can get the JDK
right
now, but if
some bug in the Java libraries pops up that would prevent
things
from
working, I
[Lift] Re: Java 5 support?
Hmm - had this problem the other day. The only real downside of not letting it build on 1.5 from my position is that people on Mac will need to tweak the PATH because the default JDK is 5, not 6 (which is installed too, oddly) Might be some others, but I cant think of them. Cheers, Tim On 28 Sep 2009, at 19:14, Derek Chen-Becker wrote: I was just about to work on issue #67 (build breaks on Java 5), but when I went to get a Java 5 JDK to compile/test with, Sun says that it's EOL as of October 30, 2009. I don't have a problem fixing things to work with Java 5, but I don't want to do work that's going to be tossed out in a month. Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Java 5 support?
On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker dchenbec...@gmail.comwrote: My main concern is that after October 30, Java 5 costs money (I'm guessing not a trivial amount, either). I can get the JDK right now, but if some bug in the Java libraries pops up that would prevent things from working, I don't know how we'll work around that. I don't see the condition under which that could happen. When we compile against Java 1.5, we are simply defining the contract between our classes and the library classes. None of the library seeps into our code (this is not true of Scala traits). So, as long as the running library has the classes/methods that we are calling, we're fine. Compiling against 1.5 simply means that we have fewer calls that we can make. If there is an issue in 1.5 that a user is experiencing, that is the user's issue, not ours. If the code compiles (and runs tests) against 1.5 and does not generate the particular issue that the user is seeing under 1.6, then that use has to contact Sun, not us. Derek On Mon, Sep 28, 2009 at 12:29 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker dchenbec...@gmail.com wrote: I was just about to work on issue #67 (build breaks on Java 5), but when I went to get a Java 5 JDK to compile/test with, Sun says that it's EOL as of October 30, 2009. I don't have a problem fixing things to work with Java 5, but I don't want to do work that's going to be tossed out in a month. Lift will be JDK 1.5 compatible for at least 1 year (and probably longer). LinkedIn and SAP are both 1.5 shops. There are tons of other Bay Area companies (Wells Fargo, Kaiser, etc.) that are also 1.5 shops. For the next 2-3 years, OS X 10.5 will be common and 10.5 + old MacBooks == 1.5. It will not be lost work. Derek -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Java 5 support?
Crud. This just isn't going to be easy, is it?
On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:
Another issue, which may be more problematic, is that in my case I'm
compiling against the java.sql.Statement interface. If I remove the
troublesome methods so that it compiles for 1.5, it no longer compiles for
1.6 because of the missing methods:
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
error: class LoggedStatement needs to be abstract, since method isPoolable
in trait Statement of type ()Boolean is not defined
[WARNING] class LoggedStatement(underlying : Statement) extends Statement
with DBLog {
[WARNING] ^
[WARNING]
/home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
error: class LoggedPreparedStatement needs to be abstract, since method
setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit is not
defined
[WARNING] class LoggedPreparedStatement (stmt : String, underlying :
PreparedStatement) extends LoggedStatement(underlying) with
PreparedStatement {
[WARNING] ^
Derek
On Mon, Sep 28, 2009 at 2:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
The issue (and I may be overthinking this) is that we need 1.5 class
libraries to compile against if we want to be able to verify that the code
compiles under 1.5. If I, say, delete my JDK 5 install and decide to
reinstall it down the road, it's not going to be available without a
purchased license.
I can stash away a bunch of different copies of the JDK and give them to
you when you need them.
A 32 bit Linux JDK 1.5 should be enough to at least do smoke test builds
with.
Derek
On Mon, Sep 28, 2009 at 1:33 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
My main concern is that after October 30, Java 5 costs money (I'm
guessing not a trivial amount, either). I can get the JDK right now, but
if
some bug in the Java libraries pops up that would prevent things from
working, I don't know how we'll work around that.
I don't see the condition under which that could happen. When we
compile against Java 1.5, we are simply defining the contract between our
classes and the library classes. None of the library seeps into our code
(this is not true of Scala traits). So, as long as the running library has
the classes/methods that we are calling, we're fine. Compiling against 1.5
simply means that we have fewer calls that we can make. If there is an
issue in 1.5 that a user is experiencing, that is the user's issue, not
ours. If the code compiles (and runs tests) against 1.5 and does not
generate the particular issue that the user is seeing under 1.6, then that
use has to contact Sun, not us.
Derek
On Mon, Sep 28, 2009 at 12:29 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
I was just about to work on issue #67 (build breaks on Java 5), but
when I went to get a Java 5 JDK to compile/test with, Sun says that
it's EOL
as of October 30, 2009. I don't have a problem fixing things to work
with
Java 5, but I don't want to do work that's going to be tossed out in a
month.
Lift will be JDK 1.5 compatible for at least 1 year (and probably
longer). LinkedIn and SAP are both 1.5 shops. There are tons of other
Bay
Area companies (Wells Fargo, Kaiser, etc.) that are also 1.5 shops. For
the
next 2-3 years, OS X 10.5 will be common and 10.5 + old MacBooks == 1.5.
It will not be lost work.
Derek
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
[Lift] Re: Java 5 support?
In some code we have at work that has to support Java 1.6 and down for
certain things, we had to resort to having multiple versions and
dynamically Class.forName the right one in at runtime. I would be
overjoyed to hear of a better solution :-/
-Ross
On Sep 28, 2009, at 6:00 PM, David Pollak wrote:
Crud. This just isn't going to be easy, is it?
On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
Another issue, which may be more problematic, is that in my case I'm
compiling against the java.sql.Statement interface. If I remove the
troublesome methods so that it compiles for 1.5, it no longer
compiles for 1.6 because of the missing methods:
[WARNING] /home/software/liftweb/lift-mapper/src/main/scala/net/
liftweb/mapper/LoggingStatementWrappers.scala:70: error: class
LoggedStatement needs to be abstract, since method isPoolable in
trait Statement of type ()Boolean is not defined
[WARNING] class LoggedStatement(underlying : Statement) extends
Statement with DBLog {
[WARNING] ^
[WARNING] /home/software/liftweb/lift-mapper/src/main/scala/net/
liftweb/mapper/LoggingStatementWrappers.scala:267: error: class
LoggedPreparedStatement needs to be abstract, since method setNClob
in trait PreparedStatement of type (Int,java.io.Reader)Unit is not
defined
[WARNING] class LoggedPreparedStatement (stmt : String, underlying :
PreparedStatement) extends LoggedStatement(underlying) with
PreparedStatement {
[WARNING] ^
Derek
On Mon, Sep 28, 2009 at 2:29 PM, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
The issue (and I may be overthinking this) is that we need 1.5 class
libraries to compile against if we want to be able to verify that
the code compiles under 1.5. If I, say, delete my JDK 5 install and
decide to reinstall it down the road, it's not going to be available
without a purchased license.
I can stash away a bunch of different copies of the JDK and give
them to you when you need them.
A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
builds with.
Derek
On Mon, Sep 28, 2009 at 1:33 PM, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
My main concern is that after October 30, Java 5 costs money (I'm
guessing not a trivial amount, either). I can get the JDK right now,
but if some bug in the Java libraries pops up that would prevent
things from working, I don't know how we'll work around that.
I don't see the condition under which that could happen. When we
compile against Java 1.5, we are simply defining the contract
between our classes and the library classes. None of the library
seeps into our code (this is not true of Scala traits). So, as
long as the running library has the classes/methods that we are
calling, we're fine. Compiling against 1.5 simply means that we
have fewer calls that we can make. If there is an issue in 1.5 that
a user is experiencing, that is the user's issue, not ours. If the
code compiles (and runs tests) against 1.5 and does not generate the
particular issue that the user is seeing under 1.6, then that use
has to contact Sun, not us.
Derek
On Mon, Sep 28, 2009 at 12:29 PM, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
I was just about to work on issue #67 (build breaks on Java 5), but
when I went to get a Java 5 JDK to compile/test with, Sun says that
it's EOL as of October 30, 2009. I don't have a problem fixing
things to work with Java 5, but I don't want to do work that's going
to be tossed out in a month.
Lift will be JDK 1.5 compatible for at least 1 year (and probably
longer). LinkedIn and SAP are both 1.5 shops. There are tons of
other Bay Area companies (Wells Fargo, Kaiser, etc.) that are also
1.5 shops. For the next 2-3 years, OS X 10.5 will be common and
10.5 + old MacBooks == 1.5.
It will not be lost work.
Derek
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
