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
