[jira] [Updated] (FILEUPLOAD-356) Link to "changes report" for commons-fileupload is wrong
[ https://issues.apache.org/jira/browse/FILEUPLOAD-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated FILEUPLOAD-356: --- Affects Version/s: 2.0.0-M2 > Link to "changes report" for commons-fileupload is wrong > > > Key: FILEUPLOAD-356 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-356 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 2.0.0-M2 >Reporter: Mattias Reichel >Assignee: Gary D. Gregory >Priority: Trivial > Fix For: 2.0.0 > > > On [https://commons.apache.org/proper/commons-fileupload/] under the > "Releases" heading there is a link "changes report" that is incorrect. > It currently links to > [https://commons.apache.org/proper/commons-fileupload/.changes-report.html] . > The correct link is > [https://commons.apache.org/proper/commons-fileupload/changes-report.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FILEUPLOAD-356) Link to "changes report" for commons-fileupload is wrong
[ https://issues.apache.org/jira/browse/FILEUPLOAD-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved FILEUPLOAD-356. Fix Version/s: 2.0.0 Assignee: Gary D. Gregory Resolution: Fixed > Link to "changes report" for commons-fileupload is wrong > > > Key: FILEUPLOAD-356 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-356 > Project: Commons FileUpload > Issue Type: Bug >Reporter: Mattias Reichel >Assignee: Gary D. Gregory >Priority: Trivial > Fix For: 2.0.0 > > > On [https://commons.apache.org/proper/commons-fileupload/] under the > "Releases" heading there is a link "changes report" that is incorrect. > It currently links to > [https://commons.apache.org/proper/commons-fileupload/.changes-report.html] . > The correct link is > [https://commons.apache.org/proper/commons-fileupload/changes-report.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Moved] (FILEUPLOAD-356) Link to "changes report" for commons-fileupload is wrong
[ https://issues.apache.org/jira/browse/FILEUPLOAD-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory moved COMMONSSITE-172 to FILEUPLOAD-356: Key: FILEUPLOAD-356 (was: COMMONSSITE-172) Project: Commons FileUpload (was: Apache Commons All) > Link to "changes report" for commons-fileupload is wrong > > > Key: FILEUPLOAD-356 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-356 > Project: Commons FileUpload > Issue Type: Bug >Reporter: Mattias Reichel >Priority: Trivial > > On [https://commons.apache.org/proper/commons-fileupload/] under the > "Releases" heading there is a link "changes report" that is incorrect. > It currently links to > [https://commons.apache.org/proper/commons-fileupload/.changes-report.html] . > The correct link is > [https://commons.apache.org/proper/commons-fileupload/changes-report.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COMMONSSITE-172) Link to "changes report" for commons-fileupload is wrong
Mattias Reichel created COMMONSSITE-172: --- Summary: Link to "changes report" for commons-fileupload is wrong Key: COMMONSSITE-172 URL: https://issues.apache.org/jira/browse/COMMONSSITE-172 Project: Apache Commons All Issue Type: Bug Reporter: Mattias Reichel On [https://commons.apache.org/proper/commons-fileupload/] under the "Releases" heading there is a link "changes report" that is incorrect. It currently links to [https://commons.apache.org/proper/commons-fileupload/.changes-report.html] . The correct link is [https://commons.apache.org/proper/commons-fileupload/changes-report.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (BCEL-374) FIx tests on Java 23
[
https://issues.apache.org/jira/browse/BCEL-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886467#comment-17886467
]
Samael Bate commented on BCEL-374:
--
example from failed build output
[https://github.com/apache/commons-bcel/actions/runs/11125138597/job/30912192306]
{noformat}
Error: Failures:
1469Error:ConstantPoolModuleAccessTestCase.testJREModules:361 expected:
<[java.lang.System$LoggerFinder, java.net.ContentHandlerFactory,
java.net.spi.InetAddressResolverProvider,
java.net.spi.URLStreamHandlerProvider,
java.nio.channels.spi.AsynchronousChannelProvider,
java.nio.channels.spi.SelectorProvider, java.nio.charset.spi.CharsetProvider,
java.nio.file.spi.FileSystemProvider, java.nio.file.spi.FileTypeDetector,
java.security.Provider, java.text.spi.BreakIteratorProvider,
java.text.spi.CollatorProvider, java.text.spi.DateFormatProvider,
java.text.spi.DateFormatSymbolsProvider,
java.text.spi.DecimalFormatSymbolsProvider, java.text.spi.NumberFormatProvider,
java.time.chrono.AbstractChronology, java.time.chrono.Chronology,
java.time.zone.ZoneRulesProvider, java.util.random.RandomGenerator,
java.util.spi.CalendarDataProvider, java.util.spi.CalendarNameProvider,
java.util.spi.CurrencyNameProvider, java.util.spi.LocaleNameProvider,
java.util.spi.ResourceBundleControlProvider,
java.util.spi.ResourceBundleProvider, java.util.spi.TimeZoneNameProvider,
java.util.spi.ToolProvider, javax.security.auth.spi.LoginModule,
jdk.internal.io.JdkConsoleProvider, jdk.internal.logger.DefaultLoggerFinder,
sun.text.spi.JavaTimeDateTimePatternProvider,
sun.util.locale.provider.LocaleDataMetaInfo,
sun.util.resources.LocaleData$CommonResourceBundleProvider,
sun.util.resources.LocaleData$SupplementaryResourceBundleProvider,
sun.util.spi.CalendarProvider]> but was: <[java.lang.System$LoggerFinder,
java.net.ContentHandlerFactory, java.net.spi.InetAddressResolverProvider,
java.net.spi.URLStreamHandlerProvider,
java.nio.channels.spi.AsynchronousChannelProvider,
java.nio.channels.spi.SelectorProvider, java.nio.charset.spi.CharsetProvider,
java.nio.file.spi.FileSystemProvider, java.nio.file.spi.FileTypeDetector,
java.security.Provider, java.text.spi.BreakIteratorProvider,
java.text.spi.CollatorProvider, java.text.spi.DateFormatProvider,
java.text.spi.DateFormatSymbolsProvider,
java.text.spi.DecimalFormatSymbolsProvider, java.text.spi.NumberFormatProvider,
java.time.chrono.AbstractChronology, java.time.chrono.Chronology,
java.time.zone.ZoneRulesProvider, java.util.spi.CalendarDataProvider,
java.util.spi.CalendarNameProvider, java.util.spi.CurrencyNameProvider,
java.util.spi.LocaleNameProvider, java.util.spi.ResourceBundleControlProvider,
java.util.spi.ResourceBundleProvider, java.util.spi.TimeZoneNameProvider,
java.util.spi.ToolProvider, javax.security.auth.spi.LoginModule,
jdk.internal.io.JdkConsoleProvider, jdk.internal.logger.DefaultLoggerFinder,
sun.text.spi.JavaTimeDateTimePatternProvider,
sun.util.locale.provider.LocaleDataMetaInfo,
sun.util.resources.LocaleData$CommonResourceBundleProvider,
sun.util.resources.LocaleData$SupplementaryResourceBundleProvider,
sun.util.spi.CalendarProvider]>
1470Error:ConstantPoolModuleAccessTestCase.testJREModules:361 expected:
<[javax.annotation.processing.Processor, com.sun.source.util.Plugin,
com.sun.tools.doclint.DocLint, com.sun.tools.javac.platform.PlatformProvider]>
but was: <[javax.annotation.processing.Processor, com.sun.source.util.Plugin,
com.sun.tools.doclint.DocLint, com.sun.tools.javac.platform.PlatformProvider,
com.sun.tools.javac.api.JavacTrees$DocCommentTreeTransformer]>{noformat}
> FIx tests on Java 23
>
>
> Key: BCEL-374
> URL: https://issues.apache.org/jira/browse/BCEL-374
> Project: Commons BCEL
> Issue Type: Bug
> Environment: Java 23
>Reporter: Gary D. Gregory
>Priority: Major
>
> Two tests fail on Java 23. Looking for a volunteer to look into this ;-)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (BCEL-332) Separate the "ElementValuePairs" in "toString" method in "org.apache.bcel.classfile.AnnotationEntry"
[
https://issues.apache.org/jira/browse/BCEL-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886462#comment-17886462
]
Samael Bate commented on BCEL-332:
--
Seems this was done in commit:
[https://github.com/apache/commons-bcel/commit/3f281e465b404f0a5dd81cc887b2251c82b8ab38]
Can this issue be closed as resolved
> Separate the "ElementValuePairs" in "toString" method in
> "org.apache.bcel.classfile.AnnotationEntry"
>
>
> Key: BCEL-332
> URL: https://issues.apache.org/jira/browse/BCEL-332
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Lau Ka Ho
>Priority: Minor
>
> [https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/AnnotationEntry.java#L136]
>
> There are no *separator* in the list of elementValuePair(s).
> It could be better to separate them by a separator (i.e. comma)
> {code}public String toShortString() {
> final StringBuilder result = new StringBuilder();
> result.append("@");
> result.append(getAnnotationType());
> final ElementValuePair[] evPairs = getElementValuePairs();
> if (evPairs.length > 0) {
> result.append("(");
> for (final ElementValuePair element : evPairs) {
> result.append(element.toShortString());
> }
> result.append(")");
> }
> return result.toString();
> }{code}
> ||Before||Suggest|
> |{code}La/b/c//annotation/;(k1=v1k2=v2){code}|{code}@La/b/c//annotation/;(k1=v1,k2=v2){code}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1650) Add clamped spline interpolation
[
https://issues.apache.org/jira/browse/MATH-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886375#comment-17886375
]
Gilles Sadowski commented on MATH-1650:
---
Pasting below a comment posted last week on GitHub.
{quote}
- Unclarity about if extending `SplineInterpolator` by simply overloading
`interpolate()` function is the correct design approach here, or, if it should
be realised differently. I was expecting a clearer feedback from the
maintainers.
- Tests are missing.
{quote}
I don't recall the details (from almost two years ago) but, rereading my [last
comment|https://issues.apache.org/jira/browse/MATH-1650?focusedCommentId=17628356&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17628356],
it seemed that "no tests" were a "no-go" because the API blew up on the first
try, also implying that _overloading_ {{interpolate}} was leading to an
inconsistent API.
Reminder: current version (4.0) is "beta", and any functionality of the
codebase (such as the
[interpolation|https://commons.apache.org/proper/commons-math/commons-math4-legacy/apidocs/org/apache/commons/math4/legacy/analysis/interpolation/package-summary.html]
"legacy" package) is a candidate for re-implementation as a standalone
"module" (cf. other such
[modules|https://commons.apache.org/proper/commons-math/modules.html]).
It's an opportunity for algorithms' varying requirements to be satisfied in a
consistent and safe way.
Regarding the other comment on GH:
bq. The class already present in the javadoc for 4.0-beta1, but actually it's
still it's not in the codebase.
It was indeed a mistake, either in the generation of the web site, or perhaps
even in the source release (?). Sorry about that.
> Add clamped spline interpolation
>
>
> Key: MATH-1650
> URL: https://issues.apache.org/jira/browse/MATH-1650
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 4.X
>Reporter: Michael Scholz
>Priority: Minor
> Labels: Polynomials, interpolation, spline
> Attachments: 2022-10-05_ClampedSplineInterpolator.patch
>
>
> We would like to contribute a new _clamped_ spline interpolation function in
> addition to the already available unclamped spline function. Our new
> {{ClampedSplineInterpolator}} is based on the same textbook as the original
> {{{}SplineInterpolator{}}}. The clamped spline offers additional
> parameterisation of starting and ending slopes (1st derivatives) as boundary
> conditions in order to provide more flexibility in spline creation.
> In this patch we follow the approach of subclassing the original
> {{SplineInterpolator}} and simply overloading it's {{interpolate()}} function
> by these two additional parameters. Is this an acceptable way or does the
> community recommend a different design approach?
> After clarifying the basic implementation approach we could also supply
> necessary tests etc. and finally contribute everything via ordinary GitHub
> pull request.
> Refer to our post on the dev mailing list:
> https://lists.apache.org/thread/34qnx4tgjbyv345lgmd57g0bnlnwdzc8
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IMAGING-319) updateExifMetadataLossless lost the first character of a String
[
https://issues.apache.org/jira/browse/IMAGING-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886279#comment-17886279
]
Sicheng Yang edited comment on IMAGING-319 at 10/1/24 9:34 PM:
---
[~stefanoltmann] [~kinow] Hi! Sorry I was really busy these days. I own all
the materials, including code and images, feel free to share to anyone if it
can helps you all to fix the code. In the end, I really appreciate your all's
library. It helps me a lot 4 years ago! I am glad that I can make minor
contribution to this project.
was (Author: JIRAUSER280851):
[~stefanoltmann] [~kinow] Hi! Sorry I was really busy these days. I own all
the materials, including code and images, feel free to share to anyone if it
can helps you all to fix the code. In the end, I really appreciate your all's
library. It helps me a lot 4 years ago!
> updateExifMetadataLossless lost the first character of a String
> ---
>
> Key: IMAGING-319
> URL: https://issues.apache.org/jira/browse/IMAGING-319
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha2
>Reporter: Sicheng Yang
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0.0-alpha5
>
> Attachments: Screen Shot 2021-11-26 at 4.01.06 PM-1.png, Screen Shot
> 2021-11-26 at 4.01.21 PM-1.png, iPhone12-geotag.JPG
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I try to use TiffOutputSet to generate a new image. However, if a tag that
> contains String, the program may miss the first character of the String.
> {noformat}
> package org.apache.commons.imaging;
> import org.apache.commons.imaging.common.ImageMetadata;
> import org.apache.commons.imaging.formats.jpeg.JpegImageMetadata;
> import org.apache.commons.imaging.formats.jpeg.exif.ExifRewriter;
> import org.apache.commons.imaging.formats.tiff.TiffImageMetadata;
> import org.apache.commons.imaging.formats.tiff.write.TiffOutputSet;
> import java.io.BufferedOutputStream;
> import java.io.File;
> import java.io.FileOutputStream;
> import java.io.IOException;
> public class LibraryTest {
> public static void main(String[] args) throws ImagingException,
> IOException {
> File source = new File("/home/kinow/Desktop/iPhone12-geotag.JPG");
> File result = new
> File("/home/kinow/Desktop/editted-iPhone12-geotag.JPG");
> final ImageMetadata metadata = Imaging.getMetadata(source);
> final JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
> final TiffImageMetadata exif = jpegMetadata.getExif();
> TiffOutputSet outputSet = exif.getOutputSet();
> BufferedOutputStream bufferedOutputStream = new
> BufferedOutputStream(new FileOutputStream(result));
> new ExifRewriter().updateExifMetadataLossless(source,
> bufferedOutputStream, outputSet);
> }
> }{noformat}
> This is the sample code.
> Tag value in original image
> !image-2021-11-26-16-01-58-645.png!
> Tag value in output image
> !image-2021-11-26-16-04-12-185.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IMAGING-319) updateExifMetadataLossless lost the first character of a String
[
https://issues.apache.org/jira/browse/IMAGING-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886279#comment-17886279
]
Sicheng Yang edited comment on IMAGING-319 at 10/1/24 9:33 PM:
---
[~stefanoltmann] [~kinow] Hi! Sorry I was really busy these days. I own all
the materials, including code and images, feel free to share to anyone if it
can helps you all to fix the code. In the end, I really appreciate your all's
library. It helps me a lot 4 years ago!
was (Author: JIRAUSER280851):
[~stefanoltmann] [~kinow] Hi! Sorry I was really busy these days. I own all
the materials, including code and images, feel free to share to anyone if it
can helps you all to fix the code.
> updateExifMetadataLossless lost the first character of a String
> ---
>
> Key: IMAGING-319
> URL: https://issues.apache.org/jira/browse/IMAGING-319
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha2
>Reporter: Sicheng Yang
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0.0-alpha5
>
> Attachments: Screen Shot 2021-11-26 at 4.01.06 PM-1.png, Screen Shot
> 2021-11-26 at 4.01.21 PM-1.png, iPhone12-geotag.JPG
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I try to use TiffOutputSet to generate a new image. However, if a tag that
> contains String, the program may miss the first character of the String.
> {noformat}
> package org.apache.commons.imaging;
> import org.apache.commons.imaging.common.ImageMetadata;
> import org.apache.commons.imaging.formats.jpeg.JpegImageMetadata;
> import org.apache.commons.imaging.formats.jpeg.exif.ExifRewriter;
> import org.apache.commons.imaging.formats.tiff.TiffImageMetadata;
> import org.apache.commons.imaging.formats.tiff.write.TiffOutputSet;
> import java.io.BufferedOutputStream;
> import java.io.File;
> import java.io.FileOutputStream;
> import java.io.IOException;
> public class LibraryTest {
> public static void main(String[] args) throws ImagingException,
> IOException {
> File source = new File("/home/kinow/Desktop/iPhone12-geotag.JPG");
> File result = new
> File("/home/kinow/Desktop/editted-iPhone12-geotag.JPG");
> final ImageMetadata metadata = Imaging.getMetadata(source);
> final JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
> final TiffImageMetadata exif = jpegMetadata.getExif();
> TiffOutputSet outputSet = exif.getOutputSet();
> BufferedOutputStream bufferedOutputStream = new
> BufferedOutputStream(new FileOutputStream(result));
> new ExifRewriter().updateExifMetadataLossless(source,
> bufferedOutputStream, outputSet);
> }
> }{noformat}
> This is the sample code.
> Tag value in original image
> !image-2021-11-26-16-01-58-645.png!
> Tag value in output image
> !image-2021-11-26-16-04-12-185.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IMAGING-319) updateExifMetadataLossless lost the first character of a String
[
https://issues.apache.org/jira/browse/IMAGING-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886279#comment-17886279
]
Sicheng Yang commented on IMAGING-319:
--
[~stefanoltmann] [~kinow] Hi! Sorry I was really busy these days. I own all
the materials, including code and images, feel free to share to anyone if it
can helps you all to fix the code.
> updateExifMetadataLossless lost the first character of a String
> ---
>
> Key: IMAGING-319
> URL: https://issues.apache.org/jira/browse/IMAGING-319
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha2
>Reporter: Sicheng Yang
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0.0-alpha5
>
> Attachments: Screen Shot 2021-11-26 at 4.01.06 PM-1.png, Screen Shot
> 2021-11-26 at 4.01.21 PM-1.png, iPhone12-geotag.JPG
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I try to use TiffOutputSet to generate a new image. However, if a tag that
> contains String, the program may miss the first character of the String.
> {noformat}
> package org.apache.commons.imaging;
> import org.apache.commons.imaging.common.ImageMetadata;
> import org.apache.commons.imaging.formats.jpeg.JpegImageMetadata;
> import org.apache.commons.imaging.formats.jpeg.exif.ExifRewriter;
> import org.apache.commons.imaging.formats.tiff.TiffImageMetadata;
> import org.apache.commons.imaging.formats.tiff.write.TiffOutputSet;
> import java.io.BufferedOutputStream;
> import java.io.File;
> import java.io.FileOutputStream;
> import java.io.IOException;
> public class LibraryTest {
> public static void main(String[] args) throws ImagingException,
> IOException {
> File source = new File("/home/kinow/Desktop/iPhone12-geotag.JPG");
> File result = new
> File("/home/kinow/Desktop/editted-iPhone12-geotag.JPG");
> final ImageMetadata metadata = Imaging.getMetadata(source);
> final JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
> final TiffImageMetadata exif = jpegMetadata.getExif();
> TiffOutputSet outputSet = exif.getOutputSet();
> BufferedOutputStream bufferedOutputStream = new
> BufferedOutputStream(new FileOutputStream(result));
> new ExifRewriter().updateExifMetadataLossless(source,
> bufferedOutputStream, outputSet);
> }
> }{noformat}
> This is the sample code.
> Tag value in original image
> !image-2021-11-26-16-01-58-645.png!
> Tag value in output image
> !image-2021-11-26-16-04-12-185.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (BCEL-374) FIx tests on Java 23
[ https://issues.apache.org/jira/browse/BCEL-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated BCEL-374: - Description: Two tests fail on Java 23. Looking for a volunteer to look into this ;-) (was: Two tests fail on Java 23.) > FIx tests on Java 23 > > > Key: BCEL-374 > URL: https://issues.apache.org/jira/browse/BCEL-374 > Project: Commons BCEL > Issue Type: Bug > Environment: Java 23 >Reporter: Gary D. Gregory >Priority: Major > > Two tests fail on Java 23. Looking for a volunteer to look into this ;-) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (BCEL-374) FIx tests on Java 23
Gary D. Gregory created BCEL-374: Summary: FIx tests on Java 23 Key: BCEL-374 URL: https://issues.apache.org/jira/browse/BCEL-374 Project: Commons BCEL Issue Type: Bug Environment: Java 23 Reporter: Gary D. Gregory Two tests fail on Java 23. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (BEANUTILS-571) Fix put in for JDK 21 builds relating to locale needs changing for recent JDK
Samael Bate created BEANUTILS-571:
-
Summary: Fix put in for JDK 21 builds relating to locale needs
changing for recent JDK
Key: BEANUTILS-571
URL: https://issues.apache.org/jira/browse/BEANUTILS-571
Project: Commons BeanUtils
Issue Type: Bug
Reporter: Samael Bate
8 months ago I raised [a PR to fix CI on modern
JDKs|https://github.com/apache/commons-beanutils/pull/201]
([https://github.com/apache/commons-beanutils/commit/9dc4235bb0a47cb51d01c815a977f0228592f2f9])
see: https://issues.apache.org/jira/browse/BEANUTILS-564
The fix was to add {{-Djava.locale.providers=COMPAT}} to the surefire args so
that tests that compare times could work.
This was fine at the time as JDK 21 and 22 have that option:
-
[https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/spi/LocaleServiceProvider.html]
-
[https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/spi/LocaleServiceProvider.html]
but in JDK 23 it's been removed:
[https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/spi/LocaleServiceProvider.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CLI-339) Help formatter framework is hard to extend.
Claude Warren created CLI-339: - Summary: Help formatter framework is hard to extend. Key: CLI-339 URL: https://issues.apache.org/jira/browse/CLI-339 Project: Commons CLI Issue Type: Improvement Components: Help formatter Affects Versions: 1.9.0 Reporter: Claude Warren The current HelpFormatter implementation makes it difficult to extend and in some cases reuse components. The goal here is to create a help formatting framework that: * Supports all the current format configuration options * Is easily tested * provides ability to easily define and format the options table. This is the section of the help that currently lists the short & long option with arg name as the first column, the optional "since" column, and a description column that may contain deprecation information. * Provides the ability to easily add additional tables to the output. This implies access to the text wrapping functionality and formatting functionality. * Ability to output multiple formats. Current implementation only supports text output. There has been [discussion|https://lists.apache.org/thread/2powlgz6msqk6hqql55oo0fpgvb4x9kz] of desire for several other formats. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IMAGING-379) Generic solution for bounding memory use
Arnout Engelen created IMAGING-379: -- Summary: Generic solution for bounding memory use Key: IMAGING-379 URL: https://issues.apache.org/jira/browse/IMAGING-379 Project: Commons Imaging Issue Type: Improvement Components: imaging.* Reporter: Arnout Engelen Processing images can take considerable amounts memory, and running out of memory can impact the entire application. It would be great to have a mechanism to make sure image processing remains within 'reasonable' bounds, and fail gracefully when it exceeds them. Of course what is 'reasonable' is application-dependent. This issue exists to track the ideas and experiments around implementing such a mechanism, which will likely have impact on various APIs. The 'Allocator' API on the master branch is the current work towards this goal. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885040#comment-17885040
]
Saif Asif edited comment on LANG-1752 at 9/26/24 2:28 PM:
--
[~ggregory] I tested out and there is a NPE thrown when we use the equals
method of Strings.CS or Strings.CI. The original implementation of
StringUtils.equals is null safe.
I created a PR [https://github.com/apache/commons-lang/pull/1279] where I
Separated out test cases from StringUtils and added more cases for null check.
It seems that we are running into a NPE when we use the new
{{Strings.CS.equals(null,null)}} method. See
[line|https://github.com/apache/commons-lang/pull/1279/files#diff-190bb6d0ff6389981367f96b7e05541b5c7598c718e611d04f07d9cf66e7f65bR124]
where I created a test cases to highlight this exact failure case.
When using {{StringUtils.equals(null, null)}} it doesn't throw a NPE. IMO We
should use the same functionality when using either of the {{Strings.CS}} or
{{Strings.CI}} equals method.
Right now the test case in the PR is failing, I left it so you can also take a
look at what kind of functionality should be the right choice.
was (Author: saifasif):
[~ggregory] I tested out and there is a NPE thrown when we use the equals
method of Strings.CS or Strings.CI. The original implementation of
StringUtils.equals is null safe.
I created a PR [https://github.com/apache/commons-lang/pull/1279] where I
Separated out test cases from StringUtils and added more cases for null check.
It seems that we are running into a NPE when we use the new
{{Strings.CS.equals(null,null)}} method. See
[line|https://github.com/apache/commons-lang/pull/1279/files#diff-190bb6d0ff6389981367f96b7e05541b5c7598c718e611d04f07d9cf66e7f65bR124]
where I created a test cases to highlight this exact failure case.
When using {{StringUtils.equals(null, null)}} it doesn't throw a NPE. IMO We
should use the same functionality when using either of the {{Strings.CS}} or
{{Strings.CI}} equals method
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Saif Asif
>Assignee: Gary D. Gregory
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885040#comment-17885040
]
Saif Asif edited comment on LANG-1752 at 9/26/24 2:29 PM:
--
[~ggregory] I tested out and there is a NPE thrown when we use the equals
method of Strings.CS or Strings.CI. The original implementation of
StringUtils.equals is null safe.
I created a PR [https://github.com/apache/commons-lang/pull/1279] where I
Separated out test cases from StringUtils and added more cases for null check.
It seems that we are running into a NPE when we use the new
{{Strings.CS.equals(null,null)}} method. See
[line|https://github.com/apache/commons-lang/pull/1279/files#diff-190bb6d0ff6389981367f96b7e05541b5c7598c718e611d04f07d9cf66e7f65bR124]
where I created a test cases to highlight this exact failure case.
When using {{StringUtils.equals(null, null)}} it doesn't throw a NPE. IMO We
should use the same functionality when using either of the {{Strings.CS}} or
{{Strings.CI}} equals method.
Right now the test case in the PR is failing, I left it so you can also take a
look first and then we can add in whatever functionality we feel should be the
right choice to avoid NPE.
was (Author: saifasif):
[~ggregory] I tested out and there is a NPE thrown when we use the equals
method of Strings.CS or Strings.CI. The original implementation of
StringUtils.equals is null safe.
I created a PR [https://github.com/apache/commons-lang/pull/1279] where I
Separated out test cases from StringUtils and added more cases for null check.
It seems that we are running into a NPE when we use the new
{{Strings.CS.equals(null,null)}} method. See
[line|https://github.com/apache/commons-lang/pull/1279/files#diff-190bb6d0ff6389981367f96b7e05541b5c7598c718e611d04f07d9cf66e7f65bR124]
where I created a test cases to highlight this exact failure case.
When using {{StringUtils.equals(null, null)}} it doesn't throw a NPE. IMO We
should use the same functionality when using either of the {{Strings.CS}} or
{{Strings.CI}} equals method.
Right now the test case in the PR is failing, I left it so you can also take a
look at what kind of functionality should be the right choice.
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Saif Asif
>Assignee: Gary D. Gregory
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885040#comment-17885040
]
Saif Asif commented on LANG-1752:
-
[~ggregory] I tested out and there is a NPE thrown when we use the equals
method of Strings.CS or Strings.CI. The original implementation of
StringUtils.equals is null safe.
I created a PR [https://github.com/apache/commons-lang/pull/1279] where I
Separated out test cases from StringUtils and added more cases for null check.
It seems that we are running into a NPE when we use the new
{{Strings.CS.equals(null,null)}} method. See
[line|https://github.com/apache/commons-lang/pull/1279/files#diff-190bb6d0ff6389981367f96b7e05541b5c7598c718e611d04f07d9cf66e7f65bR124]
where I created a test cases to highlight this exact failure case.
When using {{StringUtils.equals(null, null)}} it doesn't throw a NPE. IMO We
should use the same functionality when using either of the {{Strings.CS}} or
{{Strings.CI}} equals method
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Saif Asif
>Assignee: Gary D. Gregory
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IMAGING-328) Support for WEBP image format
[ https://issues.apache.org/jira/browse/IMAGING-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884930#comment-17884930 ] Swastik Pal commented on IMAGING-328: - I was wondering if creating a Java Implementation based on Google's libwebp reference implementation sources https://chromium.googlesource.com/webm/libwebp is acceptable (Licence-wise) for this project. > Support for WEBP image format > - > > Key: IMAGING-328 > URL: https://issues.apache.org/jira/browse/IMAGING-328 > Project: Commons Imaging > Issue Type: Improvement >Reporter: David Ekholm >Priority: Major > > We'd like to see support for the WEBP image format as it's such a widely > supported image format on the web today. With support for WEBP we will be > able to extract and embed xmp metadata into WEBP images too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884775#comment-17884775
]
Gary D. Gregory commented on LANG-1752:
---
Hello [~SaifAsif]
You can test this in your app and make sure everything works as expected.
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Saif Asif
>Assignee: Gary D. Gregory
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884773#comment-17884773
]
Saif Asif commented on LANG-1752:
-
[~ggregory] Just got time to look through the commits. I like the
{{Strings.CI}} approach and I see you already made the changes for
CharSequenceUtils as well. Its a clean approach and doesn't have a lot of
impact for users. What is the next steps for this then ?
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Saif Asif
>Assignee: Gary D. Gregory
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LANG-1752:
--
Affects Version/s: (was: 4.0)
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Saif Asif
>Assignee: Gary D. Gregory
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883497#comment-17883497
]
Gary D. Gregory edited comment on LANG-1752 at 9/25/24 7:58 PM:
[~SaifAsif] Please see {{Strings}} in git master.
was (Author: garydgregory):
[~SaifAsif] Please see git master.
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Saif Asif
>Assignee: Gary D. Gregory
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-430) JexlArithmetic behavior change
[
https://issues.apache.org/jira/browse/JEXL-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884501#comment-17884501
]
Henri Biestro edited comment on JEXL-430 at 9/25/24 5:53 AM:
-
This new behavior is intended, the type system is less lenient than it was. In
this case, comparing a string to a number is not a clear semantic; do we try
and coerce to number before comparison or to string ?
The workaround Is to remove the ambiguity by deriving the JexlArithmetic and
adding a method 'public int compare(Number n, String s);' which will be used by
all comparison operators (and even automatically be applied to arguments
(String, Number) thanks to JEXL-428 ) that gives you full control over the
intended behavior.
was (Author: henrib):
This new behavior is intended, the type system is less lenient than it was. In
this case, comparing a string to a number is not a clear semantic; do we try
and coerce to number before comparison or to string ?
The workaround Is to remove the ambiguity by deriving the JexlArithmetic and
adding a method 'public int compare(Number n, String s);' which will be used by
all comparison operators (and even automatically be applied to arguments
(String, Number) thanks to JEXL-428 ).
> JexlArithmetic behavior change
> --
>
> Key: JEXL-430
> URL: https://issues.apache.org/jira/browse/JEXL-430
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {*}Regression{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-429) Ternary expression regression
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-429:
---
Fix Version/s: 3.4.1
> Ternary expression regression
> -
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {*}Regression{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-430) JexlArithmetic behavior change
[
https://issues.apache.org/jira/browse/JEXL-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884501#comment-17884501
]
Henri Biestro edited comment on JEXL-430 at 9/25/24 5:49 AM:
-
This new behavior is intended, the type system is less lenient than it was. In
this case, comparing a string to a number is not a clear semantic; do we try
and coerce to number before comparison or to string ?
The workaround Is to remove the ambiguity by deriving the JexlArithmetic and
adding a method 'public int compare(Number n, String s);' which will be used by
all comparison operators (and even automatically be applied to arguments
(String, Number) thanks to JEXL-428 ).
was (Author: henrib):
This new behavior is intended, the type system is less lenient than it was. In
this case, comparing a string to a number is not a clear semantic; do we try
and coerce to number before comparison or to string ?
The workaround Is to remove the ambiguity by deriving the JexlArithmetic and
adding a method 'public int compare(Number n, String s);' which will be used by
all comparison operators (and even automatically be applied to arguments
(String, Number) thanks to JEXL-428.
> JexlArithmetic behavior change
> --
>
> Key: JEXL-430
> URL: https://issues.apache.org/jira/browse/JEXL-430
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {*}Regression{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-428) Make Comparable object high priority while comparing
[ https://issues.apache.org/jira/browse/JEXL-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884505#comment-17884505 ] Henri Biestro edited comment on JEXL-428 at 9/25/24 5:49 AM: - The problem with Comparable interface is that its generic nature implies the signature is compareTo(Object) which does not help disambiguate the call. The workaround is to implement your own 'public int compare(MyClass lhs, String rhs)' - or any signature you need to disambiguate - in your own derived arithmetic. Commit [2d2300e|https://github.com/apache/commons-jexl/commit/2d2300e0fea55e1da432d3ef1b04ba49afc5b025] was (Author: henrib): Commit [2d2300e|https://github.com/apache/commons-jexl/commit/2d2300e0fea55e1da432d3ef1b04ba49afc5b025] > Make Comparable object high priority while comparing > > > Key: JEXL-428 > URL: https://issues.apache.org/jira/browse/JEXL-428 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Major > Fix For: 3.4.1 > > > [https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/JexlArithmetic.java#L787] > > I defined a Class with implemented Comparable interface, when compare it with > a string object, engine does not call the compareTo method but compares by > string value. > > At JexlArithmetic.java L787, if one of the left/right value is string type, > then compares by string value, I think if the left value is Comparable and > not String type, using left object's compareTo method first makes more sense. > Thanks! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-428) Make Comparable object high priority while comparing
[ https://issues.apache.org/jira/browse/JEXL-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-428. Resolution: Fixed Commit [2d2300e|https://github.com/apache/commons-jexl/commit/2d2300e0fea55e1da432d3ef1b04ba49afc5b025] > Make Comparable object high priority while comparing > > > Key: JEXL-428 > URL: https://issues.apache.org/jira/browse/JEXL-428 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Major > Fix For: 3.4.1 > > > [https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/JexlArithmetic.java#L787] > > I defined a Class with implemented Comparable interface, when compare it with > a string object, engine does not call the compareTo method but compares by > string value. > > At JexlArithmetic.java L787, if one of the left/right value is string type, > then compares by string value, I think if the left value is Comparable and > not String type, using left object's compareTo method first makes more sense. > Thanks! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JEXL-429) Ternary expression regression
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-429.
Resolution: Fixed
Commit
[2d2300e|https://github.com/apache/commons-jexl/commit/2d2300e0fea55e1da432d3ef1b04ba49afc5b025]
> Ternary expression regression
> -
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Assignee: Henri Biestro
>Priority: Major
>
> {*}Regression{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-429) Ternary expression regression
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884502#comment-17884502
]
Henri Biestro commented on JEXL-429:
Ternary and namespace syntax is a grammar ambiguity pothole.
To fix this, a new hint will consider if the function name (the fun in ns :
fun()) is a variable which solves this precise case.
A new feature flag is introduced, 'namespace identifier' which considers a
namespace identifier as one token that is only when 'ns:fun' is written with no
space in between. Default remains false but, as per recommendation, one should
be explicit about which feature, option, security and arithmetic is used.
> Ternary expression regression
> -
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Assignee: Henri Biestro
>Priority: Major
>
> {*}Regression{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-430) JexlArithmetic behavior change
[
https://issues.apache.org/jira/browse/JEXL-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-430.
Assignee: Henri Biestro
Resolution: Workaround
This new behavior is intended, the type system is less lenient than it was. In
this case, comparing a string to a number is not a clear semantic; do we try
and coerce to number before comparison or to string ?
The workaround Is to remove the ambiguity by deriving the JexlArithmetic and
adding a method 'public int compare(Number n, String s);' which will be used by
all comparison operators (and even automatically be applied to arguments
(String, Number) thanks to JEXL-428.
> JexlArithmetic behavior change
> --
>
> Key: JEXL-430
> URL: https://issues.apache.org/jira/browse/JEXL-430
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.4.1
>
>
> {*}Regression{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-429) Ternary expression regression
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-429:
---
Summary: Ternary expression regression (was: Regressions in 3.4.0)
> Ternary expression regression
> -
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Assignee: Henri Biestro
>Priority: Major
>
> {*}Regression{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-429) Regressions in 3.4.0
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-429:
---
Description:
{*}Regression{*}:
{code:java}
const f = function(a) {return a;};
b ? b : f(2);{code}
When the script is executed, there is a variable *b* in the jexl context with
value as {*}1{*}.
The script returns 1 as expected in 3.3, but throws a parsing exception in
3.4.0.
{code:java}
parsing error in ';'
at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
{code}
If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
and 2 is returned as expected.
was:
{*}Regression #1{*}:
{code:java}
"1.1" > 0 {code}
returns *true* in 3.3. But it throws an exception in 3.4.0.
{code:java}
java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
at org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
at
org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
at org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
{*}Regression #2{*}:
{code:java}
const f = function(a) {return a;};
b ? b : f(2);{code}
When the script is executed, there is a variable *b* in the jexl context with
value as {*}1{*}.
The script returns 1 as expected in 3.3, but throws a parsing exception in
3.4.0.
{code:java}
parsing error in ';'
at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
{code}
If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
and 2 is returned as expected.
> Regressions in 3.4.0
>
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Assignee: Henri Biestro
>Priority: Major
>
> {*}Regression{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-430) JexlArithmetic behavior change
Henri Biestro created JEXL-430:
--
Summary: JexlArithmetic behavior change
Key: JEXL-430
URL: https://issues.apache.org/jira/browse/JEXL-430
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.4.0
Reporter: Henri Biestro
Fix For: 3.4.1
{*}Regression{*}:
{code:java}
"1.1" > 0 {code}
returns *true* in 3.3. But it throws an exception in 3.4.0.
{code:java}
java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
at org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
at
org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
at org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-429) Regressions in 3.4.0
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-429:
---
Assignee: Henri Biestro
> Regressions in 3.4.0
>
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Assignee: Henri Biestro
>Priority: Major
>
> {*}Regression #1{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
> {*}Regression #2{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VFS-840) IllegalArgumentException when using special characters in filename eg [ or ] and calling FileObject.getPath method
[
https://issues.apache.org/jira/browse/VFS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884051#comment-17884051
]
Matthew Bellew commented on VFS-840:
The problem seems to be that UriParser.encode(uri, RESERVED_URI_CHARS) as
called from AbstractFileName.handleURISpecialCharacters() does not encode these
5 characters, causing an error later when java.net.URI.create() is called.
> IllegalArgumentException when using special characters in filename eg [ or ]
> and calling FileObject.getPath method
> --
>
> Key: VFS-840
> URL: https://issues.apache.org/jira/browse/VFS-840
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10
> Java 17
> Apache VFS 2.9.0
>Reporter: Usman Ashraf Bajwah
>Priority: Major
> Attachments: Main.java
>
>
> When special characters ([ or ] for example there might be others also) are
> used in filename FileObject resolve it alright but calling its getPath method
> fails with following exception.
>
> +java.lang.IllegalArgumentException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:906+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getURI({color}+FileObject.java:310+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getPath({color}+FileObject.java:320+{color:#ff}){color}
> {color:#ff} at
> com.gallerysystems.tms.common.util.FileUtil.main({color}+FileUtil.java:859+{color:#ff}){color}
> {color:#ff}Caused by:
> {color}+java.net.URISyntaxException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI$Parser.fail({color}+URI.java:2974+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.checkChars({color}+URI.java:3145+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parseHierarchical({color}+URI.java:3227+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parse({color}+URI.java:3175+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.({color}+URI.java:623+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:904+{color:#ff}){color}
> {color:#ff} ... 3 more{color}
>
> Following is the code to reproduce the issue.
> {color:#7f0055}try{color}{color:#00} {{color}
> {color:#00} String {color}{color:#6a3e3e}fileName{color}{color:#00} =
> {color}{color:#2a00ff}"D:\\citrus[1].jpg"{color}{color:#00};{color}
> {color:#00} FileSystemManager
> {color}{color:#6a3e3e}fsManager{color}{color:#00} =
> VFS.{color}{color:#00}getManager{color}{color:#00}();{color}
> {color:#00} FileObject
> {color}{color:#6a3e3e}fileObject{color}{color:#00} =
> {color}{color:#6a3e3e}fsManager{color}{color:#00}.resolveFile({color}{color:#6a3e3e}fileName{color}{color:#00});{color}
> {color:#00}
> System.{color}{color:#c0}out{color}{color:#00}.println({color}{color:#6a3e3e}fileObject{color}{color:#00}.getPath());{color}
> {color:#00} }{color}{color:#7f0055}catch{color}{color:#00}(Exception
> {color}{color:#6a3e3e}ex{color}{color:#00}) {{color}
> {color:#00}
> {color}{color:#6a3e3e}ex{color}{color:#00}.printStackTrace();{color}
> {color:#00} }{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (VFS-840) IllegalArgumentException when using special characters in filename eg [ or ] and calling FileObject.getPath method
[
https://issues.apache.org/jira/browse/VFS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew Bellew updated VFS-840:
---
Attachment: Main.java
> IllegalArgumentException when using special characters in filename eg [ or ]
> and calling FileObject.getPath method
> --
>
> Key: VFS-840
> URL: https://issues.apache.org/jira/browse/VFS-840
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10
> Java 17
> Apache VFS 2.9.0
>Reporter: Usman Ashraf Bajwah
>Priority: Major
> Attachments: Main.java
>
>
> When special characters ([ or ] for example there might be others also) are
> used in filename FileObject resolve it alright but calling its getPath method
> fails with following exception.
>
> +java.lang.IllegalArgumentException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:906+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getURI({color}+FileObject.java:310+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getPath({color}+FileObject.java:320+{color:#ff}){color}
> {color:#ff} at
> com.gallerysystems.tms.common.util.FileUtil.main({color}+FileUtil.java:859+{color:#ff}){color}
> {color:#ff}Caused by:
> {color}+java.net.URISyntaxException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI$Parser.fail({color}+URI.java:2974+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.checkChars({color}+URI.java:3145+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parseHierarchical({color}+URI.java:3227+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parse({color}+URI.java:3175+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.({color}+URI.java:623+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:904+{color:#ff}){color}
> {color:#ff} ... 3 more{color}
>
> Following is the code to reproduce the issue.
> {color:#7f0055}try{color}{color:#00} {{color}
> {color:#00} String {color}{color:#6a3e3e}fileName{color}{color:#00} =
> {color}{color:#2a00ff}"D:\\citrus[1].jpg"{color}{color:#00};{color}
> {color:#00} FileSystemManager
> {color}{color:#6a3e3e}fsManager{color}{color:#00} =
> VFS.{color}{color:#00}getManager{color}{color:#00}();{color}
> {color:#00} FileObject
> {color}{color:#6a3e3e}fileObject{color}{color:#00} =
> {color}{color:#6a3e3e}fsManager{color}{color:#00}.resolveFile({color}{color:#6a3e3e}fileName{color}{color:#00});{color}
> {color:#00}
> System.{color}{color:#c0}out{color}{color:#00}.println({color}{color:#6a3e3e}fileObject{color}{color:#00}.getPath());{color}
> {color:#00} }{color}{color:#7f0055}catch{color}{color:#00}(Exception
> {color}{color:#6a3e3e}ex{color}{color:#00}) {{color}
> {color:#00}
> {color}{color:#6a3e3e}ex{color}{color:#00}.printStackTrace();{color}
> {color:#00} }{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VFS-840) IllegalArgumentException when using special characters in filename eg [ or ] and calling FileObject.getPath method
[
https://issues.apache.org/jira/browse/VFS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884049#comment-17884049
]
Matthew Bellew commented on VFS-840:
2.10.0 fails in the same way. E.g.
Exception in thread "main" java.lang.IllegalArgumentException: Illegal
character in path at index 8: file:///[
at java.base/java.net.URI.create(URI.java:906)
at org.apache.commons.vfs2.FileObject.getURI(FileObject.java:321)
at org.apache.commons.vfs2.FileObject.getPath(FileObject.java:296)
at Main.main(Main.java:22)
Caused by: java.net.URISyntaxException: Illegal character in path at index 8:
file:///[
at java.base/java.net.URI$Parser.fail(URI.java:2976)
at java.base/java.net.URI$Parser.checkChars(URI.java:3147)
at java.base/java.net.URI$Parser.parseHierarchical(URI.java:3229)
at java.base/java.net.URI$Parser.parse(URI.java:3177)
at java.base/java.net.URI.(URI.java:623)
at java.base/java.net.URI.create(URI.java:904)
... 3 more
> IllegalArgumentException when using special characters in filename eg [ or ]
> and calling FileObject.getPath method
> --
>
> Key: VFS-840
> URL: https://issues.apache.org/jira/browse/VFS-840
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10
> Java 17
> Apache VFS 2.9.0
>Reporter: Usman Ashraf Bajwah
>Priority: Major
>
> When special characters ([ or ] for example there might be others also) are
> used in filename FileObject resolve it alright but calling its getPath method
> fails with following exception.
>
> +java.lang.IllegalArgumentException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:906+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getURI({color}+FileObject.java:310+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getPath({color}+FileObject.java:320+{color:#ff}){color}
> {color:#ff} at
> com.gallerysystems.tms.common.util.FileUtil.main({color}+FileUtil.java:859+{color:#ff}){color}
> {color:#ff}Caused by:
> {color}+java.net.URISyntaxException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI$Parser.fail({color}+URI.java:2974+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.checkChars({color}+URI.java:3145+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parseHierarchical({color}+URI.java:3227+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parse({color}+URI.java:3175+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.({color}+URI.java:623+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:904+{color:#ff}){color}
> {color:#ff} ... 3 more{color}
>
> Following is the code to reproduce the issue.
> {color:#7f0055}try{color}{color:#00} {{color}
> {color:#00} String {color}{color:#6a3e3e}fileName{color}{color:#00} =
> {color}{color:#2a00ff}"D:\\citrus[1].jpg"{color}{color:#00};{color}
> {color:#00} FileSystemManager
> {color}{color:#6a3e3e}fsManager{color}{color:#00} =
> VFS.{color}{color:#00}getManager{color}{color:#00}();{color}
> {color:#00} FileObject
> {color}{color:#6a3e3e}fileObject{color}{color:#00} =
> {color}{color:#6a3e3e}fsManager{color}{color:#00}.resolveFile({color}{color:#6a3e3e}fileName{color}{color:#00});{color}
> {color:#00}
> System.{color}{color:#c0}out{color}{color:#00}.println({color}{color:#6a3e3e}fileObject{color}{color:#00}.getPath());{color}
> {color:#00} }{color}{color:#7f0055}catch{color}{color:#00}(Exception
> {color}{color:#6a3e3e}ex{color}{color:#00}) {{color}
> {color:#00}
> {color}{color:#6a3e3e}ex{color}{color:#00}.printStackTrace();{color}
> {color:#00} }{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NET-735) IMAP missing timeout on SSL handshake
John van der Kamp created NET-735:
-
Summary: IMAP missing timeout on SSL handshake
Key: NET-735
URL: https://issues.apache.org/jira/browse/NET-735
Project: Commons Net
Issue Type: Bug
Components: IMAP
Affects Versions: 3.11.1, 3.5
Reporter: John van der Kamp
When an SSL handshake is not being received due to network issues, this is not
detected and the connection hangs waiting for data. The code does not install a
timeout on the ssl socket.
We are using the following patch to fix this:
{{---
commons-net/commons-net/3.11.1/commons-net-3.11.1-sources/org/apache/commons/net/imap/IMAPSClient.java}}
{{+++
commons-net/commons-net/3.11.1/commons-net-3.11.1-sources/org/apache/commons/net/imap/IMAPSClient.java}}
{{@@ -282,6 +282,7 @@ public class IMAPSClient extends IMAPClient {}}
{{ final SSLSocket socket = (SSLSocket) ssf.createSocket(_socket_,
host, port, true);}}
{{ socket.setEnableSessionCreation(true);}}
{{ socket.setUseClientMode(true);}}
{{+ socket.setSoTimeout(1000);}}
{{ }}
{{ if (tlsEndpointChecking) {}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NET-734) IMAP login fails with 3.11.1
John van der Kamp created NET-734:
-
Summary: IMAP login fails with 3.11.1
Key: NET-734
URL: https://issues.apache.org/jira/browse/NET-734
Project: Commons Net
Issue Type: Bug
Components: IMAP
Affects Versions: 3.11.1
Reporter: John van der Kamp
We tried to upgrade from 3.5 to 3.11.1 but now IMAP logins fail. In
IMAPReply.java a regular expression is changed and now looks like this:
{quote} private static final String TAGGED_RESPONSE = "^\\w\{1,80}
(\\S\{1,80}).\{0,80}";
{quote}
The matchings now have length restrictions and this fails the call to
{{matches}} later on in {{{}getReplyCode{}}}.
The IMAP server in our case sends the following reply on a correct login:
{{CBJJ OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ENABLE IDLE ID SORT
SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND
URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED
I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH
LIST-STATUS BINARY MOVE STATUS=SIZE SAVEDATE LITERAL+ QUOTA] Logged in}}
{{}}
and now we get an {{{}org.apache.commons.net.MalformedServerReplyException{}}}.
The login was fine, but the check is faulty.{{{}{}}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-429) Regressions in 3.4.0
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883891#comment-17883891
]
Henri Biestro commented on JEXL-429:
Something can be done to improve JEXL-412; a function call using a local
variable can be used as hint.
For the arithmetic new stricter behavior, the workaround would be to derive a
JexlArithmetic and add a compare(String, Number) method; need to commit
JEXL-428 related work first.
PS: 2 issues in one ticket is really inconvenient.
> Regressions in 3.4.0
>
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Priority: Major
>
> {*}Regression #1{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
> {*}Regression #2{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-429) Regressions in 3.4.0
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883820#comment-17883820
]
Gary D. Gregory commented on JEXL-429:
--
I think we can close this ticket as "info provided".
> Regressions in 3.4.0
>
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Priority: Major
>
> {*}Regression #1{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
> {*}Regression #2{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-429) Regressions in 3.4.0
[
https://issues.apache.org/jira/browse/JEXL-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883765#comment-17883765
]
Henri Biestro commented on JEXL-429:
Related to:
1/ [JEXL-420|https://issues.apache.org/jira/browse/JEXL-420]
2/ [JEXL-412|https://issues.apache.org/jira/browse/JEXL-412]
> Regressions in 3.4.0
>
>
> Key: JEXL-429
> URL: https://issues.apache.org/jira/browse/JEXL-429
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Shuo Geng
>Priority: Major
>
> {*}Regression #1{*}:
> {code:java}
> "1.1" > 0 {code}
> returns *true* in 3.3. But it throws an exception in 3.4.0.
> {code:java}
> java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
> at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
> at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
> at
> org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
> at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
> {*}Regression #2{*}:
> {code:java}
> const f = function(a) {return a;};
> b ? b : f(2);{code}
> When the script is executed, there is a variable *b* in the jexl context with
> value as {*}1{*}.
> The script returns 1 as expected in 3.3, but throws a parsing exception in
> 3.4.0.
> {code:java}
> parsing error in ';'
> at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
> {code}
> If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
> and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-429) Regressions in 3.4.0
Shuo Geng created JEXL-429:
--
Summary: Regressions in 3.4.0
Key: JEXL-429
URL: https://issues.apache.org/jira/browse/JEXL-429
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.4.0
Reporter: Shuo Geng
{*}Regression #1{*}:
{code:java}
"1.1" > 0 {code}
returns *true* in 3.3. But it throws an exception in 3.4.0.
{code:java}
java.lang.ArithmeticException: Object comparison:(1.1 GT 0)
at org.apache.commons.jexl3.JexlArithmetic.doCompare(JexlArithmetic.java:806)
at org.apache.commons.jexl3.JexlArithmetic.compare(JexlArithmetic.java:503)
at org.apache.commons.jexl3.JexlArithmetic.greaterThan(JexlArithmetic.java:892)
at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1448)
at org.apache.commons.jexl3.parser.ASTGTNode.jjtAccept(ASTGTNode.java:19)
at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1532)
at
org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:137)
at org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:843)
at org.apache.commons.jexl3.internal.Script.execute(Script.java:239) {code}
{*}Regression #2{*}:
{code:java}
const f = function(a) {return a;};
b ? b : f(2);{code}
When the script is executed, there is a variable *b* in the jexl context with
value as {*}1{*}.
The script returns 1 as expected in 3.3, but throws a parsing exception in
3.4.0.
{code:java}
parsing error in ';'
at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:411)
{code}
If the ternary statement is changed to {{b ? f(2) : b;}} , there is no issue
and 2 is returned as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1707) Syntactic sugar to concatenate arrays
[
https://issues.apache.org/jira/browse/LANG-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LANG-1707:
--
Fix Version/s: (was: 3.18.0)
> Syntactic sugar to concatenate arrays
> -
>
> Key: LANG-1707
> URL: https://issues.apache.org/jira/browse/LANG-1707
> Project: Commons Lang
> Issue Type: Wish
> Components: lang.*
>Affects Versions: 3.13.0
>Reporter: Gilles Sadowski
>Priority: Trivial
> Labels: suggestion
>
> In {{ArrayUtils}}, a method such as {{addAll(T[], T ... others)}} makes it
> easy to concatenate two arrays.
> Then, one can concatenate several arrays:
> {code}
> /**
> * @param Type.
> * @param arrays Arrays.
> * @return an array that contains all the elements in the input arrays.
> */
> private static T[] concat(T[] ... arrays) {
> final int numArr = arrays.length;
> T[] concatenated = null;
> for (int i = numArr; i > 0; i--) {
> concatenated = ArrayUtils.addAll(arrays[i - 1], concatenated);
> }
> return concatenated;
> }
> {code}
> Shouldn't {{concat(T[] ...)}} be part of {{ArrayUtils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1656) Short-circuit operation of firstNonBlank and firstNonEmpty
[
https://issues.apache.org/jira/browse/LANG-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LANG-1656:
--
Fix Version/s: (was: 3.18.0)
> Short-circuit operation of firstNonBlank and firstNonEmpty
> --
>
> Key: LANG-1656
> URL: https://issues.apache.org/jira/browse/LANG-1656
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Affects Versions: 3.12.0
>Reporter: Zhengkai Wang
>Priority: Minor
> Labels: features
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> Sometimes it is not possible to provide an array of strings, but only an
> array of methods to obtain a string to obtain a string. At this time, you do
> not need to execute all the methods in the method array, only need to execute
> until the first method whose result is not an empty string or a blank string.
> E.g.
> {code:java}
> StringUtil.firstNonBlank(()-> "123", ()-> rpcMethod(), ()->dbQuery())
> {code}
> In the above code, we only need to execute the first method, not the latter
> two methods, because the latter two methods may be time-consuming.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (LANG-1482) Functions
[
https://issues.apache.org/jira/browse/LANG-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LANG-1482.
---
Fix Version/s: (was: 3.18.0)
Resolution: Pending Closed
PR is closed.
> Functions
> --
>
> Key: LANG-1482
> URL: https://issues.apache.org/jira/browse/LANG-1482
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Peter Verhas
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The implementation of the methods {{asRunnable()}}, {{asConsumer()}},
> {{asCallable()}}, {{asBiConsumer()}} etc. is redundant and copy-paste. They
> are implemented with the structure (example from {{asRunnable()}}:
> {code}
> return () -> {
> try {
> pRunnable.run();
> } catch (Throwable t) {
> throw rethrow(t);
> }
> };
> {code}
> This try-catch structure is already implemented in the class and can be used
> here simplifying the method to
> {code}
> return () -> run(pRunnable);
> {code}
> Also, the tests for {{asPredicate()}} and {{asBiPredicate()}} are missing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1595) Add ArrayUtils methods that accept a Predicate.
[ https://issues.apache.org/jira/browse/LANG-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LANG-1595: -- Fix Version/s: (was: 3.18.0) > Add ArrayUtils methods that accept a Predicate. > --- > > Key: LANG-1595 > URL: https://issues.apache.org/jira/browse/LANG-1595 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Isira Seneviratne >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (LANG-1747) Measure the execution time of functional interfaces
[
https://issues.apache.org/jira/browse/LANG-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LANG-1747.
---
Fix Version/s: 3.17.1
Resolution: Fixed
Hello [~o.b.fischer]
I took a simpler route than we previously discussed by only adding
{{StopWatch.run([Failable]Runnable)}} and
{{get([Failable]Supplier)}} which I believe should be able to handle the most
common use cases.
> Measure the execution time of functional interfaces
> ---
>
> Key: LANG-1747
> URL: https://issues.apache.org/jira/browse/LANG-1747
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.time.*
>Reporter: Oliver B. Fischer
>Priority: Major
> Fix For: 3.17.1
>
>
> As a developer, I would like to be able to use a stop watch with modern
> language features, so that I can measure the time recuired for
> {{{}Runable{}}}s or {{{}Supplier{}}}s or similar stuff.
> I would like to be able to write code similar to this example
> {code:java}
> StopWatch watch = StopWatch.create();
> watch.takeTime( () -> { ...} )
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CSV-272) Support fixed-width format
[ https://issues.apache.org/jira/browse/CSV-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883534#comment-17883534 ] Bernd Eckenfels commented on CSV-272: - A fixed-widt format has a fixed length for each field, it can have one or multiple record types, each record describing the length of each field in bytes, code units or codepoints. I think this is entirely out of scope for the csv parser (however when we would provide a fixed length or cpnpö-record or in-house parser (sap idocs also use this format)) it would maybe be good idea to share a common retrieval interface. Suggestion! Wont fix > Support fixed-width format > -- > > Key: CSV-272 > URL: https://issues.apache.org/jira/browse/CSV-272 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.8 >Reporter: Holger Brandl >Priority: Major > > Although not strictly a delimiter format, fixed-width tables are still very > common. So it would be great if commons-csv would support fixed-width via a > dedicated format. > Since jira does not render fixed-delim content correctly, I've deposited an > example under > https://gist.github.com/holgerbrandl/26298ae77d53b3393d9d22c73249ab72 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CSV-272) Support fixed-width format
[
https://issues.apache.org/jira/browse/CSV-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883501#comment-17883501
]
David Szigecsan commented on CSV-272:
-
I checked the file at linked gist and I have some problems understanding what
would be the expectation.
# I can't see any delimiter (I mean there are spaces, but their count is
different in each cell)
# If I assume the whitespace is the delimiter, then what about "Product 1"?
Does it count as one ("Product 1") or two ("Product" and "1")?
# What do you mean about "fixed-width"? Every cell has the same amount of
characters? What about "Pa wafer" following more space than the line starting
"1"?
The only logic I could use is when there is one single whitespace, that is part
of the data, but more consecutive whitespaces are delimiter.
For me, it does not seem like a CSV or its alternatives (with a tab or
anything). Especially after checking the "test wafer" followed by 15 spaces.
Tabs usually represent 4 or 8 spaces, not 15.
> Support fixed-width format
> --
>
> Key: CSV-272
> URL: https://issues.apache.org/jira/browse/CSV-272
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.8
>Reporter: Holger Brandl
>Priority: Major
>
> Although not strictly a delimiter format, fixed-width tables are still very
> common. So it would be great if commons-csv would support fixed-width via a
> dedicated format.
> Since jira does not render fixed-delim content correctly, I've deposited an
> example under
> https://gist.github.com/holgerbrandl/26298ae77d53b3393d9d22c73249ab72
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883497#comment-17883497
]
Gary D. Gregory commented on LANG-1752:
---
[~ggregory] Please see git master.
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Saif Asif
>Assignee: Gary D. Gregory
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883497#comment-17883497
]
Gary D. Gregory edited comment on LANG-1752 at 9/21/24 2:50 PM:
[~SaifAsif] Please see git master.
was (Author: garydgregory):
[~ggregory] Please see git master.
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Saif Asif
>Assignee: Gary D. Gregory
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LANG-1752:
--
Assignee: Gary D. Gregory
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Saif Asif
>Assignee: Gary D. Gregory
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VFS-840) IllegalArgumentException when using special characters in filename eg [ or ] and calling FileObject.getPath method
[
https://issues.apache.org/jira/browse/VFS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883442#comment-17883442
]
Gary D. Gregory commented on VFS-840:
-
Hello [~mbellew]
Please try 2.10.0-SNAPSHOT from git master or the snapshot repository:
[https://repository.apache.org/content/repositories/snapshots]
TY
> IllegalArgumentException when using special characters in filename eg [ or ]
> and calling FileObject.getPath method
> --
>
> Key: VFS-840
> URL: https://issues.apache.org/jira/browse/VFS-840
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10
> Java 17
> Apache VFS 2.9.0
>Reporter: Usman Ashraf Bajwah
>Priority: Major
>
> When special characters ([ or ] for example there might be others also) are
> used in filename FileObject resolve it alright but calling its getPath method
> fails with following exception.
>
> +java.lang.IllegalArgumentException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:906+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getURI({color}+FileObject.java:310+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getPath({color}+FileObject.java:320+{color:#ff}){color}
> {color:#ff} at
> com.gallerysystems.tms.common.util.FileUtil.main({color}+FileUtil.java:859+{color:#ff}){color}
> {color:#ff}Caused by:
> {color}+java.net.URISyntaxException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI$Parser.fail({color}+URI.java:2974+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.checkChars({color}+URI.java:3145+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parseHierarchical({color}+URI.java:3227+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parse({color}+URI.java:3175+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.({color}+URI.java:623+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:904+{color:#ff}){color}
> {color:#ff} ... 3 more{color}
>
> Following is the code to reproduce the issue.
> {color:#7f0055}try{color}{color:#00} {{color}
> {color:#00} String {color}{color:#6a3e3e}fileName{color}{color:#00} =
> {color}{color:#2a00ff}"D:\\citrus[1].jpg"{color}{color:#00};{color}
> {color:#00} FileSystemManager
> {color}{color:#6a3e3e}fsManager{color}{color:#00} =
> VFS.{color}{color:#00}getManager{color}{color:#00}();{color}
> {color:#00} FileObject
> {color}{color:#6a3e3e}fileObject{color}{color:#00} =
> {color}{color:#6a3e3e}fsManager{color}{color:#00}.resolveFile({color}{color:#6a3e3e}fileName{color}{color:#00});{color}
> {color:#00}
> System.{color}{color:#c0}out{color}{color:#00}.println({color}{color:#6a3e3e}fileObject{color}{color:#00}.getPath());{color}
> {color:#00} }{color}{color:#7f0055}catch{color}{color:#00}(Exception
> {color}{color:#6a3e3e}ex{color}{color:#00}) {{color}
> {color:#00}
> {color}{color:#6a3e3e}ex{color}{color:#00}.printStackTrace();{color}
> {color:#00} }{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1638) Add module-info.java into 3.x
[ https://issues.apache.org/jira/browse/MATH-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883432#comment-17883432 ] Gilles Sadowski commented on MATH-1638: --- bq. [...] where is module-info.java in the 4.x version? Good question. It seems (?) auto-generated via [commons-parent|https://github.com/apache/commons-parent/blob/master/pom.xml#L1818]. But I did not test whether it works as expected in a JPMS setup. > Add module-info.java into 3.x > - > > Key: MATH-1638 > URL: https://issues.apache.org/jira/browse/MATH-1638 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Jan Tošovský >Priority: Major > > When Math3 is used as dependency, the parent project can't be processed by > [jlink|https://docs.oracle.com/javase/9/tools/jlink.htm], which rejects > dependencies with automatic module names. > While module-info is already added to 4.x version, this version is not going > to be released soon. > Would it be possible to fix 3.x version and create a new release? > Thanks! > (Math3 is dependency of Apache POI so entire POI cannot be used as dependency > in my project) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1638) Add module-info.java into 3.x
[ https://issues.apache.org/jira/browse/MATH-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883428#comment-17883428 ] Gili commented on MATH-1638: Out of curiosity, where is module-info.java in the 4.x version? While the issue description says it's there, I haven't been able to find it. Thanks in advance. > Add module-info.java into 3.x > - > > Key: MATH-1638 > URL: https://issues.apache.org/jira/browse/MATH-1638 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Jan Tošovský >Priority: Major > > When Math3 is used as dependency, the parent project can't be processed by > [jlink|https://docs.oracle.com/javase/9/tools/jlink.htm], which rejects > dependencies with automatic module names. > While module-info is already added to 4.x version, this version is not going > to be released soon. > Would it be possible to fix 3.x version and create a new release? > Thanks! > (Math3 is dependency of Apache POI so entire POI cannot be used as dependency > in my project) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (VFS-840) IllegalArgumentException when using special characters in filename eg [ or ] and calling FileObject.getPath method
[
https://issues.apache.org/jira/browse/VFS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883403#comment-17883403
]
Matthew Bellew edited comment on VFS-840 at 9/20/24 8:26 PM:
-
I've just hit this, in trying to sort this out I discovered various JDK and VFS
inconsistencies (alluded to above). In trying to make the simplest repro I
found 5 chars that are poison to LocalFIle.getPath(). They are ?[]{}
This is a challenge for adopting VFS because I'd have to somehow enforce that
across the entire codebase no one uses FileObject.getPath() and always use
FileObject.getName().
{quote}java.util.List bad = java.util.Arrays.asList(
"file:///%3F", // /? this fails differently than the others
(getURI() is OK)
"file:///%5B", // /[
"file:///%5D", // /]
"file:///%7B", // /}
);
for (String uriString : bad)
{
// TRY ENCODED
out.println(uriString);
try
\{ FileObject fo = VFS.getManager().resolveFile(uriString);
fo.getName().getPathDecoded(); fo.getURI(); fo.getPath(); }
catch (Exception x)
\{ out.println(x.getClass().getName() + " " + x.getMessage()); }
// TRY DECODED
out.println(URI.create(uriString).getPath());
try
\{ FileObject fo =
VFS.getManager().resolveFile(URI.create(uriString).getPath());
fo.getName().getPathDecoded(); fo.getURI(); fo.getPath(); }
catch (Exception x)
\{ out.println(x.getClass().getName() + " " + x.getMessage());
}{quote}
was (Author: mbellew):
I've just hit this, in trying to sort this out I discovered various JDK and VFS
inconsistencies (alluded to above). In trying to make the simplest repro I
found 5 chars that are poison to LocalFIle.getPath(). They are ?[]{}
This is a challenge for adopting VFS because I'd have to somehow enforce that
across the entire codebase no one uses FileObject.getPath() and always use
FileObject.getName().
{quote}java.util.List bad = java.util.Arrays.asList(
"file:///%3F", // /? this fails differently than the others
(getURI() is OK)
"file:///%5B", // /[
"file:///%5D", // /]
"file:///%7B", // /{
"file:///%7D" // /}
);
for (String uriString : bad)
{
// TRY ENCODED
out.println(uriString);
try
{
FileObject fo = VFS.getManager().resolveFile(uriString);
fo.getName().getPathDecoded();
fo.getURI();
fo.getPath();
}
catch (Exception x)
{
out.println(x.getClass().getName() + " " + x.getMessage());
}
// TRY DECODED
out.println(URI.create(uriString).getPath());
try
{
FileObject fo =
VFS.getManager().resolveFile(URI.create(uriString).getPath());
fo.getName().getPathDecoded();
fo.getURI();
fo.getPath();
}
catch (Exception x)
{
out.println(x.getClass().getName() + " " + x.getMessage());
}
}
{quote}
> IllegalArgumentException when using special characters in filename eg [ or ]
> and calling FileObject.getPath method
> --
>
> Key: VFS-840
> URL: https://issues.apache.org/jira/browse/VFS-840
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10
> Java 17
> Apache VFS 2.9.0
>Reporter: Usman Ashraf Bajwah
>Priority: Major
>
> When special characters ([ or ] for example there might be others also) are
> used in filename FileObject resolve it alright but calling its getPath method
> fails with following exception.
>
> +java.lang.IllegalArgumentException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:906+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getURI({color}+FileObject.java:310+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getPath({color}+FileObject.java:320+{color:#ff}){color}
> {color:#ff} at
> com.gallerysystems.tms.common.util.FileUtil.main({color}+FileUtil.java:859+{color:#ff}){color}
> {color:#ff}Caused by:
> {color}+java.net.URISyntaxException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI$Parser.fail({color}+URI.java:2974+{color:#ff}){color}
> {color:#ff
[jira] [Comment Edited] (VFS-840) IllegalArgumentException when using special characters in filename eg [ or ] and calling FileObject.getPath method
[
https://issues.apache.org/jira/browse/VFS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883403#comment-17883403
]
Matthew Bellew edited comment on VFS-840 at 9/20/24 8:24 PM:
-
I've just hit this, in trying to sort this out I discovered various JDK and VFS
inconsistencies (alluded to above). In trying to make the simplest repro I
found 5 chars that are poison to LocalFIle.getPath(). They are ?[]{}
This is a challenge for adopting VFS because I'd have to somehow enforce that
across the entire codebase no one uses FileObject.getPath() and always use
FileObject.getName().
{quote}java.util.List bad = java.util.Arrays.asList(
"file:///%3F", // /? this fails differently than the others
(getURI() is OK)
"file:///%5B", // /[
"file:///%5D", // /]
"file:///%7B", // /{
"file:///%7D" // /}
);
for (String uriString : bad)
{
// TRY ENCODED
out.println(uriString);
try
{
FileObject fo = VFS.getManager().resolveFile(uriString);
fo.getName().getPathDecoded();
fo.getURI();
fo.getPath();
}
catch (Exception x)
{
out.println(x.getClass().getName() + " " + x.getMessage());
}
// TRY DECODED
out.println(URI.create(uriString).getPath());
try
{
FileObject fo =
VFS.getManager().resolveFile(URI.create(uriString).getPath());
fo.getName().getPathDecoded();
fo.getURI();
fo.getPath();
}
catch (Exception x)
{
out.println(x.getClass().getName() + " " + x.getMessage());
}
}
{quote}
was (Author: mbellew):
I've just hit this, in trying to sort this out I discovered various JDK and VFS
inconsistencies (alluded to above). In trying to make the simplest repro I
found 5 chars that are poison to LocalFIle.getPath(). They are ?[]{}
This is a challenge for adopting VFS because I'd have to somehow enforce that
across the entire codebase no one uses FileObject.getPath() and always use
FileObject.getName().
{quote}java.util.List bad = java.util.Arrays.asList(
"file:///%3F", // /? this fails differently than the others
(getURI() is OK)
"file:///%5B", // /[
"file:///%5D", // /]
"file:///%7B", // /{
"file:///%7D" // /}
);
for (String uriString : bad)
{
// TRY ENCODED
out.println(uriString);
try
{
FileObject fo = VFS.getManager().resolveFile(uriString);
fo.getName().getPathDecoded();
fo.getURI();
fo.getPath();
}
catch (Exception x)
{
out.println(x.getClass().getName() + " " + x.getMessage());
}
// TRY DECODED
out.println(URI.create(uriString).getPath());
try
{
FileObject fo =
VFS.getManager().resolveFile(URI.create(uriString).getPath());
fo.getName().getPathDecoded();
fo.getURI();
fo.getPath();
}
catch (Exception x)
{
out.println(x.getClass().getName() + " " + x.getMessage());
}
}
{quote}
> IllegalArgumentException when using special characters in filename eg [ or ]
> and calling FileObject.getPath method
> --
>
> Key: VFS-840
> URL: https://issues.apache.org/jira/browse/VFS-840
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10
> Java 17
> Apache VFS 2.9.0
>Reporter: Usman Ashraf Bajwah
>Priority: Major
>
> When special characters ([ or ] for example there might be others also) are
> used in filename FileObject resolve it alright but calling its getPath method
> fails with following exception.
>
> +java.lang.IllegalArgumentException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:906+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getURI({color}+FileObject.java:310+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getPath({color}+FileObject.java:320+{color:#ff}){color}
> {color:#ff} at
> com.gallerysystems.tms.common.util.FileUtil.main({color}+FileUtil.java:859+{color:#ff}){color}
> {color:#ff}Caused by:
> {color}+java.net.URISyntaxException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI$Parser.fail({color}+URI.java:2974+{color:#ff}){col
[jira] [Commented] (VFS-840) IllegalArgumentException when using special characters in filename eg [ or ] and calling FileObject.getPath method
[
https://issues.apache.org/jira/browse/VFS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883403#comment-17883403
]
Matthew Bellew commented on VFS-840:
I've just hit this, in trying to sort this out I discovered various JDK and VFS
inconsistencies (alluded to above). In trying to make the simplest repro I
found 5 chars that are poison to LocalFIle.getPath(). They are ?[]{}
This is a challenge for adopting VFS because I'd have to somehow enforce that
across the entire codebase no one uses FileObject.getPath() and always use
FileObject.getName().
{quote}java.util.List bad = java.util.Arrays.asList(
"file:///%3F", // /? this fails differently than the others
(getURI() is OK)
"file:///%5B", // /[
"file:///%5D", // /]
"file:///%7B", // /{
"file:///%7D" // /}
);
for (String uriString : bad)
{
// TRY ENCODED
out.println(uriString);
try
{
FileObject fo = VFS.getManager().resolveFile(uriString);
fo.getName().getPathDecoded();
fo.getURI();
fo.getPath();
}
catch (Exception x)
{
out.println(x.getClass().getName() + " " + x.getMessage());
}
// TRY DECODED
out.println(URI.create(uriString).getPath());
try
{
FileObject fo =
VFS.getManager().resolveFile(URI.create(uriString).getPath());
fo.getName().getPathDecoded();
fo.getURI();
fo.getPath();
}
catch (Exception x)
{
out.println(x.getClass().getName() + " " + x.getMessage());
}
}
{quote}
> IllegalArgumentException when using special characters in filename eg [ or ]
> and calling FileObject.getPath method
> --
>
> Key: VFS-840
> URL: https://issues.apache.org/jira/browse/VFS-840
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10
> Java 17
> Apache VFS 2.9.0
>Reporter: Usman Ashraf Bajwah
>Priority: Major
>
> When special characters ([ or ] for example there might be others also) are
> used in filename FileObject resolve it alright but calling its getPath method
> fails with following exception.
>
> +java.lang.IllegalArgumentException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:906+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getURI({color}+FileObject.java:310+{color:#ff}){color}
> {color:#ff} at
> org.apache.commons.vfs2.FileObject.getPath({color}+FileObject.java:320+{color:#ff}){color}
> {color:#ff} at
> com.gallerysystems.tms.common.util.FileUtil.main({color}+FileUtil.java:859+{color:#ff}){color}
> {color:#ff}Caused by:
> {color}+java.net.URISyntaxException+{color:#ff}: Illegal character in
> path at index 17: file:///D:/citrus[1].jpg{color}
> {color:#ff} at
> java.base/java.net.URI$Parser.fail({color}+URI.java:2974+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.checkChars({color}+URI.java:3145+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parseHierarchical({color}+URI.java:3227+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI$Parser.parse({color}+URI.java:3175+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.({color}+URI.java:623+{color:#ff}){color}
> {color:#ff} at
> java.base/java.net.URI.create({color}+URI.java:904+{color:#ff}){color}
> {color:#ff} ... 3 more{color}
>
> Following is the code to reproduce the issue.
> {color:#7f0055}try{color}{color:#00} {{color}
> {color:#00} String {color}{color:#6a3e3e}fileName{color}{color:#00} =
> {color}{color:#2a00ff}"D:\\citrus[1].jpg"{color}{color:#00};{color}
> {color:#00} FileSystemManager
> {color}{color:#6a3e3e}fsManager{color}{color:#00} =
> VFS.{color}{color:#00}getManager{color}{color:#00}();{color}
> {color:#00} FileObject
> {color}{color:#6a3e3e}fileObject{color}{color:#00} =
> {color}{color:#6a3e3e}fsManager{color}{color:#00}.resolveFile({color}{color:#6a3e3e}fileName{color}{color:#00});{color}
> {color:#00}
> System.{color}{color:#c0}out{color}{color:#00}.println({color}{color:#6a3e3e}fileObject{color}{color:#00}.getPath());{color}
> {color:#00} }{color}{color:#7f0055}catch{color}{color:#00}(Exception
> {color}{color:#6a3e3e}ex{color}{color:#00}) {{color}
> {color:#00}
> {color}{color:#6a3e3e}ex{color}{color:#00}.printStackTrace();{color}
> {color:#00} }{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CSV-289) Memory usage
[ https://issues.apache.org/jira/browse/CSV-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CSV-289. - Resolution: Information Provided > Memory usage > > > Key: CSV-289 > URL: https://issues.apache.org/jira/browse/CSV-289 > Project: Commons CSV > Issue Type: Improvement >Reporter: Pruteanu Dragos >Priority: Major > > I intend to use the CSV parser to parse text lines from a file, separate ( > not in a row ). This is intended for an editor for large CSV files, where > only the visible lines are parsed. > Is it possible to somehow parse only a line of text, without initializing the > parser each time? I ask this in order to reduce the number of created objects > in Java. > Like for example > ``` > CSVParser parser = new CSVParser(); > parser.parse(line1); > parser.reset(); > parser.parse(line2); > `` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CSV-289) Memory usage
[ https://issues.apache.org/jira/browse/CSV-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495012#comment-17495012 ] Gary D. Gregory edited comment on CSV-289 at 9/19/24 7:06 PM: -- When you parse a file, it is consumed one record at a time. If you have an issue, report it here or on the user's mailing list. was (Author: garydgregory): Please post to the user's mailing list. > Memory usage > > > Key: CSV-289 > URL: https://issues.apache.org/jira/browse/CSV-289 > Project: Commons CSV > Issue Type: Improvement >Reporter: Pruteanu Dragos >Priority: Major > > I intend to use the CSV parser to parse text lines from a file, separate ( > not in a row ). This is intended for an editor for large CSV files, where > only the visible lines are parsed. > Is it possible to somehow parse only a line of text, without initializing the > parser each time? I ask this in order to reduce the number of created objects > in Java. > Like for example > ``` > CSVParser parser = new CSVParser(); > parser.parse(line1); > parser.reset(); > parser.parse(line2); > `` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IO-555) Add a FileSystem enum to provide legal file names
[
https://issues.apache.org/jira/browse/IO-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-555:
---
Fix Version/s: 2.17.1
(was: 2.17.0)
> Add a FileSystem enum to provide legal file names
> -
>
> Key: IO-555
> URL: https://issues.apache.org/jira/browse/IO-555
> Project: Commons IO
> Issue Type: Improvement
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.1
>
>
> Add {{org.apache.commons.io.FilenameUtils.isIllegalWindowsFileName(char)}}.
> {code:java}
> /**
> * Checks whether the given character is illegal in a Windows file names.
> *
> * The illegal character are:
> *
> *
> * < (less than
> * > (greater than
> * : (colon
> * " (double quote
> * / (forward slash
> * \ (backslash
> * | (vertical bar or pipe
> * ? (question mark
> * * (asterisk
> * ASCII NUL (0)
> * Integer characters 1 through 31
> * There may be other characters that the file name does not allow.
> Please see
> * href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx">Naming
> Files, Paths,
> * and Namespaces
> *
> *
> * @see href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx">Naming
> Files,
> * Paths, and Namespaces
> * @param c
> *the character to check
> * @return whether the give character is legal
> * @since 2.7
> */
> {code}
> I use this method as a building block to create file names based on Strings
> from other sources.
> A further contribution could be: {{String toLegalWindowsFileName(String
> input, char replacementChar)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IO-840) Review ChecksumInputStream
[ https://issues.apache.org/jira/browse/IO-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-840: --- Fix Version/s: 2.17.1 (was: 2.17.0) > Review ChecksumInputStream > -- > > Key: IO-840 > URL: https://issues.apache.org/jira/browse/IO-840 > Project: Commons IO > Issue Type: Task >Reporter: Elliotte Rusty Harold >Priority: Major > Fix For: 2.17.1 > > > This was added to the public API without full discussion. It has a single use > case in commons compress from where it originates, but it doesn't add a lot > to CheckedInputStream. > Discuss and consider whether this meets the bar for commons-io public API. > Keep or remove as decided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CLI-338) Replace StringBuffer with Appendable in the Help system
Claude Warren created CLI-338: - Summary: Replace StringBuffer with Appendable in the Help system Key: CLI-338 URL: https://issues.apache.org/jira/browse/CLI-338 Project: Commons CLI Issue Type: Improvement Components: Help formatter Affects Versions: 1.9.0 Reporter: Claude Warren There was a partial change from StringBuffer to Appendable in 1.9.0 this is to complete that transition. There are a number of protected methods in HelpFormatter that explicitly use StringBuffer. This change is to migrate those to Appendable. This may require deprecation with replacement of some methods. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CLI-337) Parse arguments in a single string
[ https://issues.apache.org/jira/browse/CLI-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882627#comment-17882627 ] Claude Warren edited comment on CLI-337 at 9/18/24 8:44 AM: This seems a bit beyond the functionality of CLI. CLI expects Options and Args. There are a number of issues that come to mind with parsing args from a string. I believe those issues are best resolved by the calling program. A quick search shows that there is a solution in the Apache Ant project: [Commandline|http://api.dpml.net/ant/1.6.4/org/apache/tools/ant/types/Commandline.html] was (Author: claudenw): This seems a bit beyond the functionality of CLI. CLI expects Options and Args. There are a number of issues that come to mind with parsing args from a string. I believe those issues are best resolved by the calling program. > Parse arguments in a single string > -- > > Key: CLI-337 > URL: https://issues.apache.org/jira/browse/CLI-337 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.9.0 >Reporter: Hüseyin Kartal >Priority: Major > > Apache Maven uses apache-cli to parse args. But maven also supports passing > conf file which contains these args. To handle that they do the splitting of > file content to args[] and pass this to cli. > Please provide a parser for single string to args[] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CLI-337) Parse arguments in a single string
[ https://issues.apache.org/jira/browse/CLI-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882627#comment-17882627 ] Claude Warren commented on CLI-337: --- This seems a bit beyond the functionality of CLI. CLI expects Options and Args. There are a number of issues that come to mind with parsing args from a string. I believe those issues are best resolved by the calling program. > Parse arguments in a single string > -- > > Key: CLI-337 > URL: https://issues.apache.org/jira/browse/CLI-337 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.9.0 >Reporter: Hüseyin Kartal >Priority: Major > > Apache Maven uses apache-cli to parse args. But maven also supports passing > conf file which contains these args. To handle that they do the splitting of > file content to args[] and pass this to cli. > Please provide a parser for single string to args[] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (BEANUTILS-570) Vulnerability in commons-beanutils 1.9.4
[ https://issues.apache.org/jira/browse/BEANUTILS-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882509#comment-17882509 ] Chirag Shah commented on BEANUTILS-570: --- [~ggregory] [~ggregory] [~ggregory1] > Vulnerability in commons-beanutils 1.9.4 > > > Key: BEANUTILS-570 > URL: https://issues.apache.org/jira/browse/BEANUTILS-570 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean-Collections >Affects Versions: 1.9.4 >Reporter: Chirag Shah >Priority: Major > Fix For: 2.0.0 > > > Commons BeanUtils uses Common Collection 3.3.2 library which has the > vulnerability identified to it. The required fix requires to upgrade > common-collection to 4.4 or above version. Common-BeanUtils 2.0.0 is already > available but not release generally. Need help to release that library. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (BEANUTILS-570) Vulnerability in commons-beanutils 1.9.4
Chirag Shah created BEANUTILS-570: - Summary: Vulnerability in commons-beanutils 1.9.4 Key: BEANUTILS-570 URL: https://issues.apache.org/jira/browse/BEANUTILS-570 Project: Commons BeanUtils Issue Type: Bug Components: Bean-Collections Affects Versions: 1.9.4 Reporter: Chirag Shah Fix For: 2.0.0 Commons BeanUtils uses Common Collection 3.3.2 library which has the vulnerability identified to it. The required fix requires to upgrade common-collection to 4.4 or above version. Common-BeanUtils 2.0.0 is already available but not release generally. Need help to release that library. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (COMPRESS-687) Pack200CompressorInputStream unexpected process finished on Java 22
[
https://issues.apache.org/jira/browse/COMPRESS-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved COMPRESS-687.
--
Resolution: Cannot Reproduce
> Pack200CompressorInputStream unexpected process finished on Java 22
> ---
>
> Key: COMPRESS-687
> URL: https://issues.apache.org/jira/browse/COMPRESS-687
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.27.1
>Reporter: Alexis Jehan
>Priority: Major
> Attachments: test-issue.7z
>
>
> Hello,
> Consider the following class:
> {code:java}
> public final class Foo {
> public static void main(final String... args) throws IOException {
> System.out.println("start");
> try (var inputStream =
> Foo.class.getClassLoader().getResourceAsStream("foo.pack")) {
> try (var compressInputStream = new
> Pack200CompressorInputStream(inputStream)) {
> compressInputStream.transferTo(System.out);
> }
> }
> System.out.println("end"); // never reached
> }
> }
> {code}
> Running it using Java 22, and the `--add-opens=java.base/java.io=ALL-UNNAMED`
> VM option, the result is:
> {noformat}
> start
> Process finished with exit code 0
> {noformat}
> The process is interrupted without any error.
> I have attached files.
> Thank you in advance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (COMPRESS-687) Pack200CompressorInputStream unexpected process finished on Java 22
[
https://issues.apache.org/jira/browse/COMPRESS-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881858#comment-17881858
]
Gary D. Gregory edited comment on COMPRESS-687 at 9/15/24 3:18 PM:
---
I added a new test to git master
{{org.apache.commons.compress.compressors.pack200.Compress687Test}} which
passes locally for me on macOS 23.6.0 Darwin Kernel Version 23.6.0 using Java 8
and 22.
The tests also pass on GitHub on macOS, Windows, Ubuntu using Java 8, 11, 17,
21, 22.
The issue must be on your end unless you can provide a failing unit test.
was (Author: garydgregory):
I added a new test
{{org.apache.commons.compress.compressors.pack200.Compress687Test}} which
passes locally for me on macOS 23.6.0 Darwin Kernel Version 23.6.0 using Java 8
and 22.
The tests also pass on GitHub on macOS, Windows, Ubuntu using Java 8, 11, 17,
21, 22.
The issue must be on your end unless you can provide a failing unit test.
> Pack200CompressorInputStream unexpected process finished on Java 22
> ---
>
> Key: COMPRESS-687
> URL: https://issues.apache.org/jira/browse/COMPRESS-687
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.27.1
>Reporter: Alexis Jehan
>Priority: Major
> Attachments: test-issue.7z
>
>
> Hello,
> Consider the following class:
> {code:java}
> public final class Foo {
> public static void main(final String... args) throws IOException {
> System.out.println("start");
> try (var inputStream =
> Foo.class.getClassLoader().getResourceAsStream("foo.pack")) {
> try (var compressInputStream = new
> Pack200CompressorInputStream(inputStream)) {
> compressInputStream.transferTo(System.out);
> }
> }
> System.out.println("end"); // never reached
> }
> }
> {code}
> Running it using Java 22, and the `--add-opens=java.base/java.io=ALL-UNNAMED`
> VM option, the result is:
> {noformat}
> start
> Process finished with exit code 0
> {noformat}
> The process is interrupted without any error.
> I have attached files.
> Thank you in advance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COMPRESS-687) Pack200CompressorInputStream unexpected process finished on Java 22
[
https://issues.apache.org/jira/browse/COMPRESS-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881858#comment-17881858
]
Gary D. Gregory commented on COMPRESS-687:
--
I added a new test
{{org.apache.commons.compress.compressors.pack200.Compress687Test}} which
passes locally for me on macOS 23.6.0 Darwin Kernel Version 23.6.0 using Java 8
and 22.
The tests also pass on GitHub on macOS, Windows, Ubuntu using Java 8, 11, 17,
21, 22.
The issue must be on your end unless you can provide a failing unit test.
> Pack200CompressorInputStream unexpected process finished on Java 22
> ---
>
> Key: COMPRESS-687
> URL: https://issues.apache.org/jira/browse/COMPRESS-687
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.27.1
>Reporter: Alexis Jehan
>Priority: Major
> Attachments: test-issue.7z
>
>
> Hello,
> Consider the following class:
> {code:java}
> public final class Foo {
> public static void main(final String... args) throws IOException {
> System.out.println("start");
> try (var inputStream =
> Foo.class.getClassLoader().getResourceAsStream("foo.pack")) {
> try (var compressInputStream = new
> Pack200CompressorInputStream(inputStream)) {
> compressInputStream.transferTo(System.out);
> }
> }
> System.out.println("end"); // never reached
> }
> }
> {code}
> Running it using Java 22, and the `--add-opens=java.base/java.io=ALL-UNNAMED`
> VM option, the result is:
> {noformat}
> start
> Process finished with exit code 0
> {noformat}
> The process is interrupted without any error.
> I have attached files.
> Thank you in advance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CSV-150) Escaping is not disableable
[
https://issues.apache.org/jira/browse/CSV-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved CSV-150.
-
Resolution: Fixed
In git master and snapshot builds
[https://repository.apache.org/content/repositories/snapshots/]
> Escaping is not disableable
> ---
>
> Key: CSV-150
> URL: https://issues.apache.org/jira/browse/CSV-150
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.1
>Reporter: Georg Tsakumagos
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: CSV-150.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h6. Problem
> If escaping is disabled the Lexer maps the NULL Character to the magic char
> '\ufffe'. I currently hit this char randomly with data. This leads to a
> RuntimeException inside of
> org.apache.commons.csv.Lexer.parseEncapsulatedToken(Token) with the message
> "invalid char between encapsulated token and delimiter".
> h6. Solution
> Don't map the Character object and use it.
> {code:title=Lexer.java|borderStyle=solid}
> Lexer(final CSVFormat format, final ExtendedBufferedReader reader) {
> this.reader = reader;
> this.delimiter = format.getDelimiter();
> this.escape = format.getEscapeCharacter();
> .
> .
> .
> }
> boolean isEscape(final int ch) {
> return null != this.escape && escape.charValue() == ch;
> }
> {code}
> h6. Hint
> This pattern is used in other cases to. It seem to be a systematic error.
> This cases should be refactored also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881807#comment-17881807
]
Saif Asif commented on LANG-1752:
-
Thanks for the response [~ggregory] and also linking the discussion. I wanted
to get an idea what other ideas may be floating around, fully agree my proposed
implementation may not be the best approach. So as I understand, we would be
moving APIs to this new Strings class and maybe deprecate usage of the utility
class StringUtils ?
I have some time in my hands and would be willing to work on this.
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Saif Asif
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (CSV-150) Escaping is not disableable
[ https://issues.apache.org/jira/browse/CSV-150 ]
Gary D. Gregory deleted comment on CSV-150:
-
was (Author: garydgregory):
Fixed in git master, see JiraCsv150Test.
> Escaping is not disableable
> ---
>
> Key: CSV-150
> URL: https://issues.apache.org/jira/browse/CSV-150
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.1
>Reporter: Georg Tsakumagos
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: CSV-150.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h6. Problem
> If escaping is disabled the Lexer maps the NULL Character to the magic char
> '\ufffe'. I currently hit this char randomly with data. This leads to a
> RuntimeException inside of
> org.apache.commons.csv.Lexer.parseEncapsulatedToken(Token) with the message
> "invalid char between encapsulated token and delimiter".
> h6. Solution
> Don't map the Character object and use it.
> {code:title=Lexer.java|borderStyle=solid}
> Lexer(final CSVFormat format, final ExtendedBufferedReader reader) {
> this.reader = reader;
> this.delimiter = format.getDelimiter();
> this.escape = format.getEscapeCharacter();
> .
> .
> .
> }
> boolean isEscape(final int ch) {
> return null != this.escape && escape.charValue() == ch;
> }
> {code}
> h6. Hint
> This pattern is used in other cases to. It seem to be a systematic error.
> This cases should be refactored also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CSV-150) Escaping is not disableable
[
https://issues.apache.org/jira/browse/CSV-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated CSV-150:
Assignee: Gary D. Gregory
> Escaping is not disableable
> ---
>
> Key: CSV-150
> URL: https://issues.apache.org/jira/browse/CSV-150
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.1
>Reporter: Georg Tsakumagos
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: CSV-150.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h6. Problem
> If escaping is disabled the Lexer maps the NULL Character to the magic char
> '\ufffe'. I currently hit this char randomly with data. This leads to a
> RuntimeException inside of
> org.apache.commons.csv.Lexer.parseEncapsulatedToken(Token) with the message
> "invalid char between encapsulated token and delimiter".
> h6. Solution
> Don't map the Character object and use it.
> {code:title=Lexer.java|borderStyle=solid}
> Lexer(final CSVFormat format, final ExtendedBufferedReader reader) {
> this.reader = reader;
> this.delimiter = format.getDelimiter();
> this.escape = format.getEscapeCharacter();
> .
> .
> .
> }
> boolean isEscape(final int ch) {
> return null != this.escape && escape.charValue() == ch;
> }
> {code}
> h6. Hint
> This pattern is used in other cases to. It seem to be a systematic error.
> This cases should be refactored also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (CSV-150) Escaping is not disableable
[
https://issues.apache.org/jira/browse/CSV-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory reopened CSV-150:
-
> Escaping is not disableable
> ---
>
> Key: CSV-150
> URL: https://issues.apache.org/jira/browse/CSV-150
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.1
>Reporter: Georg Tsakumagos
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: CSV-150.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h6. Problem
> If escaping is disabled the Lexer maps the NULL Character to the magic char
> '\ufffe'. I currently hit this char randomly with data. This leads to a
> RuntimeException inside of
> org.apache.commons.csv.Lexer.parseEncapsulatedToken(Token) with the message
> "invalid char between encapsulated token and delimiter".
> h6. Solution
> Don't map the Character object and use it.
> {code:title=Lexer.java|borderStyle=solid}
> Lexer(final CSVFormat format, final ExtendedBufferedReader reader) {
> this.reader = reader;
> this.delimiter = format.getDelimiter();
> this.escape = format.getEscapeCharacter();
> .
> .
> .
> }
> boolean isEscape(final int ch) {
> return null != this.escape && escape.charValue() == ch;
> }
> {code}
> h6. Hint
> This pattern is used in other cases to. It seem to be a systematic error.
> This cases should be refactored also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CSV-150) Escaping is not disableable
[
https://issues.apache.org/jira/browse/CSV-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881801#comment-17881801
]
Gary D. Gregory commented on CSV-150:
-
Fixed in git master, see JiraCsv150Test.
> Escaping is not disableable
> ---
>
> Key: CSV-150
> URL: https://issues.apache.org/jira/browse/CSV-150
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.1
>Reporter: Georg Tsakumagos
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: CSV-150.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h6. Problem
> If escaping is disabled the Lexer maps the NULL Character to the magic char
> '\ufffe'. I currently hit this char randomly with data. This leads to a
> RuntimeException inside of
> org.apache.commons.csv.Lexer.parseEncapsulatedToken(Token) with the message
> "invalid char between encapsulated token and delimiter".
> h6. Solution
> Don't map the Character object and use it.
> {code:title=Lexer.java|borderStyle=solid}
> Lexer(final CSVFormat format, final ExtendedBufferedReader reader) {
> this.reader = reader;
> this.delimiter = format.getDelimiter();
> this.escape = format.getEscapeCharacter();
> .
> .
> .
> }
> boolean isEscape(final int ch) {
> return null != this.escape && escape.charValue() == ch;
> }
> {code}
> h6. Hint
> This pattern is used in other cases to. It seem to be a systematic error.
> This cases should be refactored also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CSV-150) Escaping is not disableable
[
https://issues.apache.org/jira/browse/CSV-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved CSV-150.
-
Fix Version/s: 1.12.0
(was: Review)
Resolution: Fixed
> Escaping is not disableable
> ---
>
> Key: CSV-150
> URL: https://issues.apache.org/jira/browse/CSV-150
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.1
>Reporter: Georg Tsakumagos
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: CSV-150.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h6. Problem
> If escaping is disabled the Lexer maps the NULL Character to the magic char
> '\ufffe'. I currently hit this char randomly with data. This leads to a
> RuntimeException inside of
> org.apache.commons.csv.Lexer.parseEncapsulatedToken(Token) with the message
> "invalid char between encapsulated token and delimiter".
> h6. Solution
> Don't map the Character object and use it.
> {code:title=Lexer.java|borderStyle=solid}
> Lexer(final CSVFormat format, final ExtendedBufferedReader reader) {
> this.reader = reader;
> this.delimiter = format.getDelimiter();
> this.escape = format.getEscapeCharacter();
> .
> .
> .
> }
> boolean isEscape(final int ch) {
> return null != this.escape && escape.charValue() == ch;
> }
> {code}
> h6. Hint
> This pattern is used in other cases to. It seem to be a systematic error.
> This cases should be refactored also.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CSV-270) Throw a different Expeciton type on malformed CSV input
[
https://issues.apache.org/jira/browse/CSV-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved CSV-270.
-
Fix Version/s: 1.11.1
Resolution: Fixed
> Throw a different Expeciton type on malformed CSV input
> ---
>
> Key: CSV-270
> URL: https://issues.apache.org/jira/browse/CSV-270
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.8
>Reporter: Thomas Kamps
>Priority: Minor
> Fix For: 1.11.1
>
> Attachments: malformed_format.csv
>
>
> In our application we support to read CSV files with a custom definable
> format. The problem is now, that a suer could give a CSV file, which doies
> not match the defined pattern, the CSVParser throws an IOException. This
> exception type could also be throws, if the reading of the itself fails.
> Wed like to have a simple distiction beween IO errors and file content errors.
> We could parse the IOException's message, but those messages could change and
> we have to know about all kinds of content errors in advance.
>
> So my suggestion is to throw a specialied exception, when malformed content
> is detected during parsing. So we could distinguish between thsoe two kind of
> errors very easily:
> {code:java}
> try (
> final CSVParser csvParser = new CSVParser(
> new FileReader(soneFile, encoding),
> csvFormat
> )
> ) {
> csvParser.getRecords();
> }
> catch (IOException e) {
> //File cannot be read for some reason
> }
> catch (MalformedCSVException e) {
> //CSV content is malformed compared to given CSVFormat
> }
> {code}
> Currently we wold have to get the message from the IOExcpetion and check its
> pattern to get the problem.
>
> Here is a simple example how to get an IOException that occurs, when the
> files content does not match the given CSVFormat:
> {code:java}
> try (
> final CSVParser csvParser = new CSVParser(
> new FileReader("path/to/malformed_format.csv",
> StandardCharsets.UTF_8),
> CSVFormat.DEFAULT
> )
> ) {
> csvParser.getRecords();
> }
> catch (IOException e) {
> e.printStackTrace();
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CSV-270) Throw a different Expeciton type on malformed CSV input
[
https://issues.apache.org/jira/browse/CSV-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated CSV-270:
Summary: Throw a different Expeciton type on malformed CSV input (was:
Throw a different Expeciton type on malformed CSV files)
> Throw a different Expeciton type on malformed CSV input
> ---
>
> Key: CSV-270
> URL: https://issues.apache.org/jira/browse/CSV-270
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.8
>Reporter: Thomas Kamps
>Priority: Minor
> Attachments: malformed_format.csv
>
>
> In our application we support to read CSV files with a custom definable
> format. The problem is now, that a suer could give a CSV file, which doies
> not match the defined pattern, the CSVParser throws an IOException. This
> exception type could also be throws, if the reading of the itself fails.
> Wed like to have a simple distiction beween IO errors and file content errors.
> We could parse the IOException's message, but those messages could change and
> we have to know about all kinds of content errors in advance.
>
> So my suggestion is to throw a specialied exception, when malformed content
> is detected during parsing. So we could distinguish between thsoe two kind of
> errors very easily:
> {code:java}
> try (
> final CSVParser csvParser = new CSVParser(
> new FileReader(soneFile, encoding),
> csvFormat
> )
> ) {
> csvParser.getRecords();
> }
> catch (IOException e) {
> //File cannot be read for some reason
> }
> catch (MalformedCSVException e) {
> //CSV content is malformed compared to given CSVFormat
> }
> {code}
> Currently we wold have to get the message from the IOExcpetion and check its
> pattern to get the problem.
>
> Here is a simple example how to get an IOException that occurs, when the
> files content does not match the given CSVFormat:
> {code:java}
> try (
> final CSVParser csvParser = new CSVParser(
> new FileReader("path/to/malformed_format.csv",
> StandardCharsets.UTF_8),
> CSVFormat.DEFAULT
> )
> ) {
> csvParser.getRecords();
> }
> catch (IOException e) {
> e.printStackTrace();
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CSV-270) Throw a different Expeciton type on malformed CSV files
[
https://issues.apache.org/jira/browse/CSV-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated CSV-270:
Summary: Throw a different Expeciton type on malformed CSV files (was:
Different Expeciton type on malformed csv files)
> Throw a different Expeciton type on malformed CSV files
> ---
>
> Key: CSV-270
> URL: https://issues.apache.org/jira/browse/CSV-270
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.8
>Reporter: Thomas Kamps
>Priority: Minor
> Attachments: malformed_format.csv
>
>
> In our application we support to read CSV files with a custom definable
> format. The problem is now, that a suer could give a CSV file, which doies
> not match the defined pattern, the CSVParser throws an IOException. This
> exception type could also be throws, if the reading of the itself fails.
> Wed like to have a simple distiction beween IO errors and file content errors.
> We could parse the IOException's message, but those messages could change and
> we have to know about all kinds of content errors in advance.
>
> So my suggestion is to throw a specialied exception, when malformed content
> is detected during parsing. So we could distinguish between thsoe two kind of
> errors very easily:
> {code:java}
> try (
> final CSVParser csvParser = new CSVParser(
> new FileReader(soneFile, encoding),
> csvFormat
> )
> ) {
> csvParser.getRecords();
> }
> catch (IOException e) {
> //File cannot be read for some reason
> }
> catch (MalformedCSVException e) {
> //CSV content is malformed compared to given CSVFormat
> }
> {code}
> Currently we wold have to get the message from the IOExcpetion and check its
> pattern to get the problem.
>
> Here is a simple example how to get an IOException that occurs, when the
> files content does not match the given CSVFormat:
> {code:java}
> try (
> final CSVParser csvParser = new CSVParser(
> new FileReader("path/to/malformed_format.csv",
> StandardCharsets.UTF_8),
> CSVFormat.DEFAULT
> )
> ) {
> csvParser.getRecords();
> }
> catch (IOException e) {
> e.printStackTrace();
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CSV-270) Different Expeciton type on malformed csv files
[
https://issues.apache.org/jira/browse/CSV-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881794#comment-17881794
]
Gary D. Gregory commented on CSV-270:
-
Having a subclass of IOException for a formatting error seems OK to me, Java
does it all over the place:
* java.io.UTFDataFormatException
* java.io.CharConversionException
* java.nio.charset.MalformedInputException
* java.util.InvalidPropertiesFormatException
* on and on and on...
> Different Expeciton type on malformed csv files
> ---
>
> Key: CSV-270
> URL: https://issues.apache.org/jira/browse/CSV-270
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.8
>Reporter: Thomas Kamps
>Priority: Minor
> Attachments: malformed_format.csv
>
>
> In our application we support to read CSV files with a custom definable
> format. The problem is now, that a suer could give a CSV file, which doies
> not match the defined pattern, the CSVParser throws an IOException. This
> exception type could also be throws, if the reading of the itself fails.
> Wed like to have a simple distiction beween IO errors and file content errors.
> We could parse the IOException's message, but those messages could change and
> we have to know about all kinds of content errors in advance.
>
> So my suggestion is to throw a specialied exception, when malformed content
> is detected during parsing. So we could distinguish between thsoe two kind of
> errors very easily:
> {code:java}
> try (
> final CSVParser csvParser = new CSVParser(
> new FileReader(soneFile, encoding),
> csvFormat
> )
> ) {
> csvParser.getRecords();
> }
> catch (IOException e) {
> //File cannot be read for some reason
> }
> catch (MalformedCSVException e) {
> //CSV content is malformed compared to given CSVFormat
> }
> {code}
> Currently we wold have to get the message from the IOExcpetion and check its
> pattern to get the problem.
>
> Here is a simple example how to get an IOException that occurs, when the
> files content does not match the given CSVFormat:
> {code:java}
> try (
> final CSVParser csvParser = new CSVParser(
> new FileReader("path/to/malformed_format.csv",
> StandardCharsets.UTF_8),
> CSVFormat.DEFAULT
> )
> ) {
> csvParser.getRecords();
> }
> catch (IOException e) {
> e.printStackTrace();
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CSV-272) Support fixed-width format
[
https://issues.apache.org/jira/browse/CSV-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881790#comment-17881790
]
Gary D. Gregory commented on CSV-272:
-
[~holgerbrandl]
You can display fixed-width text in Jira by enclosing it "\{noformat\}" tags:
https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=advanced
> Support fixed-width format
> --
>
> Key: CSV-272
> URL: https://issues.apache.org/jira/browse/CSV-272
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.8
>Reporter: Holger Brandl
>Priority: Major
>
> Although not strictly a delimiter format, fixed-width tables are still very
> common. So it would be great if commons-csv would support fixed-width via a
> dedicated format.
> Since jira does not render fixed-delim content correctly, I've deposited an
> example under
> https://gist.github.com/holgerbrandl/26298ae77d53b3393d9d22c73249ab72
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CSV-294) CSVFormat does not support explicit " as escape char
[
https://issues.apache.org/jira/browse/CSV-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved CSV-294.
-
Fix Version/s: 1.11.1
Resolution: Fixed
I added JiraCsv294Test to git master and it is green, so this has been fixed
since 1.9.0.
> CSVFormat does not support explicit " as escape char
>
>
> Key: CSV-294
> URL: https://issues.apache.org/jira/browse/CSV-294
> Project: Commons CSV
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Joern Huxhorn
>Priority: Major
> Fix For: 1.11.1
>
> Attachments: JiraCsv294Test.java
>
>
> Reading data that contains " does not work if escape character is *manually
> set to {{'"'}}* as specified in [RFC
> 4180|https://datatracker.ietf.org/doc/html/rfc4180].
> *It works for other escape characters or if no escape character is explicitly
> defined in the format.*
> This line in {{Lexer.java}} is responsible for the originally quite erroneous
> ticket:
> {{this.escape = mapNullToDisabled(format.getEscapeCharacter());}}
> From this line I (wrongly) deduced that an unspecified escape character would
> actually disable escaping. Because of that I wanted to enable it by setting
> it to {{'"'}} which causes exceptions in the Lexer for perfectly valid input.
> That in turn convinced my that this is a way bigger issue than it is. Sorry
> about that.
> I don't think that the current situation is ideal, though.
> I would not have been this confused if {{CSVFormat}} would be more explicit
> about the escape char that will be used, i.e. if {{toString()}} would show
> the implicitly used quote character or print - in case of {{null}} - that
> this means it's using the quote character. It is currently omitted from the
> output if it is not set explicitly.
> There is also no documentation about what {{null}} as escape character
> actually means - it may be documented somewhere but isn't documented for
> {{CSVFormat.getEscapeCharacter()}} or {{CSVFormat.Builder.set/getEscape()}}
> methods.
> And setting the escape character explicitly to the value specified in the RFC
> should certainly not fail, even if setting it to that value is superfluous
> since {{null}} behaves exactly the same.
> h4. Relevant part of the RFC:
> 7. If double-quotes are used to enclose fields, then a double-quote
> appearing inside a field must be escaped by preceding it with
> another double quote. For example:
> "aaa","b""bb","ccc"
> h4. Related issue:
> https://issues.apache.org/jira/browse/CSV-150
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CSV-312) CSV Header with multiple lines throughs error
[
https://issues.apache.org/jira/browse/CSV-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881788#comment-17881788
]
Gary D. Gregory commented on CSV-312:
-
Hello [~gautham_arunachalam]
There is no provision for multi-line records, and therefore headers in the CSV
Format you use, RFC4180. Either pick a different format or change the header to
be on one line.
Please specify which version you use in the future.
> CSV Header with multiple lines throughs error
> -
>
> Key: CSV-312
> URL: https://issues.apache.org/jira/browse/CSV-312
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Reporter: Gautham Arunachalam
>Priority: Minor
>
> CSV file header is in multi-line while trying to read the file invalid char
> between encapsulated token and delimiter error is thrown
>
> Sample CSV:
>
> {code:java}
> "SYMBOL
> ","COMPANY
> ","PURPOSE
> ","DETAILS
> ","DATE
> "
> "AURIONPRO","Aurionpro Solutions Limited","Fund Raising","To consider and
> approve the Issue price, including a discount if any","08-Apr-2024"
> "CUPID","Cupid Limited","Financial Results/Other business matters","To
> consider and approve the financial results for the period ended March 31,
> 2024 and other business matters","08-Apr-2024"
> "DPWIRES","D P Wires Limited","Other business matters","To consider other
> business matters","08-Apr-2024" {code}
> Code used to read
>
>
> {code:java}
> Reader in = new FileReader(file);
> Iterable records = CSVFormat.RFC4180.parse(in);
> for (CSVRecord record : records) {
> System.out.println(record.get(0));
> } {code}
> Occurring Error :
> {code:java}
> Exception in thread "main" java.io.UncheckedIOException: IOException reading
> next record: java.io.IOException: (line 2) invalid char between encapsulated
> token and delimiter
> at
> org.apache.commons.csv.CSVParser$CSVRecordIterator.getNextRecord(CSVParser.java:150)
> at
> org.apache.commons.csv.CSVParser$CSVRecordIterator.hasNext(CSVParser.java:160)
> at com.gautham.stockmarket.tools.Main.main(Main.java:21)
> Caused by: java.io.IOException: (line 2) invalid char between encapsulated
> token and delimiter
> at org.apache.commons.csv.Lexer.parseEncapsulatedToken(Lexer.java:369)
> at org.apache.commons.csv.Lexer.nextToken(Lexer.java:290)
> at org.apache.commons.csv.CSVParser.nextRecord(CSVParser.java:770)
> at
> org.apache.commons.csv.CSVParser$CSVRecordIterator.getNextRecord(CSVParser.java:148)
> ... 2 more {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (VALIDATOR-494) provide validator for VATIN
Eugen Hanussek created VALIDATOR-494: Summary: provide validator for VATIN Key: VALIDATOR-494 URL: https://issues.apache.org/jira/browse/VALIDATOR-494 Project: Commons Validator Issue Type: New Feature Components: Routines Reporter: Eugen Hanussek [VAT id number|https://en.wikipedia.org/wiki/VAT_identification_number] is required in the EU intra-Community market. Format and CheckDigit validation are different in each country. Sometimes VATID is equal to TIN (Bulgaria), sometimes there are many formats (Spain). You can check a VATID online with VIES but this redirects a query to national register. Better to use VIES with a pre-validated id. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COMPRESS-687) Pack200CompressorInputStream unexpected process finished on Java 22
Alexis Jehan created COMPRESS-687:
-
Summary: Pack200CompressorInputStream unexpected process finished
on Java 22
Key: COMPRESS-687
URL: https://issues.apache.org/jira/browse/COMPRESS-687
Project: Commons Compress
Issue Type: Bug
Components: Compressors
Affects Versions: 1.27.1
Reporter: Alexis Jehan
Attachments: test-issue.7z
Hello,
Consider the following class:
{code:java}
public final class Foo {
public static void main(final String... args) throws IOException {
System.out.println("start");
try (var inputStream =
Foo.class.getClassLoader().getResourceAsStream("foo.pack")) {
try (var compressInputStream = new
Pack200CompressorInputStream(inputStream)) {
compressInputStream.transferTo(System.out);
}
}
System.out.println("end"); // never reached
}
}
{code}
Running it using Java 22, and the `--add-opens=java.base/java.io=ALL-UNNAMED`
VM option, the result is:
{noformat}
start
Process finished with exit code 0
{noformat}
The process is interrupted without any error.
I have attached files.
Thank you in advance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881337#comment-17881337
]
Gary D. Gregory edited comment on LANG-1752 at 9/12/24 3:00 PM:
Hello [~SaifAsif]
I'm not sure this is the best approach IMO because there is more than one
dimension to the APIs than case-sensitivity. My thinking here is to create a
"Strings" class with defaults for:
- case-sensitivity
- Locale
- Charset
A default instance would be used like:
{code:java}
Strings.DEFAULT.startWith(...)
{code}
and
{code:java}
public static final Strings.MY_UTILS =
Strings.builder().setCaseSenstivity(false).build();
MY_UTILS.startWith(...)
{code}
FYI, this has come up before:
https://lists.apache.org/thread/fb5myt33lprq464wyp98ox5mt2f9ghpm
Whether the actual functionality is implemented in private subclasses is an
implementation detail for now.
Needs discussion...
was (Author: garydgregory):
Hello [~SaifAsif]
I'm not sure this is the best approach IMO because there is more than one
dimension to the APIs than case-sensitivity. My thinking here is to create a
"Strings" class with defaults for:
- case-sensitivity
- Locale
- Charset
A default instance would be used like:
{code:java}
Strings.DEFAULT.startWith(...)
{code}
and
{code:java}
public static final Strings.MY_UTILS =
Strings.builder().setCaseSenstivity(false).build();
MY_UTILS.startWith(...)
{code}
FYI, this has come up before:
https://lists.apache.org/thread/fb5myt33lprq464wyp98ox5mt2f9ghpm
Needs discussion...
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Saif Asif
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881337#comment-17881337
]
Gary D. Gregory commented on LANG-1752:
---
Hello [~SaifAsif]
I'm not sure this is the best approach IMO because there is more than one
dimension to the APIs than case-sensitivity. My thinking here is to create a
"Strings" class with defaults for:
- case-sensitivity
- Locale
- Charset
A default instance would be used like:
{code:java}
Strings.DEFAULT.startWith(...)
{code}
and
{code:java}
public static final Strings.MY_UTILS =
Strings.builder().setCaseSenstivity(false).build();
MY_UTILS.startWith(...)
{code}
FYI, this has come up before:
https://lists.apache.org/thread/fb5myt33lprq464wyp98ox5mt2f9ghpm
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Saif Asif
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881337#comment-17881337
]
Gary D. Gregory edited comment on LANG-1752 at 9/12/24 2:57 PM:
Hello [~SaifAsif]
I'm not sure this is the best approach IMO because there is more than one
dimension to the APIs than case-sensitivity. My thinking here is to create a
"Strings" class with defaults for:
- case-sensitivity
- Locale
- Charset
A default instance would be used like:
{code:java}
Strings.DEFAULT.startWith(...)
{code}
and
{code:java}
public static final Strings.MY_UTILS =
Strings.builder().setCaseSenstivity(false).build();
MY_UTILS.startWith(...)
{code}
FYI, this has come up before:
https://lists.apache.org/thread/fb5myt33lprq464wyp98ox5mt2f9ghpm
Needs discussion...
was (Author: garydgregory):
Hello [~SaifAsif]
I'm not sure this is the best approach IMO because there is more than one
dimension to the APIs than case-sensitivity. My thinking here is to create a
"Strings" class with defaults for:
- case-sensitivity
- Locale
- Charset
A default instance would be used like:
{code:java}
Strings.DEFAULT.startWith(...)
{code}
and
{code:java}
public static final Strings.MY_UTILS =
Strings.builder().setCaseSenstivity(false).build();
MY_UTILS.startWith(...)
{code}
FYI, this has come up before:
https://lists.apache.org/thread/fb5myt33lprq464wyp98ox5mt2f9ghpm
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Saif Asif
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saif Asif updated LANG-1752:
Description:
Overtime, more and more APIs are being added to the StringUtils class that are
a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is just
`endsWith` with an additional boolean ignoreCase set to true.
{code:java}
public static boolean endsWithIgnoreCase(final CharSequence str, final
CharSequence suffix) {
return endsWith(str, suffix, true);
}
private static boolean endsWith(final CharSequence str, final CharSequence
suffix, final boolean ignoreCase) {}{code}
This leads to StringUtils class increasing in size.
I would like to propose that we refactor StringUtils class and move all
ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase`
or so.
Since the refactoring will be huge, we can target for the next major version
(4.0?) and introduce `@deprecated` on the methods to give users enough time to
track and update their existing code bases.
What does the community think ?
was:
Overtime, more and more APIs are being added to the StringUtils class that are
a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is just
`endsWith` with an additional boolean ignoreCase set to true.
{{private static boolean endsWith(final CharSequence str, final CharSequence
suffix, final boolean ignoreCase)}}
This leads to StringUtils class increasing in size.
I would like to propose that we refactor StringUtils class and move all
ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase`
or so.
Since the refactoring will be huge, we can target for the next major version
(4.0?) and introduce `@deprecated` on the methods to give users enough time to
track and update their existing code bases.
What does the community think ?
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Saif Asif
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
>
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase`
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saif Asif updated LANG-1752:
Description:
Overtime, more and more APIs are being added to the StringUtils class that are
a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is just
`endsWith` with an additional boolean ignoreCase set to true.
{code:java}
public static boolean endsWithIgnoreCase(final CharSequence str, final
CharSequence suffix) {
return endsWith(str, suffix, true);
}
private static boolean endsWith(final CharSequence str, final CharSequence
suffix, final boolean ignoreCase) {}{code}
This leads to StringUtils class increasing in size.
I would like to propose that we refactor StringUtils class and move all
ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase`
or so.
Since the refactoring will be huge, we can target for the next major version
(4.0?) and introduce `@deprecated` on the methods to give users enough time to
track and update their existing code bases.
What does the community think ?
was:
Overtime, more and more APIs are being added to the StringUtils class that are
a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is just
`endsWith` with an additional boolean ignoreCase set to true.
{code:java}
public static boolean endsWithIgnoreCase(final CharSequence str, final
CharSequence suffix) {
return endsWith(str, suffix, true);
}
private static boolean endsWith(final CharSequence str, final CharSequence
suffix, final boolean ignoreCase) {}{code}
This leads to StringUtils class increasing in size.
I would like to propose that we refactor StringUtils class and move all
ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase`
or so.
Since the refactoring will be huge, we can target for the next major version
(4.0?) and introduce `@deprecated` on the methods to give users enough time to
track and update their existing code bases.
What does the community think ?
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Saif Asif
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase`
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saif Asif updated LANG-1752:
Description:
Overtime, more and more APIs are being added to the StringUtils class that are
a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is just
`endsWith` with an additional boolean ignoreCase set to true.
{code:java}
public static boolean endsWithIgnoreCase(final CharSequence str, final
CharSequence suffix) {
return endsWith(str, suffix, true);
}
private static boolean endsWith(final CharSequence str, final CharSequence
suffix, final boolean ignoreCase) {}{code}
This leads to StringUtils class increasing in size.
I would like to propose that we refactor StringUtils class and move all
ignoreCase APIs to their own class e.g something like
{code:java}
StringUtilsIgnoreCase{code}
or so.
Since the refactoring will be huge, we can target for the next major version
(4.0?) and introduce `@deprecated` on the methods to give users enough time to
track and update their existing code bases.
What does the community think ?
was:
Overtime, more and more APIs are being added to the StringUtils class that are
a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is just
`endsWith` with an additional boolean ignoreCase set to true.
{code:java}
public static boolean endsWithIgnoreCase(final CharSequence str, final
CharSequence suffix) {
return endsWith(str, suffix, true);
}
private static boolean endsWith(final CharSequence str, final CharSequence
suffix, final boolean ignoreCase) {}{code}
This leads to StringUtils class increasing in size.
I would like to propose that we refactor StringUtils class and move all
ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase`
or so.
Since the refactoring will be huge, we can target for the next major version
(4.0?) and introduce `@deprecated` on the methods to give users enough time to
track and update their existing code bases.
What does the community think ?
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Saif Asif
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
> {code:java}
> public static boolean endsWithIgnoreCase(final CharSequence str, final
> CharSequence suffix) {
> return endsWith(str, suffix, true);
> }
> private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase) {}{code}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like
> {code:java}
> StringUtilsIgnoreCase{code}
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[
https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saif Asif updated LANG-1752:
Description:
Overtime, more and more APIs are being added to the StringUtils class that are
a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is just
`endsWith` with an additional boolean ignoreCase set to true.
{{private static boolean endsWith(final CharSequence str, final CharSequence
suffix, final boolean ignoreCase)}}
This leads to StringUtils class increasing in size.
I would like to propose that we refactor StringUtils class and move all
ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase`
or so.
Since the refactoring will be huge, we can target for the next major version
(4.0?) and introduce `@deprecated` on the methods to give users enough time to
track and update their existing code bases.
What does the community think ?
was:
Overtime, more and more APIs are being added to the StringUtils class that are
a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is just
`endsWith` with an additional boolean ignoreCase set to true.
```java
private static boolean endsWith(final CharSequence str, final CharSequence
suffix, final boolean ignoreCase)
```
This leads to StringUtils class increasing in size.
I would like to propose that we refactor StringUtils class and move all
ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase`
or so.
Since the refactoring will be huge, we can target for the next major version
(4.0?) and introduce `@deprecated` on the methods to give users enough time to
track and update their existing code bases.
What does the community think ?
> Seperating ignoresCase APIs from StringUtils
>
>
> Key: LANG-1752
> URL: https://issues.apache.org/jira/browse/LANG-1752
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Saif Asif
>Priority: Major
>
> Overtime, more and more APIs are being added to the StringUtils class that
> are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is
> just `endsWith` with an additional boolean ignoreCase set to true.
>
> {{private static boolean endsWith(final CharSequence str, final CharSequence
> suffix, final boolean ignoreCase)}}
>
> This leads to StringUtils class increasing in size.
> I would like to propose that we refactor StringUtils class and move all
> ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase`
> or so.
> Since the refactoring will be huge, we can target for the next major version
> (4.0?) and introduce `@deprecated` on the methods to give users enough time
> to track and update their existing code bases.
> What does the community think ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1752) Seperating ignoresCase APIs from StringUtils
[ https://issues.apache.org/jira/browse/LANG-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saif Asif updated LANG-1752: Description: Overtime, more and more APIs are being added to the StringUtils class that are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is just `endsWith` with an additional boolean ignoreCase set to true. ```java private static boolean endsWith(final CharSequence str, final CharSequence suffix, final boolean ignoreCase) ``` This leads to StringUtils class increasing in size. I would like to propose that we refactor StringUtils class and move all ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase` or so. Since the refactoring will be huge, we can target for the next major version (4.0?) and introduce `@deprecated` on the methods to give users enough time to track and update their existing code bases. What does the community think ? was: Overtime, more and more APIs are being added to the StringUtils class that are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is just `endsWith` with an additional boolean ignoreCase set to true. This leads to StringUtils class increasing in size. I would like to propose that we refactor StringUtils class and move all ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase` or so. Since the refactoring will be huge, we can target for the next major version (4.0?) and introduce `@deprecated` on the methods to give users enough time to track and update their existing code bases. What does the community think ? > Seperating ignoresCase APIs from StringUtils > > > Key: LANG-1752 > URL: https://issues.apache.org/jira/browse/LANG-1752 > Project: Commons Lang > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: Saif Asif >Priority: Major > > Overtime, more and more APIs are being added to the StringUtils class that > are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is > just `endsWith` with an additional boolean ignoreCase set to true. > ```java > private static boolean endsWith(final CharSequence str, final CharSequence > suffix, final boolean ignoreCase) > ``` > This leads to StringUtils class increasing in size. > I would like to propose that we refactor StringUtils class and move all > ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase` > or so. > Since the refactoring will be huge, we can target for the next major version > (4.0?) and introduce `@deprecated` on the methods to give users enough time > to track and update their existing code bases. > What does the community think ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (LANG-1752) Seperating ignoresCase APIs from StringUtils
Saif Asif created LANG-1752: --- Summary: Seperating ignoresCase APIs from StringUtils Key: LANG-1752 URL: https://issues.apache.org/jira/browse/LANG-1752 Project: Commons Lang Issue Type: Improvement Affects Versions: 4.0 Reporter: Saif Asif Overtime, more and more APIs are being added to the StringUtils class that are a variation of existing APIs based on casing e.g `endsWithIgnoreCase` is just `endsWith` with an additional boolean ignoreCase set to true. This leads to StringUtils class increasing in size. I would like to propose that we refactor StringUtils class and move all ignoreCase APIs to their own class e.g something like `StringUtilsIgnoreCase` or so. Since the refactoring will be huge, we can target for the next major version (4.0?) and introduce `@deprecated` on the methods to give users enough time to track and update their existing code bases. What does the community think ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-428) Make Comparable object high priority while comparing
[ https://issues.apache.org/jira/browse/JEXL-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-428: --- Assignee: Henri Biestro > Make Comparable object high priority while comparing > > > Key: JEXL-428 > URL: https://issues.apache.org/jira/browse/JEXL-428 > Project: Commons JEXL > Issue Type: Improvement >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Major > > [https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/JexlArithmetic.java#L787] > > I defined a Class with implemented Comparable interface, when compare it with > a string object, engine does not call the compareTo method but compares by > string value. > > At JexlArithmetic.java L787, if one of the left/right value is string type, > then compares by string value, I think if the left value is Comparable and > not String type, using left object's compareTo method first makes more sense. > Thanks! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-428) Make Comparable object high priority while comparing
[ https://issues.apache.org/jira/browse/JEXL-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-428: --- Fix Version/s: 3.4.1 > Make Comparable object high priority while comparing > > > Key: JEXL-428 > URL: https://issues.apache.org/jira/browse/JEXL-428 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Major > Fix For: 3.4.1 > > > [https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/JexlArithmetic.java#L787] > > I defined a Class with implemented Comparable interface, when compare it with > a string object, engine does not call the compareTo method but compares by > string value. > > At JexlArithmetic.java L787, if one of the left/right value is string type, > then compares by string value, I think if the left value is Comparable and > not String type, using left object's compareTo method first makes more sense. > Thanks! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-428) Make Comparable object high priority while comparing
[ https://issues.apache.org/jira/browse/JEXL-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-428: --- Affects Version/s: 3.4.0 > Make Comparable object high priority while comparing > > > Key: JEXL-428 > URL: https://issues.apache.org/jira/browse/JEXL-428 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Xu Pengcheng >Assignee: Henri Biestro >Priority: Major > > [https://github.com/apache/commons-jexl/blob/master/src/main/java/org/apache/commons/jexl3/JexlArithmetic.java#L787] > > I defined a Class with implemented Comparable interface, when compare it with > a string object, engine does not call the compareTo method but compares by > string value. > > At JexlArithmetic.java L787, if one of the left/right value is string type, > then compares by string value, I think if the left value is Comparable and > not String type, using left object's compareTo method first makes more sense. > Thanks! > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
