Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <2007085765.1228914525588.JavaMail.jira@brutus>
Date: Wed, 10 Dec 2008 05:08:45 -0800 (PST)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-3966) Do not require JRE 1.4 libraries at
 compile time since SUN's JDK 1.4 went out of support and can be used on JRE
 1.4 without any problem
In-Reply-To: <1063177997.1227811364568.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655194#action_12655194 ] 

Knut Anders Hatlen commented on DERBY-3966:
-------------------------------------------

> I have experimented with building Derby without jdk1.4. I started
> out by setting java14compile.classpath to be the JDBC3 stubs plus
> the small device classpath. I tripped across a number of issues. The
> good news is that I think our small device support should not raise
> verification errors at runtime. The bad news is that we need more
> libraries and stubs in order to build Derby without jdk1.4.

You mean in order to build against CDC/FP 1.1? I managed to build
Derby without JDK 1.4 by just adding xalan.jar and
serializer.jar.

Making it possible to compile the engine against CDC/FP 1.1 is not
required to fix this issue. It does add extra compile-time checks if
you have the FP 1.1 libraries installed, which is good, but this issue
is about removing JDK 1.4 as a requirement for building
Derby. Although making the engine compile against FP 1.1 is useful and
does not conflict with the goals of this issue, I don't think it
contributes to solving it either. Perhaps it's better to file it as a
separate issue and make the necessary improvements after this issue
has been resolved?

> [...]
> 2) Database encryption will not work on small devices unless you
> include the encryption libraries. In order to compile the encryption
> support, I needed the following JCE jar file:
>
>     jce1_2_2.jar

Sun's JDK has jce.jar under jre/lib. IBM has one that's called
ibmjcefw.jar under jre/lib. Could we make the build system smart
enough to wire in those?

> ---------------------------------------------------------
>
> The following limitations are known already too, I think. I believe
> that our small device documentation should highlight the fact that
> these features are not available on small devices:
>
> 3) Non-blocking i/o will not be used on small devices. To compile
> this feature, we need stubs frm the following jdk1.4 packages:
> [...]
> 4) Java EE resource manager support probably doesn't make sense on
> small devices. In any event, to compile resource manager support, we
> need stubs from the following jdk1.4 packages:
> [...]
> 5) Java Principal-based security may not make much sense on small
> devices. In any event, to compile it, we need stubs from the
> following jdk1.4 packages:
> [...]
> 6) LDAP-based authentication may not make much sense on small
> devices. In any event, to compile it, we need stubs from the
> following jdk1.4 packages:
> [...]
> 7) SSL encryption may not make much sense on small devices. In any
> event, to compile it, we need stubs from the following jdk1.4
> packages:
> [...]
> 8) Replication may not make much sense on small devices. In any
> event, in order to compile Replication, we need stubs from the
> following jdk1.4 packages:
> [...]

The things mentioned above only run on JDK 1.4 and higher and should
be compiled against JDK 1.4, not FP 1.1, I think.

> ---------------------------------------------------------
>
> The following other issues arose in compiling the network client:

We don't have a JSR 169 implementation of the client driver, so it
should still be compiled against JDK 1.4, or?

> ---------------------------------------------------------
>
> Finally, our tests rely on the following classes/methods not present in CDC/FP 1.1:

Not all of the tests are supposed to run on CDC/FP 1.1, so it's
probably OK to continue to compile them against JDK 1.4. At least
those tests that are not supposed to run on FP.

> I was able to successfully build the core engine by applying the
> derby-3966-02-aa-buildTools.diff patch and setting
> java14compile.classpath as follows:
>
> java14compile.classpath=${jdbc3stubs}:${xalanlib}/xml-apis.jar:${xalanlib}/xalan.jar:${tmplib}:${jcelib}/jce1_2_2.jar:${jsr169compile.classpath}
>
> where tmplib is a directory containing the following jdk1.4 classes:

I'm not following you. Are you suggesting that we add stubs for the
JDK 1.4 classes that we are already using? How does that prevent us
from using them in places of the code where they're not supposed to be
used. And does that mean that if we have legitimate new uses of
classes/methods not present in FP 1.1 (because the code is not used by
the JSR 169 driver), we'd have to add stubs for them?

I still think that problem is orthogonal to the problem for which this
issue was filed, but here's how I think we should attack that problem:

1) make compile.classpath point to jsr169compile.classpath instead of
   java14compile.classpath

2) make sure all code that should run on CDC/FP 1.1 is compiled
   against compile.classpath and not java14compile.classpath (I think
   this is true for most of the code now)

3) make sure all code that should run on JDK 1.4, but not on CDC/FP
   is compiled against java14compile.classpath

Redefining java14compile.classpath to be a hybrid between JDK 1.4 and
FP 1.1 doesn't solve any of the problems, since it still makes it
possible to introduce JDK 1.4 code in the JSR 169 driver, and it makes
it harder to use the full power of JDK 1.4 in code that is only used
in JDK>=1.4.

So what I think we should do next in this issue, is to set
java14compile.classpath to java15compile.classpath if JDK 1.4 is not
available (and add the Xalan jars for the compilation of
SqlXmlUtil). This removes the dependency on JDK 1.4, but it still
allows us to compile Derby against JDK 1.4, with the same level of
compile-time checks as today, if we have it installed.

> Do not require JRE 1.4 libraries at compile time since SUN's JDK 1.4 went out of support and can be used on JRE 1.4 without any problem
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3966
>                 URL: https://issues.apache.org/jira/browse/DERBY-3966
>             Project: Derby
>          Issue Type: Task
>          Components: Build tools
>            Reporter: Pedro Faundez Gonzalez
>         Attachments: derby-3966-01-aa-jdbc3stubs.diff, derby-3966-01-ab-jdbc3jdbc4stubs.diff, derby-3966-01-ac-jdbc3jdbc4stubs.diff, derby-3966-02-aa-buildTools.diff
>
>
> In the "JDK 1.4 support" conversation at Derby Users:
> http://www.nabble.com/JDK-1.4-support--td20650279.html
> I made a point that JRE 1.4 should not be required for build since SUN's JRE 1.4 went End Of Life.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.