You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <ri...@oracle.com> on 2011/06/30 18:39:46 UTC
Sunsetting support for Derby on JVM 1.4
No-one on the user list has objected to sunsetting support for JVM 1.4
starting with Derby 10.9. There is still some interest in supporting
small devices on CDC/FP 1.1. Sunsetting support for JVM 1.4 would mean
that we would stop running regression tests on that platform (starting
with Derby 10.9) and we would not spend a lot of effort chasing problems
on that platform.
Because we would continue supporting CDC/FP 1.1, we would not be able to
modernize the bulk of Derby code to take advantage of language features
introduced by Java 5. These features include enums, annotations, and
generics.
I would like to move ahead with sunsetting support for JVM 1.4. I'm
happy to call a formal vote to ratify this change if people think that
would be useful. What are your thoughts?
Thanks,
-Rick
Re: Sunsetting support for Derby on JVM 1.4
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Kathey Marsden <km...@sbcglobal.net> writes:
> On 7/1/2011 6:28 AM, Knut Anders Hatlen wrote:
>>
>> I wouldn't think this rules out running the client on small devices in
>> the future, since small devices in the future (maybe even now) will
>> hopefully support less constrained environments than CDC FP 1.1.
>>
>> If it turns out Java 1.4 indeed is the future on small devices, I'd be
>> somewhat disappointed... ;)
>>
> Yes I think all agree 1.4 is out of the picture everywhere and I agree
> small devices are getting bigger.
>
> One other thing that we might want to consider as a development
> community and something that we havealways been pretty good about,
> is that we try to keep refactoring and syntax changes separate from
> behavior changes to facilitate ease of review of patches, backporting
> and tracking down regressions. I wonder if it makes sense to defer
> any heavy duty reorganization until after 10.8.2 so it doesn't
> interfere with backporting efforts for the fall release.
Makes sense. +1 to that.
--
Knut Anders
Re: Sunsetting support for Derby on JVM 1.4
Posted by Kathey Marsden <km...@sbcglobal.net>.
On 7/1/2011 6:28 AM, Knut Anders Hatlen wrote:
>
> I wouldn't think this rules out running the client on small devices in
> the future, since small devices in the future (maybe even now) will
> hopefully support less constrained environments than CDC FP 1.1.
>
> If it turns out Java 1.4 indeed is the future on small devices, I'd be
> somewhat disappointed... ;)
>
Yes I think all agree 1.4 is out of the picture everywhere and I agree
small devices are getting bigger.
One other thing that we might want to consider as a development
community and something that we havealways been pretty good about, is
that we try to keep refactoring and syntax changes separate from
behavior changes to facilitate ease of review of patches, backporting
and tracking down regressions. I wonder if it makes sense to defer any
heavy duty reorganization until after 10.8.2 so it doesn't interfere
with backporting efforts for the fall release.
Thanks
Kathey
Re: Sunsetting support for Derby on JVM 1.4
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Kathey Marsden <km...@sbcglobal.net> writes:
> On 7/1/2011 1:23 AM, Knut Anders Hatlen wrote:
>> Mike Matrigali<mi...@sbcglobal.net> writes:
>>
>>> Rick Hillegas wrote:
>>>> No-one on the user list has objected to sunsetting support for JVM
>>>> 1.4 starting with Derby 10.9. There is still some interest in
>>>> supporting small devices on CDC/FP 1.1. Sunsetting support for JVM
>>>> 1.4 would mean that we would stop running regression tests on that
>>>> platform (starting with Derby 10.9) and we would not spend a lot of
>>>> effort chasing problems on that platform.
>>>>
>>>> Because we would continue supporting CDC/FP 1.1, we would not be
>>>> able to modernize the bulk of Derby code to take advantage of
>>>> language features introduced by Java 5. These features include
>>>> enums, annotations, and generics.
>>>>
>>>> I would like to move ahead with sunsetting support for JVM 1.4. I'm
>>>> happy to call a formal vote to ratify this change if people think
>>>> that would be useful. What are your thoughts?
>>>>
>>>> Thanks,
>>>> -Rick
>>>>
>>> I am not sure what it means in open source for such a vote. If anyone
>>> wants to run tests and fix issues for JVM 1.4 or any other JVM that
>>> seems fine to me. Individual contributors as always can decide which
>>> features and bugs to work on. It would be different if we were
>>> deciding to actively check
>>> in things to the default Derby set of features that we know would not
>>> work against JVM 1.4 architecture.
>>>
>>> As I understand it nothing is changing.
>>> The default set of Derby 10.9 is designed to work
>>> against the JDK 1.4 spec, and allows extensions against more recent
>>> specs for features designed to be "optional and/or enhanced".
>> I was hoping that if we agreed on not supporting Java 1.4 anymore, it
>> would allow us to start using Java 5 features in those areas of the code
>> that aren't used on Java ME. In particular, I was hoping that it opened
>> for the following improvements:
>>
>> - Using Java 5 features in the client driver and the network server.
>>
> I am glad you mentioned this, because I hadn't really thought of it
> this way. Does this mean that we are ruling out client on small
> devices in the future? I am not sure that I (or anyone I know) has
> time to do this but it seems like it would be useful.
The client has never run on CDC devices, and I've never heard of any
plans to implement support for it. And given that our probes both here
and on derby-user have resulted in no one saying they're using Derby on
such devices, I think the likelihood of it being done is close to zero.
I wouldn't think this rules out running the client on small devices in
the future, since small devices in the future (maybe even now) will
hopefully support less constrained environments than CDC FP 1.1.
If it turns out Java 1.4 indeed is the future on small devices, I'd be
somewhat disappointed... ;)
--
Knut Anders
Re: Sunsetting support for Derby on JVM 1.4
Posted by Kathey Marsden <km...@sbcglobal.net>.
On 7/1/2011 1:23 AM, Knut Anders Hatlen wrote:
> Mike Matrigali<mi...@sbcglobal.net> writes:
>
>> Rick Hillegas wrote:
>>> No-one on the user list has objected to sunsetting support for JVM
>>> 1.4 starting with Derby 10.9. There is still some interest in
>>> supporting small devices on CDC/FP 1.1. Sunsetting support for JVM
>>> 1.4 would mean that we would stop running regression tests on that
>>> platform (starting with Derby 10.9) and we would not spend a lot of
>>> effort chasing problems on that platform.
>>>
>>> Because we would continue supporting CDC/FP 1.1, we would not be
>>> able to modernize the bulk of Derby code to take advantage of
>>> language features introduced by Java 5. These features include
>>> enums, annotations, and generics.
>>>
>>> I would like to move ahead with sunsetting support for JVM 1.4. I'm
>>> happy to call a formal vote to ratify this change if people think
>>> that would be useful. What are your thoughts?
>>>
>>> Thanks,
>>> -Rick
>>>
>> I am not sure what it means in open source for such a vote. If anyone
>> wants to run tests and fix issues for JVM 1.4 or any other JVM that
>> seems fine to me. Individual contributors as always can decide which
>> features and bugs to work on. It would be different if we were
>> deciding to actively check
>> in things to the default Derby set of features that we know would not
>> work against JVM 1.4 architecture.
>>
>> As I understand it nothing is changing.
>> The default set of Derby 10.9 is designed to work
>> against the JDK 1.4 spec, and allows extensions against more recent
>> specs for features designed to be "optional and/or enhanced".
> I was hoping that if we agreed on not supporting Java 1.4 anymore, it
> would allow us to start using Java 5 features in those areas of the code
> that aren't used on Java ME. In particular, I was hoping that it opened
> for the following improvements:
>
> - Using Java 5 features in the client driver and the network server.
>
I am glad you mentioned this, because I hadn't really thought of it this
way. Does this mean that we are ruling out client on small devices in
the future? I am not sure that I (or anyone I know) has time to do
this but it seems like it would be useful.
Re: Sunsetting support for Derby on JVM 1.4
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Mike Matrigali <mi...@sbcglobal.net> writes:
> Rick Hillegas wrote:
>> No-one on the user list has objected to sunsetting support for JVM
>> 1.4 starting with Derby 10.9. There is still some interest in
>> supporting small devices on CDC/FP 1.1. Sunsetting support for JVM
>> 1.4 would mean that we would stop running regression tests on that
>> platform (starting with Derby 10.9) and we would not spend a lot of
>> effort chasing problems on that platform.
>>
>> Because we would continue supporting CDC/FP 1.1, we would not be
>> able to modernize the bulk of Derby code to take advantage of
>> language features introduced by Java 5. These features include
>> enums, annotations, and generics.
>>
>> I would like to move ahead with sunsetting support for JVM 1.4. I'm
>> happy to call a formal vote to ratify this change if people think
>> that would be useful. What are your thoughts?
>>
>> Thanks,
>> -Rick
>>
> I am not sure what it means in open source for such a vote. If anyone
> wants to run tests and fix issues for JVM 1.4 or any other JVM that
> seems fine to me. Individual contributors as always can decide which
> features and bugs to work on. It would be different if we were
> deciding to actively check
> in things to the default Derby set of features that we know would not
> work against JVM 1.4 architecture.
>
> As I understand it nothing is changing.
> The default set of Derby 10.9 is designed to work
> against the JDK 1.4 spec, and allows extensions against more recent
> specs for features designed to be "optional and/or enhanced".
I was hoping that if we agreed on not supporting Java 1.4 anymore, it
would allow us to start using Java 5 features in those areas of the code
that aren't used on Java ME. In particular, I was hoping that it opened
for the following improvements:
- Using Java 5 features in the client driver and the network server.
- Using Java 5 features in the JDBC layer (except in the JSR-169
classes).
- Simplify the JDBC class hierarchies (example: the wrapper methods in
EmbedStatement40 and EmbedPreparedStatement40 could be moved to a
common super-class instead of being duplicated. Similarly, the various
DataSource implementations could be made JDBC 4.0 compliant without
the users specifying the "40" suffix in the class names.)
So I'd really like to have a vote, and what we are voting over is
whether we are allowed to use Java 5 features in code that's not meant
to run on Java ME. If the proposal is just to stop testing and caring
for Java 1.4-specific bugs, I agree that no vote is needed, as no one is
forced to run tests or fix bugs in the first place.
--
Knut Anders
Re: Sunsetting support for Derby on JVM 1.4
Posted by Rick Hillegas <ri...@oracle.com>.
On 6/30/11 1:17 PM, Mike Matrigali wrote:
> Rick Hillegas wrote:
>> No-one on the user list has objected to sunsetting support for JVM
>> 1.4 starting with Derby 10.9. There is still some interest in
>> supporting small devices on CDC/FP 1.1. Sunsetting support for JVM
>> 1.4 would mean that we would stop running regression tests on that
>> platform (starting with Derby 10.9) and we would not spend a lot of
>> effort chasing problems on that platform.
>>
>> Because we would continue supporting CDC/FP 1.1, we would not be able
>> to modernize the bulk of Derby code to take advantage of language
>> features introduced by Java 5. These features include enums,
>> annotations, and generics.
>>
>> I would like to move ahead with sunsetting support for JVM 1.4. I'm
>> happy to call a formal vote to ratify this change if people think
>> that would be useful. What are your thoughts?
>>
>> Thanks,
>> -Rick
>>
> I am not sure what it means in open source for such a vote. If anyone
> wants to run tests and fix issues for JVM 1.4 or any other JVM that
> seems fine to me. Individual contributors as always can decide which
> features and bugs to work on. It would be different if we were
> deciding to actively check
> in things to the default Derby set of features that we know would not
> work against JVM 1.4 architecture.
>
> As I understand it nothing is changing.
> The default set of Derby 10.9 is designed to work
> against the JDK 1.4 spec, and allows extensions against more recent
> specs for features designed to be "optional and/or enhanced".
Hi Mike,
Our release notes claim that Derby runs on a spectrum of platforms,
backed up by an audit trail of release testing results. See for
instance:
http://db.apache.org/derby/releases/release-10.8.1.2.cgi#Overview and
http://wiki.apache.org/db-derby/TenEightOnePlatformTesting. Since we are
proposing to stop testing on JVM 1.4, there will be no audit trail for a
claim that Derby runs on that platform. In 10.9 we will drop the claim
that we run there. That is a customer-visible change which the community
might want to vote on.
Thanks,
-Rick
Re: Sunsetting support for Derby on JVM 1.4
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Rick Hillegas wrote:
> No-one on the user list has objected to sunsetting support for JVM 1.4
> starting with Derby 10.9. There is still some interest in supporting
> small devices on CDC/FP 1.1. Sunsetting support for JVM 1.4 would mean
> that we would stop running regression tests on that platform (starting
> with Derby 10.9) and we would not spend a lot of effort chasing problems
> on that platform.
>
> Because we would continue supporting CDC/FP 1.1, we would not be able to
> modernize the bulk of Derby code to take advantage of language features
> introduced by Java 5. These features include enums, annotations, and
> generics.
>
> I would like to move ahead with sunsetting support for JVM 1.4. I'm
> happy to call a formal vote to ratify this change if people think that
> would be useful. What are your thoughts?
>
> Thanks,
> -Rick
>
I am not sure what it means in open source for such a vote. If anyone
wants to run tests and fix issues for JVM 1.4 or any other JVM that
seems fine to me. Individual contributors as always can decide which
features and bugs to work on. It would be different if we were deciding
to actively check
in things to the default Derby set of features that we know would not
work against JVM 1.4 architecture.
As I understand it nothing is changing.
The default set of Derby 10.9 is designed to work
against the JDK 1.4 spec, and allows extensions against more recent
specs for features designed to be "optional and/or enhanced".
Re: Sunsetting support for Derby on JVM 1.4
Posted by Kathey Marsden <km...@sbcglobal.net>.
On 6/30/2011 9:39 AM, Rick Hillegas wrote:
>
> I would like to move ahead with sunsetting support for JVM 1.4. I'm
> happy to call a formal vote to ratify this change if people think that
> would be useful. What are your thoughts?
>
I think a vote would be good for the record on JDK 1.4.2.
After thinking about it, I am glad we aren't giving up on small
devices. I think it would be impossible to go back if we gave it up.
Perhaps sometime the J2ME specification will adopt the more modern
constructs.
Kathey
Re: Sunsetting support for Derby on JVM 1.4
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Knut Anders Hatlen <kn...@oracle.com> writes:
> Bryan Pendleton <bp...@gmail.com> writes:
>
>>> o This also means that Java 5 language features can be used in
>>> client code, network server code, and in the embedded JDBC
>>> classes which are not loaded when running at the JSR 169 level.
>>
>> I think the plan is great!
+1
Dag
Re: Sunsetting support for Derby on JVM 1.4
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Bryan Pendleton <bp...@gmail.com> writes:
>> o This also means that Java 5 language features can be used in client code, network server code, and in the embedded JDBC
>> classes which are not loaded when running at the JSR 169 level.
>
> I think the plan is great!
+1
> I'm sure I'll forget what can be used where, though.
>
> Can we ensure that the build scripts enforce the rules so that we
> have a crutch to help avoid accidental mistakes?
We should only change the compile classpath and source/target level in
the build targets used to compile the classes in which we allow Java 5
features. Then the build script could continue to use
java14compile.classpath and jsr169compile.classpath to build the core
engine. So if those properties are set up properly, the build should
fail if Java 5 features are used where not allowed.
It won't always notice if we use Java 1.4 features that are not in FP,
though, since we don't compile the entire core against
jsr169compile.classpath. But that's no change from the current
situation, see DERBY-3484.
--
Knut Anders
Re: Sunsetting support for Derby on JVM 1.4
Posted by Bryan Pendleton <bp...@gmail.com>.
> o This also means that Java 5 language features can be used in client code, network server code, and in the embedded JDBC
> classes which are not loaded when running at the JSR 169 level.
I think the plan is great!
I'm sure I'll forget what can be used where, though.
Can we ensure that the build scripts enforce the rules so that we
have a crutch to help avoid accidental mistakes?
thanks,
bryan
Re: Sunsetting support for Derby on JVM 1.4
Posted by Rick Hillegas <ri...@oracle.com>.
Thanks to everyone for the discussion so far. Here is a revised
statement of what we would like to do:
o The 10.8 family of releases will be the last family supporting JVM 1.4.
o Starting with 10.9, Derby will no longer support JVM 1.4.
o This means that 10.9 will not be tested on JVM 1.4.
o This also means that Java 5 language features can be used in client
code, network server code, and in the embedded JDBC classes which are
not loaded when running at the JSR 169 level.
o Release notes for the 10.9 family will claim that we support the
following JDBC levels on the following platforms:
- JSR 169 on CDC/FP 1.1
- JDBC 3.0 on Java 5
- JDBC 4.1 on Java 6 and Java 7
How does this sound?
Thanks,
-Rick