[
https://issues.apache.org/jira/browse/DERBY-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135854#comment-15135854
]
Rick Hillegas commented on DERBY-6856:
--------------------------------------
I removed the PropertySetter code because it had no purpose, now that we only
build with JDK 8. The code did not work with Java 9's way of packaging classes.
We may need to revive PropertySetter or, more likely, write something else from
scratch if we want to be able to construct two different bootclasspaths, one
for Java 8 and the other for Java 9.
I would phrase what Knut said a little differently. The build had the potential
to work as Dalibor describes. But in practice, it rarely did. The Dalibor
approach was only possible when the builder's system had several JDKs at
different levels and when they were located in a place where the build could
find them. But if the build couldn't find old JDKs (the usual situation), then
the bootclasspaths were basically the jar files of the compiling JDK overlayed
with some JDBC stubs. That is, only the JDBC drivers were being compiled as
Dalibor describes. Much of what we did in this area was done in order to make
it possible for someone to build Derby out-of-the box with just the JDK
supplied by the machine--something which was a pre-requisite for being bundled
with Linux distros.
I don't know what to do about building with Java 9 and I am not planning any
dramatic work on this issue for a while. If someone else wants to push this
issue forward, they are welcome to. It used to be that the Sun/Oracle team
endured considerable contortion and pain in order to make it possible to use a
current JDK for the purpose of building JDBC drivers which implemented the
contract of a future, unreleased JDK. This made it possible for the future JDK
to bundle Derby when that JDK reached GA. However, Oracle does not seem
interested in pursuing this relationship further.
We will keep any eye on what's going into JDBC 4.3. Right now, there's nothing
of interest to Derby: just some new apis to support a ShardingKey feature which
Derby doesn't implement. But some more useful apis may go into JDBC 4.3 later
on. Someone may decide that supporting them is worth the contortion and pain
required to fix the build in order to work with both the jigsaw JDK and the
pre-jigsaw JDK.
> Make it possible to build Derby using JDK 9
> -------------------------------------------
>
> Key: DERBY-6856
> URL: https://issues.apache.org/jira/browse/DERBY-6856
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
> Affects Versions: 10.12.1.1
> Reporter: Rick Hillegas
> Attachments: derby-6856-01-ab-addShardingKey.diff,
> derby-6856-01-ac-cleanup.diff
>
>
> Derby can't be built with JDK 9. Java 9 introduces new JDBC classes like
> java.sql.ShardingKey and methods which refer to these new classes.
> In addition, project Jigsaw has created a new way to name classes (see
> http://openjdk.java.net/jeps/220). This breaks the PropertySetter build tool
> which we use so that old JVMs can compile Derby and so that Derby can be
> compiled to run on old JVMs.
> It is likely that we will need to leave this issue open throughout the
> development cycle of Java 9.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
