[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)


So the dependency on desktop is declared as optional but it still exists?

Gary

On Sat, Jun 9, 2018, 16:52 Bruno P. Kinoshita
<brunodepaulak@xxxxxxxxxxxx.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 <britter@xxxxxxxxxx>
> To: Commons Developers List <dev@xxxxxxxxxxxxxxxxxx>
> 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.heger@xxxxxxxxxxxxxxx>:
> >
> >
> >
> > Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
> >> On 23 May 2017 at 17:17, sebb <sebbaz@xxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxxxx
> >> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>
>