Re: [beanutils] Java plaform for 2.0
for 90%+ normal user each version under which spring using be OK From: Richard Zowalla Sent: Saturday, September 14, 2024 12:59:15 PM To: Commons Developers List Subject: Re: [beanutils] Java plaform for 2.0 My 2 cents are: BeanUtils is often used in the EE ecosystem EE 9.1 targets 8/11, EE 10 targets 11/17, EE 11 targets 17 or higher. People are still doing the EE8 to 9.1/10 move (thanks to the name change). So perhaps 11 or 17 would be a good fit for a baseline version. Gruß Richard Am 14. September 2024 00:00:48 MESZ schrieb sebb : >On Fri, 13 Sept 2024 at 22:01, Gary Gregory wrote: >> >> The age does not really matter Elric, it's the percentage of people using a >> platform. See the links in my previous email. I think the highest we can go >> is 17, but that's just me. > >According to the 3rd link, Java version usage in 2024 is > >7 - 0.2% >8 - 28.8% >11 - 32.9% >17 - 35.4% >21 - 1.4% > >Here is the list showing the percentages that will no longer be >supported by choosing a particular version: > >7 - 0% >8 - 0.2% >11 - 29% >17 - 61.9% >21 - 97.3% > >Bigger is definitely not better here. > >> Gary >> >> On Fri, Sep 13, 2024, 4:11 PM Elric wrote: >> >> > On 12/09/2024 19:21, Gary D. Gregory wrote: >> > > Hi All, >> > > >> > > Any thoughts on the minimum Java platform requirement for 2.0? >> > > >> > > Options are (IMO): 8, 11, 17, or 21. >> > >> > I have no vote, but I would go for 21. This will likely be a decision >> > that will have an impact for a long time. 21 is 1 year old, 17 is 3 >> > years old, 11 is already already 6 years old, and 8 is over 10 years old. >> > >> > People can continue to use 1.x if they are stuck on ancient Java >> > versions, but there should be no need to for any major release of any >> > commons project to stick to older versions. >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > > >- >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org >
Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
good and should did it 5 years ago From: Niall Pemberton Sent: Saturday, September 14, 2024 1:46:32 PM To: Commons Developers List Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap On Thu, 12 Sep 2024 at 19:59, Gary D. Gregory wrote: > Hi All, > > For the upcoming 2.0.0-M1, I plan on replacing the custom WeakFastHashMap > with the stock ConcurrentHashMap. > > If you think this is a bad idea, please tell us why. It’s a good idea for the “fast” part, but the “weak” aspect also needs to be retained - so in principle yes, but the implementation detail matters. BeanUtils caused memory issues in multiple ClassLoader environments (e.g. WebApp containers) because of strong references to classes prevented them from being garbage collected if the app was reloaded/restarted. So this weak map was introduced to resolve that issue. Niall > > Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
I thought old d-lea bro have a concurrent weak hashmap implement somewhere...why not just ask him after all nobody here more expert than him in this area From: Niall Pemberton Sent: Saturday, September 14, 2024 1:46:32 PM To: Commons Developers List Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap On Thu, 12 Sep 2024 at 19:59, Gary D. Gregory wrote: > Hi All, > > For the upcoming 2.0.0-M1, I plan on replacing the custom WeakFastHashMap > with the stock ConcurrentHashMap. > > If you think this is a bad idea, please tell us why. It’s a good idea for the “fast” part, but the “weak” aspect also needs to be retained - so in principle yes, but the implementation detail matters. BeanUtils caused memory issues in multiple ClassLoader environments (e.g. WebApp containers) because of strong references to classes prevented them from being garbage collected if the app was reloaded/restarted. So this weak map was introduced to resolve that issue. Niall > > Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
I submitted this PR years ago using ConcurrentWeakKeyHashMap from Doug Lea and the Netty team but Gary had concerns from legal about being able to use it. PR is here: https://github.com/apache/commons-beanutils/pull/56 On Sat, Sep 14, 2024 at 7:22 AM Xeno Amess wrote: > I thought old d-lea bro have a concurrent weak hashmap implement > somewhere...why not just ask him > after all nobody here more expert than him in this area > > From: Niall Pemberton > Sent: Saturday, September 14, 2024 1:46:32 PM > To: Commons Developers List > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > On Thu, 12 Sep 2024 at 19:59, Gary D. Gregory wrote: > > > Hi All, > > > > For the upcoming 2.0.0-M1, I plan on replacing the custom WeakFastHashMap > > with the stock ConcurrentHashMap. > > > > If you think this is a bad idea, please tell us why. > > > It’s a good idea for the “fast” part, but the “weak” aspect also needs to > be retained - so in principle yes, but the implementation detail matters. > > BeanUtils caused memory issues in multiple ClassLoader environments (e.g. > WebApp containers) because of strong references to classes prevented them > from being garbage collected if the app was reloaded/restarted. So this > weak map was introduced to resolve that issue. > > Niall > > > > > > Gary > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
why not write an email to lea ..maybe he be so kind that would be glad to offer one mit-like license copy of that class From: Melloware Inc Sent: Saturday, September 14, 2024 8:32:38 PM To: Commons Developers List Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap I submitted this PR years ago using ConcurrentWeakKeyHashMap from Doug Lea and the Netty team but Gary had concerns from legal about being able to use it. PR is here: https://github.com/apache/commons-beanutils/pull/56 On Sat, Sep 14, 2024 at 7:22 AM Xeno Amess wrote: > I thought old d-lea bro have a concurrent weak hashmap implement > somewhere...why not just ask him > after all nobody here more expert than him in this area > > From: Niall Pemberton > Sent: Saturday, September 14, 2024 1:46:32 PM > To: Commons Developers List > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > On Thu, 12 Sep 2024 at 19:59, Gary D. Gregory wrote: > > > Hi All, > > > > For the upcoming 2.0.0-M1, I plan on replacing the custom WeakFastHashMap > > with the stock ConcurrentHashMap. > > > > If you think this is a bad idea, please tell us why. > > > It’s a good idea for the “fast” part, but the “weak” aspect also needs to > be retained - so in principle yes, but the implementation detail matters. > > BeanUtils caused memory issues in multiple ClassLoader environments (e.g. > WebApp containers) because of strong references to classes prevented them > from being garbage collected if the app was reloaded/restarted. So this > weak map was introduced to resolve that issue. > > Niall > > > > > > Gary > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
Well in my PR the license in the file says this. Written by Doug Lea with assistance from members of JCP JSR-166 Expert Group and released to the public domain, as explained at @see http://creativecommons.org/licenses/publicdomain";>Creative Commons it says its public domain. On Sat, Sep 14, 2024 at 9:01 AM Xeno Amess wrote: > why not write an email to lea ..maybe he be so kind that would be glad to > offer one mit-like license copy of that class > > From: Melloware Inc > Sent: Saturday, September 14, 2024 8:32:38 PM > To: Commons Developers List > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > I submitted this PR years ago using ConcurrentWeakKeyHashMap from Doug Lea > and the Netty team but Gary had concerns from legal about being able to use > it. > > PR is here: https://github.com/apache/commons-beanutils/pull/56 > > On Sat, Sep 14, 2024 at 7:22 AM Xeno Amess wrote: > > > I thought old d-lea bro have a concurrent weak hashmap implement > > somewhere...why not just ask him > > after all nobody here more expert than him in this area > > > > From: Niall Pemberton > > Sent: Saturday, September 14, 2024 1:46:32 PM > > To: Commons Developers List > > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > > > On Thu, 12 Sep 2024 at 19:59, Gary D. Gregory > wrote: > > > > > Hi All, > > > > > > For the upcoming 2.0.0-M1, I plan on replacing the custom > WeakFastHashMap > > > with the stock ConcurrentHashMap. > > > > > > If you think this is a bad idea, please tell us why. > > > > > > It’s a good idea for the “fast” part, but the “weak” aspect also needs to > > be retained - so in principle yes, but the implementation detail matters. > > > > BeanUtils caused memory issues in multiple ClassLoader environments (e.g. > > WebApp containers) because of strong references to classes prevented them > > from being garbage collected if the app was reloaded/restarted. So this > > weak map was introduced to resolve that issue. > > > > Niall > > > > > > > > > > Gary > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > -- > == > Melloware > melloware...@gmail.com > http://melloware.com > == > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
IMO I think it ok...so Gary which part do you feel unsafe in it ？I must admit I am not that familiar to lawyer things.. From: Melloware Inc Sent: Saturday, September 14, 2024 9:18:08 PM To: Commons Developers List Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap Well in my PR the license in the file says this. Written by Doug Lea with assistance from members of JCP JSR-166 Expert Group and released to the public domain, as explained at @see http://creativecommons.org/licenses/publicdomain";>Creative Commons it says its public domain. On Sat, Sep 14, 2024 at 9:01 AM Xeno Amess wrote: > why not write an email to lea ..maybe he be so kind that would be glad to > offer one mit-like license copy of that class > > From: Melloware Inc > Sent: Saturday, September 14, 2024 8:32:38 PM > To: Commons Developers List > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > I submitted this PR years ago using ConcurrentWeakKeyHashMap from Doug Lea > and the Netty team but Gary had concerns from legal about being able to use > it. > > PR is here: https://github.com/apache/commons-beanutils/pull/56 > > On Sat, Sep 14, 2024 at 7:22 AM Xeno Amess wrote: > > > I thought old d-lea bro have a concurrent weak hashmap implement > > somewhere...why not just ask him > > after all nobody here more expert than him in this area > > > > From: Niall Pemberton > > Sent: Saturday, September 14, 2024 1:46:32 PM > > To: Commons Developers List > > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > > > On Thu, 12 Sep 2024 at 19:59, Gary D. Gregory > wrote: > > > > > Hi All, > > > > > > For the upcoming 2.0.0-M1, I plan on replacing the custom > WeakFastHashMap > > > with the stock ConcurrentHashMap. > > > > > > If you think this is a bad idea, please tell us why. > > > > > > It’s a good idea for the “fast” part, but the “weak” aspect also needs to > > be retained - so in principle yes, but the implementation detail matters. > > > > BeanUtils caused memory issues in multiple ClassLoader environments (e.g. > > WebApp containers) because of strong references to classes prevented them > > from being garbage collected if the app was reloaded/restarted. So this > > weak map was introduced to resolve that issue. > > > > Niall > > > > > > > > > > Gary > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > -- > == > Melloware > melloware...@gmail.com > http://melloware.com > == > -- == Melloware melloware...@gmail.com http://melloware.com ==
[VOTE][LAZY] Release Apache Commons Parent 75 based on RC1
We have updated dependencies since Apache Commons Parent 74 was released, so I would like to release Apache Commons Parent 75. Apache Commons Parent 75 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/parent/75-RC1 (svn revision 71588) The Git tag commons-parent-75-RC1 commit for this RC is 7ad3fff5ea3017d2dabd593da9ff034d5465cadf which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=7ad3fff5ea3017d2dabd593da9ff034d5465cadf You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-75-RC1 commons-parent-75-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1778/org/apache/commons/commons-parent/75/ These are the artifacts and their hashes: #Release SHA-512s #Sat Sep 14 19:48:21 UTC 2024 commons-parent-75-bom.json=a249d7d8b3367fa935ed745fa626dafde4a039fe0149a1ed52b9c73a19c8b5fca65479ac1c0c54e7d68a08ef0d20c47ba18b30e1731047ae2d8090a3a7b7553b commons-parent-75-bom.xml=74c795cc6c8e0c943536c955aa965e7c87974edd2de9a5f268a0a3c0909a81d4c968094c5f613412c6a01a831f05c7b759c909688941d25a81024f288240cfe4 commons-parent-75-site.xml=5f045989b2c281c567467548678fe8685efabf5c13104299eea87b6ab6b6a75c9e98b590d7b288b8ec3a06934061709d0851a6dd9d9b45100ee2950908ec2d6c commons-parent-75-src.tar.gz=0213ccb19c08cd5f3ed9da65cd82674d157c6de428e7856586a3aa8b1c149849eab673c95085a69f4f686167ca87abf7faf56268681e04cfda5ad53e73a9 commons-parent-75-src.zip=f4859457aa1e158ab126f3eca720f5451074cab52b192d373fdbca1dd6d028ad6c0b7f2b6f120d7c6b319f45e85b20aa986da17a2b76f15ac5f1172ea09e59d0 org.apache.commons_commons-parent-75.spdx.json=a1bf8155efcae7c0061bf1d2533544095bbbfe8b369ca049e3e4a9ba03c1c4af0aa1b53ad80c6dd5c3fb40ed6a40eb4f72df02fd54eff8e88e5bcd84f65db75a I have tested this with 'mvn -e -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using: openjdk version "17.0.12" 2024-07-16 OpenJDK Runtime Environment Homebrew (build 17.0.12+0) OpenJDK 64-Bit Server VM Homebrew (build 17.0.12+0, mixed mode, sharing) Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937) Maven home: /usr/local/Cellar/maven/3.9.9/libexec Java version: 17.0.12, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@17/17.0.12/libexec/openjdk.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.6.1", arch: "x86_64", family: "mac" Darwin 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 PDT 2024; root:xnu-10063.141.2~1/RELEASE_X86_64 x86_64 Details of changes since 74 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/parent/75-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/parent/75-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/parent/75-RC1/site/index.html (note some *relative* links are broken and the 75 directories are not yet created - these will be OK once the site is deployed.) RAT Report: https://dist.apache.org/repos/dist/dev/commons/parent/75-RC1/site/rat-report.html KEYS: https://downloads.apache.org/commons/KEYS Please review the release candidate and vote. This vote will close no sooner than 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thank you, Gary Gregory, Release Manager (using key 86fdc7e2a11262cb) The following is intended as a helper and refresher for reviewers. Validating a release candidate == These guidelines are NOT complete. Requirements: Git, Java, Maven. You can validate a release from a release candidate (RC) tag as follows. 1a) Clone and checkout the RC tag git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-75-RC1 commons-parent-75-RC1 cd commons-parent-75-RC1 1b) Download and unpack the source archive from: https://dist.apache.org/repos/dist/dev/commons/parent/75-RC1/source 2) Check Apache licenses This step is not required if the site includes a RAT report page which you then must check. mvn apache-rat:check 3) Check binary compatibility Older components still use Apache Clirr: This step is not required if the site includes a Clirr report page which you then must check. mvn clirr:check Newer components use JApiCmp with the japicmp Maven Profile: This step is not required if the site includes a JApiCmp report page which you then must check. mvn install -DskipTests -P japicmp japicmp:cmp 4) Build the package mvn -V clean package You can record the Maven and Java version produced by -V in your VOTE reply. To gather OS information from a command line: Windows: ver Linux: uname -a 5) Build the site for a single module project Note: Some plugins require the components to be installed instead of packaged. mvn site Check the site reports in: - Windo
