git.net

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


What’s the minimum target jre?  If 8 or later, use java.util.BiConsumer.  Otherwise, create a custom @FunctionalInterface. 

Chas

> On Jun 10, 2018, at 2:52 PM, Bruno P. Kinoshita <brunodepaulak@xxxxxxxxxxxx.INVALID> wrote:
> 
> Great catch indeed Gilles.
> 
> 
> So perhaps just leave the deprecated, with no replacement? And then add a note in the next release that those classes will be removed in the future?
> 
> B
> 
> ________________________________
> From: Stephen Colebourne <scolebourne@xxxxxxxx>
> To: Commons Developers List <dev@xxxxxxxxxxxxxxxxxx> 
> Sent: Monday, 11 June 2018 9:26 AM
> Subject: 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
> 
> ---------------------------------------------------------------------
> 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