Re: handling the deprecations introduced by early access builds 116 and 118 of jdk 9
Thanks for that response, Stuart. One comment inline... On 5/31/16 5:34 PM, Stuart Marks wrote: On 5/30/16 11:48 AM, Richard Hillegas wrote: Dalibor Topic recommended that I post this feedback on core-libs-dev. This is my feedback after ameliorating the deprecation warnings which surfaced when I compiled and tested Apache Derby with early access builds 116 and 118 of JDK 9. Derby is a pure Java relational database whose original code goes back almost 20 years. Other large, old code bases (like Weblogic) may have similar experiences. More detail on my experience can be found on the JIRA issue which tracks the Derby community's attempt to keep our code evergreen against JDK 9: https://issues.apache.org/jira/browse/DERBY-6856 Hi Rick, Thanks for your feedback on the API deprecations. A couple notes on deprecation. First, the deprecation JEP (JEP 277) [1] has clarified the definition of deprecation so that by default it no longer means that the API will be removed. In the absence of forRemoval=true, deprecation is merely a recommendation for code to migrate away from the annotated API. Only when the forRemoval=true element is present does it mean that the API is actually going to be removed. None of these deprecations has forRemoval=true, this means that there's no great urgency for anyone to migrate away from them. Now, they will generate compilation warnings, which is quite possibly a problem. There are some existing mechanisms for disabling warnings, such as -Xlint:-deprecation and the @SuppressWarnings annotation. These might not be sufficient. We're considering adding some finer-grained mechanisms. Ideally, for deprecated APIs that aren't being removed, it should be possible to manage the warnings so that migration of any code base can proceed at whatever pace its maintainers feel is appropriate, without it being forced by any particular JDK release. This was the issue which I faced. The Derby community has spent considerable effort on maintaining a clean build, one which doesn't swamp real error indications in a blizzard of diagnostic noise. At the same time, we are reluctant to wholesale-disable all deprecation warnings because, in general, they do provide useful advice about best practices. The ameliorations you are considering do sound useful. I don't have any better suggestions at this time. Thanks, -Rick If you have any thoughts on how to better manage deprecation warnings, I'd love to hear them. o Deprecating autoboxing constructors - Deprecating the autoboxing constructors for primitive wrapper objects caused a large rototill of Derby code. That rototill was comparable in size to the changes made necessary by Java 5's introduction of generics. Hopefully, IDEs can automate much of this chore. The boxing constructors -- e.g., new Integer(432) -- are the ones being deprecated. The preferred alternative is Integer.valueOf(432). Note that *auto*boxing ends calling valueOf() under the covers. Autoboxing is generally preferable, although not without pitfalls, such as the overloading of List.remove(int) vs List.remove(Object), as you stumbled across in the referenced bug report. Using valueOf() instead of autoboxing would have avoided the error. o Deprecating Class.newInstance() - The deprecation of Class.newInstance() forced a similarly large rototill. The code became more verbose. Additional exceptions had to be caught and propagated up the call stack. For reasons which I don't understand, I had better luck using Class.getConstructor().newInstance() than Class.getDeclaredConstructor().newInstance(). But the former replacement code requires you to make constructors public. For some code bases, that may introduce security problems which are worse than the security problem being addressed by this deprecation. I hope that IDEs and the release notes for JDK 9 will provide some guidance for how to handle these issues. It would be good to understand why getDeclaredConstructor() didn't work. Clearly requiring a public no-arg constructor is a non-starter. o Deprecating java.util.Observable and java.util.Observer - Two ameliorations are recommended at http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040436.html. The first suggestion (use the awt event model) runs very much counter to the whole intent of Jigsaw. That is because pulling in awt can bloat up an application with large, otherwise unneeded libraries. Using awt was out of the question for Derby, given that the community had already invested a great deal of effort in paring back Derby's dependencies in order to let the code run on JDK 8 compact profile 2. That left us with the other option: write your own replacement classes. If a lot of people end up having to write the same replacement code, then that argues for leaving this small but useful functionality in the JDK. I think that the people who advocated for this deprecation did not have good visibility
Re: handling the deprecations introduced by early access builds 116 and 118 of jdk 9
On 6/1/16 4:15 PM, Richard Hillegas wrote: [deprecation warnings] This was the issue which I faced. The Derby community has spent considerable effort on maintaining a clean build, one which doesn't swamp real error indications in a blizzard of diagnostic noise. At the same time, we are reluctant to wholesale-disable all deprecation warnings because, in general, they do provide useful advice about best practices. The ameliorations you are considering do sound useful. I don't have any better suggestions at this time. Thanks for your followup on this, especially regarding Derby's efforts to maintain a clean build. In the JDK we've been working on warnings cleanup for several years, so we're sensitive to the issues ourselves. However, we've had little visibility into whether other code bases did anything about warnings. Some of us speculated that nobody outside the JDK cared about compiler warnings. We're happy to have been proven wrong about this. But it does mean that we need to put more effort into mechanisms to help manage these warnings. s'marks
Re: handling the deprecations introduced by early access builds 116 and 118 of jdk 9
On 5/30/16 11:48 AM, Richard Hillegas wrote: Dalibor Topic recommended that I post this feedback on core-libs-dev. This is my feedback after ameliorating the deprecation warnings which surfaced when I compiled and tested Apache Derby with early access builds 116 and 118 of JDK 9. Derby is a pure Java relational database whose original code goes back almost 20 years. Other large, old code bases (like Weblogic) may have similar experiences. More detail on my experience can be found on the JIRA issue which tracks the Derby community's attempt to keep our code evergreen against JDK 9: https://issues.apache.org/jira/browse/DERBY-6856 Hi Rick, Thanks for your feedback on the API deprecations. A couple notes on deprecation. First, the deprecation JEP (JEP 277) [1] has clarified the definition of deprecation so that by default it no longer means that the API will be removed. In the absence of forRemoval=true, deprecation is merely a recommendation for code to migrate away from the annotated API. Only when the forRemoval=true element is present does it mean that the API is actually going to be removed. None of these deprecations has forRemoval=true, this means that there's no great urgency for anyone to migrate away from them. Now, they will generate compilation warnings, which is quite possibly a problem. There are some existing mechanisms for disabling warnings, such as -Xlint:-deprecation and the @SuppressWarnings annotation. These might not be sufficient. We're considering adding some finer-grained mechanisms. Ideally, for deprecated APIs that aren't being removed, it should be possible to manage the warnings so that migration of any code base can proceed at whatever pace its maintainers feel is appropriate, without it being forced by any particular JDK release. If you have any thoughts on how to better manage deprecation warnings, I'd love to hear them. o Deprecating autoboxing constructors - Deprecating the autoboxing constructors for primitive wrapper objects caused a large rototill of Derby code. That rototill was comparable in size to the changes made necessary by Java 5's introduction of generics. Hopefully, IDEs can automate much of this chore. The boxing constructors -- e.g., new Integer(432) -- are the ones being deprecated. The preferred alternative is Integer.valueOf(432). Note that *auto*boxing ends calling valueOf() under the covers. Autoboxing is generally preferable, although not without pitfalls, such as the overloading of List.remove(int) vs List.remove(Object), as you stumbled across in the referenced bug report. Using valueOf() instead of autoboxing would have avoided the error. o Deprecating Class.newInstance() - The deprecation of Class.newInstance() forced a similarly large rototill. The code became more verbose. Additional exceptions had to be caught and propagated up the call stack. For reasons which I don't understand, I had better luck using Class.getConstructor().newInstance() than Class.getDeclaredConstructor().newInstance(). But the former replacement code requires you to make constructors public. For some code bases, that may introduce security problems which are worse than the security problem being addressed by this deprecation. I hope that IDEs and the release notes for JDK 9 will provide some guidance for how to handle these issues. It would be good to understand why getDeclaredConstructor() didn't work. Clearly requiring a public no-arg constructor is a non-starter. o Deprecating java.util.Observable and java.util.Observer - Two ameliorations are recommended at http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040436.html. The first suggestion (use the awt event model) runs very much counter to the whole intent of Jigsaw. That is because pulling in awt can bloat up an application with large, otherwise unneeded libraries. Using awt was out of the question for Derby, given that the community had already invested a great deal of effort in paring back Derby's dependencies in order to let the code run on JDK 8 compact profile 2. That left us with the other option: write your own replacement classes. If a lot of people end up having to write the same replacement code, then that argues for leaving this small but useful functionality in the JDK. I think that the people who advocated for this deprecation did not have good visibility into how widely these classes are being used in the wild. I recommend that this deprecation be re-evaluated. Observable and Observer have a long history of problem reports and enhancement requests that show that people want them to be something other than what they are. This includes: Observable should be an interface, not an abstract class; there is only one "changed" bit, without any notion of what has changed; there is no control over what thread calls observers; there is no ability to control sequence of calls to observers; change notifications aren't in one-for-one correspondence with
handling the deprecations introduced by early access builds 116 and 118 of jdk 9
Dalibor Topic recommended that I post this feedback on core-libs-dev. This is my feedback after ameliorating the deprecation warnings which surfaced when I compiled and tested Apache Derby with early access builds 116 and 118 of JDK 9. Derby is a pure Java relational database whose original code goes back almost 20 years. Other large, old code bases (like Weblogic) may have similar experiences. More detail on my experience can be found on the JIRA issue which tracks the Derby community's attempt to keep our code evergreen against JDK 9: https://issues.apache.org/jira/browse/DERBY-6856 o Deprecating autoboxing constructors - Deprecating the autoboxing constructors for primitive wrapper objects caused a large rototill of Derby code. That rototill was comparable in size to the changes made necessary by Java 5's introduction of generics. Hopefully, IDEs can automate much of this chore. o Deprecating Class.newInstance() - The deprecation of Class.newInstance() forced a similarly large rototill. The code became more verbose. Additional exceptions had to be caught and propagated up the call stack. For reasons which I don't understand, I had better luck using Class.getConstructor().newInstance() than Class.getDeclaredConstructor().newInstance(). But the former replacement code requires you to make constructors public. For some code bases, that may introduce security problems which are worse than the security problem being addressed by this deprecation. I hope that IDEs and the release notes for JDK 9 will provide some guidance for how to handle these issues. o Deprecating java.util.Observable and java.util.Observer - Two ameliorations are recommended at http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040436.html. The first suggestion (use the awt event model) runs very much counter to the whole intent of Jigsaw. That is because pulling in awt can bloat up an application with large, otherwise unneeded libraries. Using awt was out of the question for Derby, given that the community had already invested a great deal of effort in paring back Derby's dependencies in order to let the code run on JDK 8 compact profile 2. That left us with the other option: write your own replacement classes. If a lot of people end up having to write the same replacement code, then that argues for leaving this small but useful functionality in the JDK. I think that the people who advocated for this deprecation did not have good visibility into how widely these classes are being used in the wild. I recommend that this deprecation be re-evaluated. Thanks, -Rick
