So the dependency on desktop is declared as optional but it still exists? Gary
On Sat, Jun 9, 2018, 16:52 Bruno P. Kinoshita <brunodepau...@yahoo.com.br.invalid> wrote: > 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 > > > [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 > >
