[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
wrote:
> 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
>> wrote:
>>
>>>
>>> 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 Klang wrote:
>>>
>>> On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim >> >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 Klang 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
[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 wrote:
>
>
> On Tue, Sep 29, 2009 at 8:32 AM, Naftoli Gugenheim
> wrote:
>
>>
>> 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 Klang wrote:
>>
>> On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim > >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 Klang 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 > > >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
>>
[Lift] Re: Java 5 support?
On Tue, Sep 29, 2009 at 8:32 AM, Naftoli Gugenheim wrote:
>
> 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 Klang wrote:
>
> On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim >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 Klang 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 > >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
> > > so
[Lift] Re: Java 5 support?
Exactly. Thanks.
Is that an opton?
-
Viktor Klang wrote:
On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim 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 Klang wrote:
>
> On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker >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 >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
> t
[Lift] Re: Java 5 support?
On Tue, Sep 29, 2009 at 3:46 PM, Viktor Klang wrote:
>
>
> On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim
> 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?
>
Sounds like it to me :)
>>
>> -
>> Viktor Klang wrote:
>>
>> On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker
>> 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
>> > 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
[Lift] Re: Java 5 support?
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.
-
Viktor Klang wrote:
On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker 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 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
[Lift] Re: Java 5 support?
On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim 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 Klang wrote:
>
> On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker >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 >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 m
[Lift] Re: Java 5 support?
On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker 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 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
[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 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.
>
> Derek
>
>
> On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang 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 Java 5 JDK to compile/test with, Sun says
>>> that it's
[Lift] Re: Java 5 support?
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 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 > 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 pro
[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
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 > > 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] Re: Java 5 support?
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 wrote:
> Crud. This just isn't going to be easy, is it?
>
>
> On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker
> 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] 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 > 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 > wrote:
>
>
> On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker > 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 > wrote:
>
>
> On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker > 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 > wrote:
>
>
> On Mon, Sep 28, 2009 at 11:14 AM, 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.
>
>
> 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
>
> >
--~--~-~--~~~---
[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 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 > > 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:/
[Lift] Re: Java 5 support?
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 wrote:
>
>
> On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker
> 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
>
> >
>
--~--~-~--~~~---~--~~
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 1:19 PM, Derek Chen-Becker 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 --~--~-~--~~~---~--~~ 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?
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. Derek On Mon, Sep 28, 2009 at 1:33 PM, David Pollak wrote: > > > On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker > 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 > > > > --~--~-~--~~~---~--~~ 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 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 --~--~-~--~~~---~--~~ 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 8:51 PM, Derek Chen-Becker 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. > It's rather simple, supply and demand, if there's a demand for us to keep Java5 compatibility, we'll need to see what we can do to fulfill that need, and if that costs money, then the demandees will need to open the wallets. > > 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 >> >> >> >> > > > > -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub --~--~-~--~~~---~--~~ 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?
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. 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 > 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 > > > > > --~--~-~--~~~---~--~~ 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:14 AM, 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. > > 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 --~--~-~--~~~---~--~~ 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?
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 -~--~~~~--~~--~--~---
