Great catch indeed Gilles.
So perhaps just leave the deprecated, with no replacement? And then add a note in the next release that those classes will be removed in the future? B ________________________________ From: Stephen Colebourne <scolebou...@joda.org> To: Commons Developers List <dev@commons.apache.org> Sent: Monday, 11 June 2018 9:26 AM Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0) Good spot. I think that means [lang] would have to have its own copy of the JDK interfaces. or just deprecate the functionality without replacement. Stephen On 10 June 2018 at 22:11, Gilles <gil...@harfang.homelinux.org> wrote: > Hello. > > On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote: >> >> Hi Bruno, >> >> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita: >>> >>> Hi all, >>> >>> There is a patch [1] for LANG-1339 [2] that I would like to merge. The >>> discussion around this issue can be found in the rest of this e-mail thread. >>> >>> The patch basically deprecates the existing classes that depend on >>> java.desktop, and provide alternative implementations. The previous classes >>> used java.desktop classes for the PropertyChangeListener. And the >>> alternative ones instead use Java 7's java.util.Observer. > > > Is it a good idea to use deprecated classes[1] in new code? > > Regards, > Gilles > > [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html > > >>> >>> >>> This will make it easier to provide [lang] as java 9, without requiring >>> users to include a dependency to java.desktop. >>> Planning to merge it during the next week if there are no objections >>> here. >>> >>> Thanks, >>> Bruno >> >> >> agreed. This seems to be the best what we can do. >> >> Oliver >> >>> >>> >>> [1] https://github.com/apache/commons-lang/pull/275 >>> >>> [2] https://issues.apache.org/jira/browse/LANG-1339 >>> >>> >>> >>> ________________________________From: Benedikt Ritter >>> <brit...@apache.org> >>> To: Commons Developers List <dev@commons.apache.org> >>> Sent: Monday, 5 June 2017 10:49 PM >>> Subject: [LANG] Java 9 problems because of dependencies to java.desktop >>> (Was: Re: [LANG] Thoughts about Lang 4.0) >>> >>> >>> >>> >>>> Am 25.05.2017 um 18:23 schrieb Oliver Heger >>>> <oliver.he...@oliver-heger.de>: >>>> >>>> >>>> >>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne: >>>>> >>>>> On 23 May 2017 at 17:17, sebb <seb...@gmail.com> wrote: >>>>>>> >>>>>>> Yes, the >>>>>>> code compiles and both can be on the classpath, but it is a pain to >>>>>>> use, just a different kind of hell. >>>>>> >>>>>> >>>>>> I don't see what the problem is here. >>>>> >>>>> >>>>> Library A that depends on lang3 returns a Pair. >>>>> Library B that depends on lang4 takes a Pair. >>>>> Application cannot pass Pair from A to the B without conversion. >>>>> >>>>> My point is that it is possible to over-worry about jar hell. >>>>> Joda-Time removed some methods when it went from v1.x to v2.x, but >>>>> didn't change package name or maven co-ordinates. It was far more >>>>> important that end-users didn't have two different LocalDate classes >>>>> (a problem that couldn't be avoided when moving to Java 8). I've never >>>>> seen any feedback about the incompatibility causing jar hell. >>>>> >>>>> The same is true here. It is vital to think properly about which is >>>>> the worse choice, not just assume that jar hell must always be >>>>> avoided. >>>>> >>>>> I remain completely unconvinced that removing these two problematic >>>>> methods justifies the lang4 package name, forcing end-users to have >>>>> three copies of the library on the classpath. It should need much, >>>>> much more to justify lang4 package name. In fact I've yet to hear >>>>> anything else much in this thread that justifies a major release. >>>> >>>> >>>> I also think that a new major release just to fix this problem would be >>>> overkill and cause clients even more trouble. >>>> >>>> Would the following approach work as a compromise: >>>> >>>> - [lang] declares an optional dependency to the desktop module. >>>> - All affected classes (AbstractCircuitBreaker and its two sub classes) >>>> are marked as deprecated. >>>> - Copies are created from the original classes with slightly changed >>>> names or in a new package (tbd). These copies use a new change listener >>>> mechanism. >>>> >>>> IIUC, the resulting [lang] module can now be used without the dependency >>>> to desktop when the new classes are used. The dependency will only be >>>> needed for the deprecated versions. >>> >>> >>> Let’s do it like this. Sounds like the right way to me. >>> >>> Benedikt >>> >>>> >>>> Oliver >>>> >>>>> >>>>> Stephen >>>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
