Re: [CLI] [Discuss[ "Since" attribute
I am. Should i create a ticket first? On Mon 22 Jul 2024, 15:22 Gary Gregory, wrote: > That sounds reasonable. Are you planning to create PR? > > Gary > > On Mon, Jul 22, 2024 at 3:12 AM Claude Warren wrote: > > > > Greetings, > > > > We recently introduced the "deprecation" processing where in we track the > > version when the option was deprecated in the DeprecationAttribute > property > > "since". > > > > I think it makes sense to add a since property to the Option class as > > well. This would list the version at which the option became available. > > > > By default it would not be displayed. However options would be added to > > the helpFormatter tool to display since as a column in the help page. > > > > Is there any disagreement on this or other points at which the value > should > > be displayed? > > > > -- > > LinkedIn: http://www.linkedin.com/in/claudewarren > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [CLI] [Discuss[ "Since" attribute
It's not strictly required IMO. Some people like to see a ticket open for discussion instead of the PR but since we also have this mailing list, I'll leave it up to you. Gary On Tue, Jul 23, 2024, 5:30 AM Claude Warren wrote: > I am. Should i create a ticket first? > > On Mon 22 Jul 2024, 15:22 Gary Gregory, wrote: > > > That sounds reasonable. Are you planning to create PR? > > > > Gary > > > > On Mon, Jul 22, 2024 at 3:12 AM Claude Warren wrote: > > > > > > Greetings, > > > > > > We recently introduced the "deprecation" processing where in we track > the > > > version when the option was deprecated in the DeprecationAttribute > > property > > > "since". > > > > > > I think it makes sense to add a since property to the Option class as > > > well. This would list the version at which the option became > available. > > > > > > By default it would not be displayed. However options would be added > to > > > the helpFormatter tool to display since as a column in the help page. > > > > > > Is there any disagreement on this or other points at which the value > > should > > > be displayed? > > > > > > -- > > > LinkedIn: http://www.linkedin.com/in/claudewarren > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: JDK 23 RDP2 | Removal of the legacy COMPAT locale provider and more heads-up!
David, I've added the 23-ea and 24-ea versions to most of the Apache Commons builds on GitHub CI. This has revealed that some third-party tooling does not support those versions yet. We do have some old issues with conversions of date/times but I'm not sure if this makes it worse or better yet. Gary On Mon, Jul 22, 2024 at 1:29 AM David Delabassee wrote: > > Welcome to the OpenJDK Quality Outreach summer update. > > JDK 23 is now in Rampdown Phase Two [1], its overall feature has been frozen > a few weeks ago. Per the JDK Release Process, we have now turned our focus to > P1 and P2 bugs, which can be fixed with approval [2]. Late enhancements are > still possible, with approval, but the bar is now extraordinarily high. That > also means that the JDK 23 Initial Release Candidates are fast approaching, > i.e., August 8th [3]! So, and in addition to testing your projects with the > latest JDK 23 early-access builds, it is now a good time to start testing > with the JDK 24 early-access builds. > > Make sure to also check the heads-up below as some are related to JDK 23 and > might have some impact, i.e., the first one being related to the eventual > removal of the Security Manager and the second one discusses the removal of > the legacy COMPAT locale provider. > > [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-July/009252.html > [2] https://openjdk.org/jeps/3#rdp-2 > [3] https://openjdk.org/projects/jdk/23/ > > > ## Heads-up - JDK 23: Subject.getSubject API Requires Allowing the Security > Manager > > In JDK 17 and as announced in JEP 411 [4], the Security Manager was > deprecated for removal. As part of that change, several Security Manager > APIs, such as `AccessControlContext`, were deprecated for removal. The > `Subject::doAs` and `Subject::getSubject` APIs depend on Security Manager > related APIs even though they do not require Security Manager to be installed > to use them. > > As of JDK 23 [5], to help applications prepare for the eventual removal of > the Security Manager, subject authorization and the Subject APIs' behavior > depend on allowing the Security Manager: > - If the system property `java.security.manager` is set on the command line > to the empty string, a class name, or the value `allow` then there is no > behavior change compared to previous releases. > - If the system property `java.security.manager` is not set on the command > line or has been set on the command line to the value `disallow`, invoking > the `Subject.getSubject` method will throw `UnsupportedOperationException`. > > Yet, running an application with `-Djava.security.manager=allow` is a > temporary workaround to keep older code working. Maintainers of code using > `Subject.doAs` and `Subject.getSubject` are strongly encouraged to migrate it > with utmost priority to the replacement APIs, `Subject.callAs` and > `Subject.current`. Make sure to check [5] and [6] for additional details. > > The jdeprscan tool [7] scans a JAR file for usage of deprecated API elements > and is helpful to find code using these methods. Additionally, consider > migrating as soon as possible code that stores a `Subject` in an > `AccessControlContext` and invokes `AccessController.doPrivileged` with that > context. Such code will stop working when the Security Manager is removed. > > [4] https://openjdk.org/jeps/411 > [5] https://jdk.java.net/23/release-notes#b15 > [6] https://inside.java/2024/07/08/quality-heads-up/ > [7] https://dev.java/learn/jvm/tools/core/jdeprscan/ > > > ## Heads-up - JDK 23: Unicode / Removal of COMPAT Locale Provider > > ### A Quick History of Locale Data in the JDK > > Before the Unicode Consortium created the Common Locale Data Repository > (CLDR) in 2003 to manage locale data, the JDK had to provide its own > collection. It did so successfully and in JDK 8 supported about 160 locales. > To reduce maintenance effort, allow better interoperability between > platforms, and improve locale data quality, the JDK started to move towards > CLDR in 2014: > - JDK 8 comes with two locale data providers, which can be selected with the > system property java.locale.providers: >. JRE/COMPAT for the JDK’s legacy data collection (default) >. CLDR for the CLDR data >. a custom locale provider can be implemented > - JDK 9 picks CLDR by default > - JDK 21 issues a warning on JRE/COMPAT > > There are plenty of minor and a few notable differences between the legacy > data and CLDR - the recently rewritten JEP 252 [8] lists a few of them. > > ### Locale Data in JDK 23 > > JDK 23 [9] removes legacy locale data. As a consequence, setting > java.locale.providers to JRE or COMPAT has no effect. > > Projects that are still using legacy locale data are highly encouraged to > switch to CLDR as soon as possible. Where that is infeasible, two > alternatives remain: > - Create custom formatters with patterns that mimic the legacy behavior and > use them everywhere where locale-sensitive data
Re: [VOTE] Release Apache Commons BCEL 6.10.0 based on RC1
[+1] Builds and tests ok, site looks good, reports show no issues (nit: code coverage need some love, JIRA report too). Built with: mvn -P jacoco -P japicmp clean install site -s ~/.m2/commons-settings.xml Using: mvn -version Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home: /Users/hbiestro/Java/apache-maven-3.8.6 Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.5", arch: "aarch64", family: "Mac" Cheers Henrib - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[CRYPTO] GH builds on macos-latest cannot find aes.h
It looks like macos-latest does not include the openssl header files (or at least they are not in the expected place). Hope to find time later to fix this, but if anyone knows the solution, please pipe up! Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[RESULT][VOTE] Release Apache Commons BCEL 6.10.0 based on RC1
This vote passes with the following binding +1 votes: - Gary Gregory (ggregory) - Rob Tompkins (chtompki) - Henri Biestro (henrib) Gary On Tue, Jul 23, 2024 at 9:25 AM Henri Biestro wrote: > > [+1] > > Builds and tests ok, site looks good, reports show no issues (nit: code > coverage need some love, JIRA report too). > > Built with: mvn -P jacoco -P japicmp clean install site -s > ~/.m2/commons-settings.xml > Using: mvn -version > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) > Maven home: /Users/hbiestro/Java/apache-maven-3.8.6 > Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: > /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.5", arch: "aarch64", family: "Mac" > > Cheers > Henrib > > - > 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: [CRYPTO] GH builds on macos-latest cannot find aes.h
On Tue, 23 Jul 2024 at 15:16, sebb wrote: > > It looks like macos-latest does not include the openssl header files > (or at least they are not in the expected place). Eventually found them under /opt/homebrew/include Although the GH macos-13 and macos-14 hosts have the same version of openssl installed, the headers are not in the same place. > Hope to find time later to fix this, but if anyone knows the solution, > please pipe up! > > Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
