Re: [text] Performance regression in StringMatcher (used by StringSubstitutor) v1.9+
Hi David, however there’s no public signup for the ASF Jira anymore. I’m hoping my > report here will suffice. If not, please create an account for me and I’ll > file a proper ticket for it. > If you provide this information we can set up an account for you (sorry about this two-step process; our JIRA has been under constant spam lately): - Name - Email - Preferred user name: Hopefully, I’ve explained it clearly enough. Please reach out with any > further questions. > I think you explained really well. If you could copy/paste it into a JIRA that would be great, as you would also get notifications for updates from JIRA/Git/etc there, or in this email thread. It would be great too if you were able to provide a use case and/or unit test. While working on the fix, we can also check if it'd possible to include a benchmark test case with JMH to prevent future regressions. Cheers -Bruno On Wed, 8 Feb 2023 at 23:41, David Becker wrote: > I would like to report a performance regression when using > StringSubstitutor with large strings that our application experienced after > upgrading to v1.9+, however there’s no public signup for the ASF Jira > anymore. I’m hoping my report here will suffice. If not, please create an > account for me and I’ll file a proper ticket for it. > > As of v1.9, StringSubstitutor no longer pre-converts the TextStringBuilder > to a char[], see this ( > https://github.com/apache/commons-text/commit/248af06171e14648e00ce0873c5f95e03041a6c7 > ) commit, and opts to reuse the TextStringBuilder API instead. A new > default method ( > https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/matcher/StringMatcher.java#L146 > ) was added to StringMatcher that takes CharSequence (which > TextStringBuilder implements) to handle the conversion. However, it calls > CharSequenceUtils.toCharArray(buffer), which is not aware of > TextStringBuilder and cannot optimize the conversion to char[] since > CharSequence has no way to do so, and it’s not a String (which does). When > using a custom StringMatcher implementation that does not override this > default method (as the stock matchers do), it results in a full copy of the > CharSequence being made, which adds up very quickly when the text is large > and lots of replacements are being made. > > Methods of ours which used to take 3 seconds, now take upwards of a > minute. Fortunately, our custom matcher is a simple OrStringMatcher (not > provided out-of-the-box) which delegates to stock StringMatchers created by > StringMatcherFactory.stringMatcher(…) which have their own optimized > implementation of the method, so we were able to resolve this ourselves by > overriding the method and delegating it directly to the optimized > implementation of the stock matchers – thus bypassing the > CharSequenceUtils.toCharArray(buffer) penalty completely. > > But others may not be as fortunate. Perhaps the default method could be > made aware of TextStringBuilder and use its package protected getBuffer() > method instead? Or maybe there’s a better way to solve it. > > Hopefully, I’ve explained it clearly enough. Please reach out with any > further questions. > > -- > David Becker > Senior IT Engineer > > > *** > Notice: This e-mail, including any attachment(s) and link(s), is > confidential, proprietary and intended solely for the above-named > individual(s). It may constitute non-public information and may contain > information subject to certain legal privileges. If you are the intended > recipient, your use of any confidential, proprietary or personal > information may be restricted by federal and state privacy or other laws. > Any unauthorized use of this communication by others is strictly prohibited > and may be unlawful. If you have received this e-mail in error, do not open > any attachment(s) or link(s). Please notify the sender immediately by > replying to sender and then delete both this e-mail and any attachment(s). > Thank you. > > EMPLOYERS® provides workers compensation insurance through Employers > Preferred Insurance Company, Employers Assurance Company, Employers > Compensation Insurance Company and Employers Insurance Company of Nevada. > EIG Services, Inc. (in California, dba EIG Insurance Services) is an > affiliated agency and adjuster. > > *** >
Re: [Beanutils] BeanUtilsBean2
+1 BeanUtilsBean2 extends BeanUtilsBean. Merging the two into a single class sounds OK for a major release and a good simplification. -Bruno On Thu, 9 Feb 2023 at 13:47, Gary Gregory wrote: > For 2.0, I think we should make the BeanUtilsBean2 class introduced in > 1.8.0 the only behavior, removing the need for the class. > > WDYT? > > Gary >
Re: [VOTE] Release Apache Commons FileUpload 1.5 based on RC1
Will try to get to today. -Rob > On Feb 9, 2023, at 8:39 AM, Mark Thomas wrote: > > Ping. One more PMC member vote required. > > Mark > > On 01/02/2023 12:57, Mark Thomas wrote: >> We have fixed a few bugs and added some small enhancements since FileUpload >> 1.4 was released, so I would like to release FileUpload 1.5. >> FileUpload 1.5 RC1 is available for review here: >> https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1 >> (svn revision 59794) >> The tag is here: >> https://gitbox.apache.org/repos/asf?p=commons-fileupload.git;a=tag;h=7a932af807778ffd11ed5e86cc69b405855c11fb >> Maven artifacts are here: >> https://repository.apache.org/content/repositories/orgapachecommons-1618/ >> These are the artifacts and their hashes: >> #Release SHA-512s >> commons-fileupload-1.5-bin.tar.gz=185699b43afcf1494378ed7efae25fb3630346323c6abadaef2dfce3a01c533341a51e2c14f081f4b90d02dd9364c4a565966bf4358e9a11b71aa3a19adb3097 >> commons-fileupload-1.5-bin.zip=4e99e8ee135d0f331a0f5ffeb3a15d94f31469c57c9ca79a65608665165604be7e20d4571571fdfaf37938db90744dc318ed634c19dd6f31c7d4815b0084c9b1 >> commons-fileupload-1.5-bom.json=864690cd2f9e962dab4a58661a356acc29aebe5958dea1c2161541160d36b3a86f582b8fd9be6502465e7d68480aad9c1777e0b1646ef9ad8c02aa541f78f964 >> commons-fileupload-1.5-bom.xml=ab82f4581eb9056dd2c28ea8656016d02729c3648f140d5b270b470e91df2baa3b0e1d2111b445093fc826834d86a2525d7421dc47ffd4afab8690ce5e865512 >> commons-fileupload-1.5-javadoc.jar=f1c1dbb054e4b1a4ed1616c78b3e00b97b4eb8b05b89971ec87d80a09aef680451d98762fd490b7618b00fe2c33e1e50e153676bb92a3941fb82c21cf5c7ec0a >> commons-fileupload-1.5-sources.jar=4a62eae065a0f7063c7377e06e499582acfcb2cd3f0a35e2b6893d7bc04406da49b9e60e1b1ec7fb53b9fcfc028e335c4ce812a3085302853a62584e663c0f2c >> commons-fileupload-1.5-src.tar.gz=6cf4a1deeb8511d29e1543af4b6d3d984f0f2991e6f4550d84e7fb5d1a6df6df71c1fad6d2607d4b5d062c8fff498d30da7bd1a5bfc09f9cabdb0a57dc5c1a16 >> commons-fileupload-1.5-src.zip=b0b6f54e6de2d472033f1bca70b587c99f1b8d649147469e4f315848ed284a9db6b4f200046cb36e99613a4029b5f5b86316bbe26494ce34ca36a670e69492e5 >> commons-fileupload-1.5-test-sources.jar=428d35784b99543d304fc44eb26da9fb76bd5844843bf7f0b027cc511a56a08ea5891c8aacc14099bf2fce0ef9cc90cc3bca01255bdf57d6015b232ecefa7f4c >> commons-fileupload-1.5-tests.jar=b3b06fe319cbc4b679b8a0ada40772bb943151bc26828c6c4d98a102c5aafab94dcffa6f61570830339d7b0f86c834413660240c6692811d22e1cfc0e051d330 >> commons-fileupload_commons-fileupload-1.5.spdx.json=add8592cb24014c3e732b1eb13f9780904ef28a4439091431b1070a735993ff83c3fdaae60de2be146b4f816c9dee123ff06515cbbd8127d99d13c93d03220fc >> commons-xyz-1.2-test-sources.jar >> Details of changes since 1.4 are in the release notes: >> https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1/RELEASE-NOTES.txt >> https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1/site/changes-report.html >> Site: >> https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1/site/index.html >> KEYS: >> https://www.apache.org/dist/commons/KEYS >> Please review the release candidate and vote. >> This vote will close no sooner that 72 hours from now, >> i.e. sometime after 13:00 UTC 4 Feb 2023 >> [ ] +1 Release these artifacts >> [ ] +0 OK, but... >> [ ] -0 OK, but really should fix... >> [ ] -1 I oppose this release because... >> Thanks! >> Mark >> - >> 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 > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons FileUpload 1.5 based on RC1
Ping. One more PMC member vote required. Mark On 01/02/2023 12:57, Mark Thomas wrote: We have fixed a few bugs and added some small enhancements since FileUpload 1.4 was released, so I would like to release FileUpload 1.5. FileUpload 1.5 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1 (svn revision 59794) The tag is here: https://gitbox.apache.org/repos/asf?p=commons-fileupload.git;a=tag;h=7a932af807778ffd11ed5e86cc69b405855c11fb Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1618/ These are the artifacts and their hashes: #Release SHA-512s commons-fileupload-1.5-bin.tar.gz=185699b43afcf1494378ed7efae25fb3630346323c6abadaef2dfce3a01c533341a51e2c14f081f4b90d02dd9364c4a565966bf4358e9a11b71aa3a19adb3097 commons-fileupload-1.5-bin.zip=4e99e8ee135d0f331a0f5ffeb3a15d94f31469c57c9ca79a65608665165604be7e20d4571571fdfaf37938db90744dc318ed634c19dd6f31c7d4815b0084c9b1 commons-fileupload-1.5-bom.json=864690cd2f9e962dab4a58661a356acc29aebe5958dea1c2161541160d36b3a86f582b8fd9be6502465e7d68480aad9c1777e0b1646ef9ad8c02aa541f78f964 commons-fileupload-1.5-bom.xml=ab82f4581eb9056dd2c28ea8656016d02729c3648f140d5b270b470e91df2baa3b0e1d2111b445093fc826834d86a2525d7421dc47ffd4afab8690ce5e865512 commons-fileupload-1.5-javadoc.jar=f1c1dbb054e4b1a4ed1616c78b3e00b97b4eb8b05b89971ec87d80a09aef680451d98762fd490b7618b00fe2c33e1e50e153676bb92a3941fb82c21cf5c7ec0a commons-fileupload-1.5-sources.jar=4a62eae065a0f7063c7377e06e499582acfcb2cd3f0a35e2b6893d7bc04406da49b9e60e1b1ec7fb53b9fcfc028e335c4ce812a3085302853a62584e663c0f2c commons-fileupload-1.5-src.tar.gz=6cf4a1deeb8511d29e1543af4b6d3d984f0f2991e6f4550d84e7fb5d1a6df6df71c1fad6d2607d4b5d062c8fff498d30da7bd1a5bfc09f9cabdb0a57dc5c1a16 commons-fileupload-1.5-src.zip=b0b6f54e6de2d472033f1bca70b587c99f1b8d649147469e4f315848ed284a9db6b4f200046cb36e99613a4029b5f5b86316bbe26494ce34ca36a670e69492e5 commons-fileupload-1.5-test-sources.jar=428d35784b99543d304fc44eb26da9fb76bd5844843bf7f0b027cc511a56a08ea5891c8aacc14099bf2fce0ef9cc90cc3bca01255bdf57d6015b232ecefa7f4c commons-fileupload-1.5-tests.jar=b3b06fe319cbc4b679b8a0ada40772bb943151bc26828c6c4d98a102c5aafab94dcffa6f61570830339d7b0f86c834413660240c6692811d22e1cfc0e051d330 commons-fileupload_commons-fileupload-1.5.spdx.json=add8592cb24014c3e732b1eb13f9780904ef28a4439091431b1070a735993ff83c3fdaae60de2be146b4f816c9dee123ff06515cbbd8127d99d13c93d03220fc commons-xyz-1.2-test-sources.jar Details of changes since 1.4 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/fileupload/1.5-RC1/site/index.html KEYS: https://www.apache.org/dist/commons/KEYS Please review the release candidate and vote. This vote will close no sooner that 72 hours from now, i.e. sometime after 13:00 UTC 4 Feb 2023 [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Mark - 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: [bcel] Invalid Method Signature when parentheses are in method name
Thanks Jason!
Gary
On Wed, Feb 8, 2023, 19:31 Jason Copenhaver
wrote:
> I've created a PR that repros at
> https://github.com/apache/commons-bcel/pull/205
>
> Jason C
>
> On Wed, Feb 8, 2023 at 3:33 PM Gary Gregory
> wrote:
>
> > Hi Jason,
> >
> > The best path forward would be for you to create a PR on GitHub with a
> > failing unit test. That will let us reproduce your issue in the simplest
> > fashion. Also make sure you are using the last version, 6.7.0.
> >
> > Thank you,
> > Gary
> >
> > On Wed, Feb 8, 2023, 11:14 Jason Copenhaver
> > wrote:
> >
> > > I've run into an issue when using BCEL on the results of the below
> Kotlin
> > > code.
> > >
> > > class test {
> > > fun takeABlock(a: () -> Unit) {
> > > a()
> > > }
> > >
> > > fun `method name with () in it`() {
> > > takeABlock { println("other test") }
> > > }
> > >
> > > fun `method name without parens`() {
> > > takeABlock { println("other test") }
> > > }
> > > }
> > >
> > > Three class files are produced.
> > >
> > > test$method name with () in it$1.class
> > > test$method name without parens$1.class
> > > test.class
> > >
> > > When i use the examples/JasminVisitor.java against `test$method name
> with
> > > () in it$1.class` with a small patch to add a `field.getType()` call to
> > the
> > > `visitField` method I get the below stack trace.
> > >
> > > Exception in thread "main"
> > org.apache.bcel.classfile.ClassFormatException:
> > > Invalid method signature: in it$1;
> > > at org.apache.bcel.classfile.Utility.typeOfSignature(Utility.java:1284)
> > > at org.apache.bcel.generic.Type.getType(Type.java:227)
> > > at org.apache.bcel.generic.Type.getReturnType(Type.java:151)
> > > at org.apache.bcel.classfile.Field.getType(Field.java:150)
> > > at JasminVisitor.visitField(JasminVisitor.java:287)
> > > at org.apache.bcel.classfile.Field.accept(Field.java:113)
> > > at
> > >
> > >
> >
> org.apache.bcel.classfile.DescendingVisitor.visitField(DescendingVisitor.java:311)
> > > at org.apache.bcel.classfile.Field.accept(Field.java:113)
> > > at
> > >
> > >
> >
> org.apache.bcel.classfile.DescendingVisitor.lambda$accept$0(DescendingVisitor.java:44)
> > > at
> > >
> > >
> >
> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> > > at
> > >
> > >
> >
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> > > at
> > >
> > >
> >
> org.apache.bcel.classfile.DescendingVisitor.accept(DescendingVisitor.java:44)
> > > at
> > >
> > >
> >
> org.apache.bcel.classfile.DescendingVisitor.visitJavaClass(DescendingVisitor.java:335)
> > > at org.apache.bcel.classfile.JavaClass.accept(JavaClass.java:251)
> > > at
> > >
> > >
> >
> org.apache.bcel.classfile.DescendingVisitor.visit(DescendingVisitor.java:77)
> > > at JasminVisitor.disassemble(JasminVisitor.java:109)
> > > at JasminVisitor.main(JasminVisitor.java:82)
> > >
> > > Thanks,
> > > Jason C
> > >
> >
>
[Beanutils] BeanUtilsBean2
For 2.0, I think we should make the BeanUtilsBean2 class introduced in 1.8.0 the only behavior, removing the need for the class. WDYT? Gary
