What’s the minimum target jre? If 8 or later, use java.util.BiConsumer. Otherwise, create a custom @FunctionalInterface.
Chas > On Jun 10, 2018, at 2:52 PM, Bruno P. Kinoshita > <brunodepau...@yahoo.com.br.INVALID> wrote: > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
