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 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 >>>> >>>> >>>> >>> >>> >>> >> >> >> -- >> 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 >> >> >> >> > > > > -- 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 -~----------~----~----~----~------~----~------~--~---