From dev-return-167824-archive-asf-public=cust-asf.ponee.io@commons.apache.org Mon Jul 16 18:13:21 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id A4446180657 for ; Mon, 16 Jul 2018 18:13:20 +0200 (CEST) Received: (qmail 36906 invoked by uid 500); 16 Jul 2018 16:13:19 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 36885 invoked by uid 99); 16 Jul 2018 16:13:18 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jul 2018 16:13:18 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 83FEE1A2631 for ; Mon, 16 Jul 2018 16:13:18 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 5EC5vrZjk4FZ for ; Mon, 16 Jul 2018 16:13:16 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id E298E5F3EA for ; Mon, 16 Jul 2018 16:13:15 +0000 (UTC) Received: from [192.168.178.20] ([88.64.145.5]) by mrelayeu.kundenserver.de (mreue003 [212.227.15.167]) with ESMTPSA (Nemesis) id 0LjfP2-1gBy1z1fKK-00ba7X for ; Mon, 16 Jul 2018 18:13:15 +0200 Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0) To: dev@commons.apache.org References: <775E823F-08D8-4954-8A0A-CDEFE4B0604C@apache.org> <1729266809.2969680.1528584721484@mail.yahoo.com> <4b33eb42-04a4-f951-1713-e099e71e556a@oliver-heger.de> <448781044.4687067.1531741233581@mail.yahoo.com> From: Oliver Heger Openpgp: preference=signencrypt Autocrypt: addr=oliver.heger@oliver-heger.de; prefer-encrypt=mutual; keydata= xsBNBFHq5ioBCADFSKoqaIK0hy41wK60Gdw1a+qMdsU8KTP94ytXU65m+wiUxgs3p/931Kog 1+djgQuznc57dQ1N0grIN83n2GxrtaILttJMTgZMBxserC5F8AhMWwHWsLshEsV3FY8wvW7e ck5EvwhwfzGF8TAZmvkfN6u4/9vyVjhDBECd2xBsHpgirAKOcBk5tED9cqYvLhlVrGAbqRjS KoBIpdJykHAUYhiiAo8fVPfxo1VqBtAqQPVf2dYX20XeQZkaVneOkfscAOWj7gju/s5gaG8C nklpIxqS+eqvTCX7Q3Atf1MTIejB/cKhUv6smr3NbqS6P2zzm5cZ6mUUB5Dpz88MQzWNABEB AAHNK09saXZlciBIZWdlciA8b2xpdmVyLmhlZ2VyQG9saXZlci1oZWdlci5kZT7CwH4EEwEC ACgFAlHq5ioCGyMFCQlmAYAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEDgk3dGBGEE4 wQEIAK28kTNwr9RyF1Xrn50HOrPBVjuEi03gaaC9aY+RI5CA00G7KYW9+5yc2nQcykEQBawT vKZ8iv3fFXjOpDVkOLZI3tCnmSGoVUtNrS4PbOsOoDX8lELtWZrMKKuDDl/nFZCo/FzDwk1F MPoyZBgluy3Uy481BxSxsPoSoHqyM2dLCRIme1yI+/5yXnQ04G45FShXvAEreB8+KTmFJelu Vt7AM+/JbIArrQvGdjQex9DfdejgSm3MdnNZYwLT/8J8kgIfEfIwtVGro1LT+/7DTcr06lzW dpx0XwV2VfTmWIz/V7MyiU9VlCjSMJnNpWWprWnx8l63mqcw63G32DFiRQXOwE0EUermKgEI AM2HBe11k0j5XwCJ1plR7qpY65rMUEmkqWsgWHXw6WukOySRRotsORw2EQN+G51b4yWK4yAe uH2V2iT31eSDQt6npslsDhGUfvz+QPb7XoxzgOyI5+ABHFM6uYlIasCjSwB5I8ojy4tguZ+D cq7l1JAHGjVKFh9jZuiUeTadeylTIusArllAHCNv5mmgdyG/WUE7mGSliIJB6yUOMlF4FLUj k1h4AXSHGO7omNM0oXf4XRzOXshe69n7GuBMvyi/l4dXVpOWKcPo9llTKT8i7VeY2YESVfp7 USnUgbsy/7HgsCfSLkY3wqjugSzvQiWmsE51thxD6UqO3/2+IMLn4YkAEQEAAcLAZQQYAQIA DwUCUermKgIbDAUJCWYBgAAKCRA4JN3RgRhBOFzfB/41f7PwJKlRGfG2icEV9Ukq9QhNqBLF WFQmhNR7/urVbBi8MvG3SF4jA+4Ip/lAs6OA7hhb5ZAYjeM+eJmQ3alqqBJ7teNbTMbmMsV/ XzEHk85Zh6K/8NV7jOpOaC8XaMBN47AuZW1oZrI/1K05z2RIaRiWt0YGyvVuOErpQZThExrE DCRppiDj3T/eQCr3wZtWYlBo1Ix1ak6YJftWBpMyJqolICSInaq8AJaRhu1nfcdTfrjastP+ 6PEmJyVs3NY5Hf+DZVlGWC9aFFei78UXD2JNj+B2ygRykJmJYrwxF7oh6ylYINJ3QBzqneLH HUVzJ9dzvdQsTvTVkDZnzjcQ Message-ID: Date: Mon, 16 Jul 2018 18:13:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <448781044.4687067.1531741233581@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:Y/04Lmbf1ZKnQd54zVCYrmdYwPSjwux60scf9QjjGKGddsgg8qn kDjyJmgafh/T1RP3UCkrN2LJuCWHQMFc9YCM9JLidzCcP+kvKfnGxGkM8cjq5ITa0fl21u6 OtRYXEdTwiaUep719+d9ys1oPELOKpcAaUCYBeXuHuTHMG/XJG+S48EQXaX5fTo+6ebheKi vcba6N1TmHaBsPwDWg62A== X-UI-Out-Filterresults: notjunk:1;V01:K0:lp5tullQgdU=:fH1YGOdvmKBd5VWfGrsW2H MyNhEcaBNE+3nSMKxWPwtEtU6MAUuvMHjxGI5X7pyNDbQgd6qU9kam1IOuWNU1OuQ7XZ81OVg 86eu2R49UmfQMK7HkltLufaepSA8fiFUCalbwJ9G/3oY+Tnl8TpnLgutU/WsCOzr2wPRsoQs8 qEGY3wnK9fOqS9oSzT+82ZVgIbCmh5CXiaQwK7ZUSYyuebPHZ2zBGBAsg5QmUE7HoPEBnb5D2 2/oN6Ydj0OeRcY9s8GKReqYeD1vlMY1L0IxPRJA0rfAuncGq3F35MtGypQuCOuFgjzaxTlAPR VXUK1p1mPpwJa40V7oPB/2IEedSBZD2Oupyg+h4p4Oi9qscH4oC24UpIBGw97Vp8bVTcLpGbF zgflq/L3zMbwY8aLcPhKcZpvj/vr3weUJOX7Debk32SB4WfL7iwQfFEYaAILDxbrP5lRmh7N4 mi3ylXH/H65pTBzibKM3fY/ko/6pDxi8Okq4eP7bnj9H+KrAOiUrGdFhI2hS8cWG6Y3r7+jTd aTcYNOVleCQt9VL2ImwEmLUzp21aJCvfOtP7hIVPQPzaEzfTNit6Bpluo3x0sBSVYAbBUnxkb cRKED0DfRXvBHaqSz2J99i3z9xJiYShDY9ho/RWwThnwfG3qum+arPHC0+WOllTrJOE+DBrmC apatYQN4Ocitxrz7C4/2WshI3TUWEJls+eUcjSr2Mv8BzXCtXKnwMEndMiwQS/zdcohB0OPG5 ZDikdZsRZFVz2DM8 Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita: > Saw some recent activity around lang 3.8, and remembered about this issue, and then looked for this thread. > > Gilles' point is really good! Here's the Java 9 docs with the deprecation warning, copied below as well https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html > > > "This class and the Observer interface have been deprecated. The event model supported by Observer and Observable is quite limited, the order of notifications delivered by Observable is unspecified, and state changes are not in one-for-one correspondence with notifications. For a richer event model, consider using the java.beans package. For reliable and ordered messaging among threads, consider using one of the concurrent data structures in the java.util.concurrent package. For reactive streams style programming, see the Flow API." > > > > So I guess the best we can do right now is add the @deprecated annotations, with an explanation in the javadocs. And also add a note about it in the release notes. > > Does that sound like a good plan? Adding a link to this thread in the pull request as well. > What about introducing our own state listener interface? The original interface from the beans package was used just for convenience because it already existed. But it would of course be possible to have a simple functional interface to notify listeners about state changes. Oliver > > Cheers > Bruno > > > > > ________________________________ > From: Stephen Colebourne > To: Commons Developers List > 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 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 >>>> >>>> To: Commons Developers List >>>> 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 >>>>> : >>>>> >>>>> >>>>> >>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne: >>>>>> >>>>>> On 23 May 2017 at 17:17, sebb 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@commons.apache.org >> For additional commands, e-mail: dev-help@commons.apache.org > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org