[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)


Yes, that's my understanding. We would use require static on java.desktop, but users wouldn't have any issues as long as they did not use the version of the class that requires java.desktop.

If the user want/needs to use those classes, then they have to add the dependency to java.desktop in their code.


Otherwise, the user just would have to update his/her code to use the new classes (the pull request is about providing this alternative).


Not perfect, but after a few releases (1? couple? major?) we can delete the deprecated classes and tests, remove the require static, and forget about this issue (-:


Bruno

________________________________
From: Gary Gregory <garydgregory@xxxxxxxxx>
To: Commons Developers List <dev@xxxxxxxxxxxxxxxxxx>; Bruno P. Kinoshita <brunodepaulak@xxxxxxxxxxxx> 
Sent: Sunday, 10 June 2018 10:56 AM
Subject: 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx