osdir.com

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


Good spot. I think that means [lang] would have to have its own copy
of the JDK interfaces. or just deprecate the functionality without
replacement.
Stephen

On 10 June 2018 at 22:11, Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx> wrote:
> 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
>>> <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