You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2008/09/28 01:00:51 UTC
JDBC 4 and build sanity
To go ahead with JDBC 4 implementation (even as an optional module)
and keep a sane build system at the same time, logically we should
switch the build system to Java 1.6. It can still produce the code
compatible with Java 1.5, but the development environment will have to
be 1.6.
This will exclude 32-bit Mac owners from the dev process (I do have 1
such laptop in my company, Ari probably has a few, etc...). So how do
we make it build on 1.5 (everything except for the 1.6 module of
course). Here is one idea: a developer may extract the new JDBC 4
interfaces from Java 1.6 (we can provide a little script to do that),
and build a small extension jar and drop it in the lib/ext of JDK 1.5.
That and also we will publish 1.6 snapshots for downstream dependents
(such as cayenne-server and cayenne-client).
Thoughts on that? Maybe there are better ideas (and I may need to vet
this little hack with Apache legal).
Thanks,
Andrus
Re: JDBC 4 and build sanity
Posted by Andrus Adamchik <an...@objectstyle.org>.
Ugh, I forgot to mention the problem with cross-jdk build: if we want
"cayenne-jdk1.5-unpublished" sources to stay buildable with both 1.5 &
1.6, all the classes implementing DataSource, Connection, ResultSet,
etc. will have a compile dependency on things like java.sql.NClob,
java.sql.SQLXML, etc.
Andrus
On Sep 28, 2008, at 2:00 AM, Andrus Adamchik wrote:
> To go ahead with JDBC 4 implementation (even as an optional module)
> and keep a sane build system at the same time, logically we should
> switch the build system to Java 1.6. It can still produce the code
> compatible with Java 1.5, but the development environment will have
> to be 1.6.
>
> This will exclude 32-bit Mac owners from the dev process (I do have
> 1 such laptop in my company, Ari probably has a few, etc...). So how
> do we make it build on 1.5 (everything except for the 1.6 module of
> course). Here is one idea: a developer may extract the new JDBC 4
> interfaces from Java 1.6 (we can provide a little script to do
> that), and build a small extension jar and drop it in the lib/ext of
> JDK 1.5. That and also we will publish 1.6 snapshots for downstream
> dependents (such as cayenne-server and cayenne-client).
>
> Thoughts on that? Maybe there are better ideas (and I may need to
> vet this little hack with Apache legal).
>
> Thanks,
> Andrus
>
Re: JDBC 4 and build sanity
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Sep 29, 2008, at 4:41 AM, Aristedes Maniatis wrote:
> Clearly implementing an interface doesn't cause a problem (since we
> do that for dozens of JRE interfaces) but can we write stubs for the
> interface itself and bundle that without causing a problem?
Note that I am not talking about us bundling JDK interfaces. Just
providing instructions to our own developers or anybody else how to
sneak these interfaces from the local JDK 1.6 into the local JDK 1.5.
Those won't be shipped with Cayenne.
Andrus
Re: JDBC 4 and build sanity
Posted by Andrus Adamchik <an...@objectstyle.org>.
Good idea about OpenJDK BTW... maybe I'll hack a little Maven module
based on OpenJDK with needed interfaces and post on on ObjectStyle.
Then we can have it as a "provided" (i.e. not bundled) dependency for
cayenne-jdk15-unpublished.
Let me float that on legal-discuss.
Andrus
On Sep 29, 2008, at 4:41 AM, Aristedes Maniatis wrote:
> On 28/09/2008, at 9:00 AM, Andrus Adamchik wrote:
>
>> This will exclude 32-bit Mac owners from the dev process (I do have
>> 1 such laptop in my company, Ari probably has a few, etc...). So
>> how do we make it build on 1.5 (everything except for the 1.6
>> module of course). Here is one idea: a developer may extract the
>> new JDBC 4 interfaces from Java 1.6 (we can provide a little script
>> to do that), and build a small extension jar and drop it in the lib/
>> ext of JDK 1.5. That and also we will publish 1.6 snapshots for
>> downstream dependents (such as cayenne-server and cayenne-client).
>>
>> Thoughts on that? Maybe there are better ideas (and I may need to
>> vet this little hack with Apache legal).
>
>
> It may be easier to do this against OpenJDK rather than Java 6,
> since the licensing is much simpler. But still, we bump into GPL
> licensing of OpenJDK. The question: "is this code linked to ours"
> such that it infects Cayenne code with the GPL license? Clearly
> implementing an interface doesn't cause a problem (since we do that
> for dozens of JRE interfaces) but can we write stubs for the
> interface itself and bundle that without causing a problem? The
> logical answer is that we are including no more intellectual
> property than simply implementing the interface, but law is so
> rarely that logical.
>
> And of course the Java 6 problem for Mac users is not just 32 bit
> machines, but also 64 bit PPC machines. I can't wait until Apple
> just give up partially supporting Java and either Sun or the open
> source community take it over to do it properly.
>
>
>
> Ari Maniatis
>
>
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
Re: JDBC 4 and build sanity
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 28/09/2008, at 9:00 AM, Andrus Adamchik wrote:
> This will exclude 32-bit Mac owners from the dev process (I do have
> 1 such laptop in my company, Ari probably has a few, etc...). So how
> do we make it build on 1.5 (everything except for the 1.6 module of
> course). Here is one idea: a developer may extract the new JDBC 4
> interfaces from Java 1.6 (we can provide a little script to do
> that), and build a small extension jar and drop it in the lib/ext of
> JDK 1.5. That and also we will publish 1.6 snapshots for downstream
> dependents (such as cayenne-server and cayenne-client).
>
> Thoughts on that? Maybe there are better ideas (and I may need to
> vet this little hack with Apache legal).
It may be easier to do this against OpenJDK rather than Java 6, since
the licensing is much simpler. But still, we bump into GPL licensing
of OpenJDK. The question: "is this code linked to ours" such that it
infects Cayenne code with the GPL license? Clearly implementing an
interface doesn't cause a problem (since we do that for dozens of JRE
interfaces) but can we write stubs for the interface itself and bundle
that without causing a problem? The logical answer is that we are
including no more intellectual property than simply implementing the
interface, but law is so rarely that logical.
And of course the Java 6 problem for Mac users is not just 32 bit
machines, but also 64 bit PPC machines. I can't wait until Apple just
give up partially supporting Java and either Sun or the open source
community take it over to do it properly.
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A