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. > > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
