[jira] [Commented] (LANG-1541) ArrayUtils.contains() fails to handle Double.NaN
[
https://issues.apache.org/jira/browse/LANG-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17231214#comment-17231214
]
Arturo Bernal commented on LANG-1541:
-
Hi [~ggregory]
PR created.
Kind Regards
> ArrayUtils.contains() fails to handle Double.NaN
>
>
> Key: LANG-1541
> URL: https://issues.apache.org/jira/browse/LANG-1541
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.7, 3.10
>Reporter: Anthony Maidment
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ArrayUtils.contains(double[], double) does not handle Double.NaN correctly.
> That is, ArrayUtils.contains() returns false, even if the given array
> contains Double.NaN.
> For example, consider the following:
> {code:java}
> double[] a = new double[]{Double.NEGATIVE_INFINITY, Double.NaN,
> Double.POSITIVE_INFINITY};
> System.out.println(ArrayUtils.contains(a, Double.POSITIVE_INFINITY)); // true
> System.out.println(ArrayUtils.contains(a, Double.NEGATIVE_INFINITY)); // true
> System.out.println(ArrayUtils.contains(a, Double.NaN)); // false ?
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] arturobernalg opened a new pull request #647: [LANG-1541] - ArrayUtils.contains() fails to handle Double.NaN
arturobernalg opened a new pull request #647: URL: https://github.com/apache/commons-lang/pull/647 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1541) ArrayUtils.contains() fails to handle Double.NaN
[
https://issues.apache.org/jira/browse/LANG-1541?focusedWorklogId=511243=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-511243
]
ASF GitHub Bot logged work on LANG-1541:
Author: ASF GitHub Bot
Created on: 13/Nov/20 07:15
Start Date: 13/Nov/20 07:15
Worklog Time Spent: 10m
Work Description: arturobernalg opened a new pull request #647:
URL: https://github.com/apache/commons-lang/pull/647
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 511243)
Remaining Estimate: 0h
Time Spent: 10m
> ArrayUtils.contains() fails to handle Double.NaN
>
>
> Key: LANG-1541
> URL: https://issues.apache.org/jira/browse/LANG-1541
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.7, 3.10
>Reporter: Anthony Maidment
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ArrayUtils.contains(double[], double) does not handle Double.NaN correctly.
> That is, ArrayUtils.contains() returns false, even if the given array
> contains Double.NaN.
> For example, consider the following:
> {code:java}
> double[] a = new double[]{Double.NEGATIVE_INFINITY, Double.NaN,
> Double.POSITIVE_INFINITY};
> System.out.println(ArrayUtils.contains(a, Double.POSITIVE_INFINITY)); // true
> System.out.println(ArrayUtils.contains(a, Double.NEGATIVE_INFINITY)); // true
> System.out.println(ArrayUtils.contains(a, Double.NaN)); // false ?
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1345) Add methods to enhance non-empty strings
[
https://issues.apache.org/jira/browse/LANG-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17231201#comment-17231201
]
Arturo Bernal commented on LANG-1345:
-
H [~ggregory]
I really like this method and the proposal. I think it is quite useful and
should be included in the next version. I create the PR with the name change
proposal.
[https://github.com/apache/commons-lang/pull/646]
> Add methods to enhance non-empty strings
>
>
> Key: LANG-1345
> URL: https://issues.apache.org/jira/browse/LANG-1345
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Mitth'raw'nuruodo
>Priority: Minor
> Original Estimate: 24h
> Time Spent: 20m
> Remaining Estimate: 23h 40m
>
> As a corollary to {{defaultString}}, {{appendIfMissing}}, and similar
> methods, which allow the client to replace a missing string with something,
> it would sometimes be helpful to have methods that enhance a string, if it is
> present, with a prefix and suffix (or perhaps with an arbitrary function).
> Eg
> {code}
> if (StringUtils.isNotEmpty(queryString)) {
> return url + "?" + queryString;
> } else {
> return url;
> }
> {code}
> would become:
> {code}
> return url + StringUtils.addIfNotEmpty(queryString, "?", null);
> {code}
> with the second parameter being the prefix, and the third, the suffix. If the
> string is null or empty, return empty string.
> If this could accept arbitrary transformation functions, it could effectively
> become the Elvis operator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] arturobernalg commented on pull request #646: [LANG-1345] - Add methods to enhance non-empty strings
arturobernalg commented on pull request #646: URL: https://github.com/apache/commons-lang/pull/646#issuecomment-726557310 I really like this method and the proposal. I think it is quite useful and should be included in the next version. I create the PR with the name change proposal. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1345) Add methods to enhance non-empty strings
[
https://issues.apache.org/jira/browse/LANG-1345?focusedWorklogId=511229=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-511229
]
ASF GitHub Bot logged work on LANG-1345:
Author: ASF GitHub Bot
Created on: 13/Nov/20 06:45
Start Date: 13/Nov/20 06:45
Worklog Time Spent: 10m
Work Description: arturobernalg commented on pull request #646:
URL: https://github.com/apache/commons-lang/pull/646#issuecomment-726557310
I really like this method and the proposal. I think it is quite useful and
should be included in the next version. I create the PR with the name change
proposal.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 511229)
Remaining Estimate: 23h 40m (was: 23h 50m)
Time Spent: 20m (was: 10m)
> Add methods to enhance non-empty strings
>
>
> Key: LANG-1345
> URL: https://issues.apache.org/jira/browse/LANG-1345
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Mitth'raw'nuruodo
>Priority: Minor
> Original Estimate: 24h
> Time Spent: 20m
> Remaining Estimate: 23h 40m
>
> As a corollary to {{defaultString}}, {{appendIfMissing}}, and similar
> methods, which allow the client to replace a missing string with something,
> it would sometimes be helpful to have methods that enhance a string, if it is
> present, with a prefix and suffix (or perhaps with an arbitrary function).
> Eg
> {code}
> if (StringUtils.isNotEmpty(queryString)) {
> return url + "?" + queryString;
> } else {
> return url;
> }
> {code}
> would become:
> {code}
> return url + StringUtils.addIfNotEmpty(queryString, "?", null);
> {code}
> with the second parameter being the prefix, and the third, the suffix. If the
> string is null or empty, return empty string.
> If this could accept arbitrary transformation functions, it could effectively
> become the Elvis operator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1345) Add methods to enhance non-empty strings
[
https://issues.apache.org/jira/browse/LANG-1345?focusedWorklogId=511228=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-511228
]
ASF GitHub Bot logged work on LANG-1345:
Author: ASF GitHub Bot
Created on: 13/Nov/20 06:45
Start Date: 13/Nov/20 06:45
Worklog Time Spent: 10m
Work Description: arturobernalg opened a new pull request #646:
URL: https://github.com/apache/commons-lang/pull/646
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 511228)
Remaining Estimate: 23h 50m (was: 24h)
Time Spent: 10m
> Add methods to enhance non-empty strings
>
>
> Key: LANG-1345
> URL: https://issues.apache.org/jira/browse/LANG-1345
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Mitth'raw'nuruodo
>Priority: Minor
> Original Estimate: 24h
> Time Spent: 10m
> Remaining Estimate: 23h 50m
>
> As a corollary to {{defaultString}}, {{appendIfMissing}}, and similar
> methods, which allow the client to replace a missing string with something,
> it would sometimes be helpful to have methods that enhance a string, if it is
> present, with a prefix and suffix (or perhaps with an arbitrary function).
> Eg
> {code}
> if (StringUtils.isNotEmpty(queryString)) {
> return url + "?" + queryString;
> } else {
> return url;
> }
> {code}
> would become:
> {code}
> return url + StringUtils.addIfNotEmpty(queryString, "?", null);
> {code}
> with the second parameter being the prefix, and the third, the suffix. If the
> string is null or empty, return empty string.
> If this could accept arbitrary transformation functions, it could effectively
> become the Elvis operator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] arturobernalg opened a new pull request #646: [LANG-1345] - Add methods to enhance non-empty strings
arturobernalg opened a new pull request #646: URL: https://github.com/apache/commons-lang/pull/646 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (COMPRESS-557) Have some kind of reset() in LZ77Compressor
Peter Lee created COMPRESS-557: -- Summary: Have some kind of reset() in LZ77Compressor Key: COMPRESS-557 URL: https://issues.apache.org/jira/browse/COMPRESS-557 Project: Commons Compress Issue Type: New Feature Reporter: Peter Lee It would be useful if we have a _reset()_ in LZ77Compressor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] kinow commented on a change in pull request #106: [Issue-216] Support alpha channel in TIFF RGB formats
kinow commented on a change in pull request #106:
URL: https://github.com/apache/commons-imaging/pull/106#discussion_r522538722
##
File path: src/main/java/org/apache/commons/imaging/common/ImageBuilder.java
##
@@ -242,16 +266,29 @@ private BufferedImage makeBufferedImage(
WritableRaster raster;
final DataBufferInt buffer = new DataBufferInt(argb, w * h);
if (useAlpha) {
-colorModel = new DirectColorModel(32, 0x00ff, 0xff00,
-0x00ff, 0xff00);
-raster = Raster.createPackedRaster(buffer, w, h,
-w, new int[]{0x00ff, 0xff00, 0x00ff,
-0xff00}, null);
+colorModel = new DirectColorModel(
+ColorSpace.getInstance(ColorSpace.CS_sRGB),
Review comment:
If a company like Microsoft, Google, Facebook, etc, invested some money
and time in organising all the image standards into a single, uniform website,
like JavaScript MDN, W3C specs, etc, that would make writing libraries like
Common Imaging much easier (and more sane :laughing: ).
Thanks for looking into this. Looks like we are good staying up close with
what the JDK does, unless a user has a valid case for us using another type.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-imaging] gwlucastrig commented on a change in pull request #106: [Issue-216] Support alpha channel in TIFF RGB formats
gwlucastrig commented on a change in pull request #106:
URL: https://github.com/apache/commons-imaging/pull/106#discussion_r522528975
##
File path: src/main/java/org/apache/commons/imaging/common/ImageBuilder.java
##
@@ -242,16 +266,29 @@ private BufferedImage makeBufferedImage(
WritableRaster raster;
final DataBufferInt buffer = new DataBufferInt(argb, w * h);
if (useAlpha) {
-colorModel = new DirectColorModel(32, 0x00ff, 0xff00,
-0x00ff, 0xff00);
-raster = Raster.createPackedRaster(buffer, w, h,
-w, new int[]{0x00ff, 0xff00, 0x00ff,
-0xff00}, null);
+colorModel = new DirectColorModel(
+ColorSpace.getInstance(ColorSpace.CS_sRGB),
Review comment:
Just finished looking through Java documentation and I got to say I
cannot believe how complicated this stuff is. Who would of thought something
like color would have such an elaborate set of support classes.
Anyway, I'm not really sure of the implications of this, but the Java API
documentation for the Color class says "The default color space for the Java
2D(tm) API is sRGB, a proposed standard RGB color space. For further
information on sRGB, see http://www.w3.org/pub/WWW/Graphics/Color/sRGB.html ".
That's what led me to use the declaration you saw. I also ran a quick test
program to see what was the default used by BufferedImage:
BufferedImage bImage = new BufferedImage(10, 10,
BufferedImage.TYPE_INT_RGB);
ColorSpace cSpace = bImage.getColorModel().getColorSpace();
ColorSpace linearRGB =
ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB);
ColorSpace sRGB = ColorSpace.getInstance(ColorSpace.CS_sRGB);
System.out.println("Compare to Linear RGB " +
cSpace.equals(linearRGB)); // printed out "false"
System.out.println("Compare to sRGB " + cSpace.equals(sRGB));
// printed out "true"
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-fileupload] jochenw merged pull request #47: Bump commons-io from 2.7 to 2.8.0
jochenw merged pull request #47: URL: https://github.com/apache/commons-fileupload/pull/47 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-fileupload] jochenw merged pull request #46: Bump junit-jupiter from 5.6.2 to 5.7.0
jochenw merged pull request #46: URL: https://github.com/apache/commons-fileupload/pull/46 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-imaging] kinow commented on a change in pull request #106: [Issue-216] Support alpha channel in TIFF RGB formats
kinow commented on a change in pull request #106: URL: https://github.com/apache/commons-imaging/pull/106#discussion_r522430639 ## File path: src/main/java/org/apache/commons/imaging/formats/tiff/write/TiffImageWriterBase.java ## @@ -287,7 +330,20 @@ public void writeImage(final BufferedImage src, final OutputStream os, Map
[GitHub] [commons-imaging] gwlucastrig commented on a change in pull request #106: [Issue-216] Support alpha channel in TIFF RGB formats
gwlucastrig commented on a change in pull request #106: URL: https://github.com/apache/commons-imaging/pull/106#discussion_r522428929 ## File path: src/main/java/org/apache/commons/imaging/formats/tiff/write/TiffImageWriterBase.java ## @@ -287,7 +330,20 @@ public void writeImage(final BufferedImage src, final OutputStream os, Map
[GitHub] [commons-imaging] kinow commented on a change in pull request #106: [Issue-216] Support alpha channel in TIFF RGB formats
kinow commented on a change in pull request #106:
URL: https://github.com/apache/commons-imaging/pull/106#discussion_r522428395
##
File path: src/main/java/org/apache/commons/imaging/common/ImageBuilder.java
##
@@ -242,16 +266,29 @@ private BufferedImage makeBufferedImage(
WritableRaster raster;
final DataBufferInt buffer = new DataBufferInt(argb, w * h);
if (useAlpha) {
-colorModel = new DirectColorModel(32, 0x00ff, 0xff00,
-0x00ff, 0xff00);
-raster = Raster.createPackedRaster(buffer, w, h,
-w, new int[]{0x00ff, 0xff00, 0x00ff,
-0xff00}, null);
+colorModel = new DirectColorModel(
+ColorSpace.getInstance(ColorSpace.CS_sRGB),
Review comment:
I normally default to RGB, but for no special reason. I think sRGB is
some standard related to RGB, but I can't really remember ever setting a file
to be saved as sRGB :thinking: so asking more out of curiosity. If this needs
changing later, it wouldn't break binary backward compatibility, so we can fix
it even after 1.0 release (if necessary)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-imaging] kinow commented on a change in pull request #106: [Issue-216] Support alpha channel in TIFF RGB formats
kinow commented on a change in pull request #106: URL: https://github.com/apache/commons-imaging/pull/106#discussion_r522427578 ## File path: src/main/java/org/apache/commons/imaging/formats/tiff/constants/TiffTagConstants.java ## @@ -347,6 +347,8 @@ public static final TagInfoShorts TIFF_TAG_EXTRA_SAMPLES = new TagInfoShorts( "ExtraSamples", 0x152, -1, TiffDirectoryType.TIFF_DIRECTORY_ROOT); +public static final int EXTRA_SAMPLE_ASSOCIATED_ALPHA = 1; +public static final int EXTRA_SAMPLE_UNASSOCIATED_ALPHA = 2; Review comment: :+1: looks like our constant will be similar to what others will find in OpenJDK, so all good. Thanks Gary! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-imaging] gwlucastrig commented on a change in pull request #106: [Issue-216] Support alpha channel in TIFF RGB formats
gwlucastrig commented on a change in pull request #106: URL: https://github.com/apache/commons-imaging/pull/106#discussion_r522427442 ## File path: src/main/java/org/apache/commons/imaging/formats/tiff/write/TiffImageWriterBase.java ## @@ -287,7 +330,20 @@ public void writeImage(final BufferedImage src, final OutputStream os, Map
[GitHub] [commons-imaging] gwlucastrig commented on a change in pull request #106: [Issue-216] Support alpha channel in TIFF RGB formats
gwlucastrig commented on a change in pull request #106:
URL: https://github.com/apache/commons-imaging/pull/106#discussion_r522425038
##
File path: src/main/java/org/apache/commons/imaging/common/ImageBuilder.java
##
@@ -242,16 +266,29 @@ private BufferedImage makeBufferedImage(
WritableRaster raster;
final DataBufferInt buffer = new DataBufferInt(argb, w * h);
if (useAlpha) {
-colorModel = new DirectColorModel(32, 0x00ff, 0xff00,
-0x00ff, 0xff00);
-raster = Raster.createPackedRaster(buffer, w, h,
-w, new int[]{0x00ff, 0xff00, 0x00ff,
-0xff00}, null);
+colorModel = new DirectColorModel(
+ColorSpace.getInstance(ColorSpace.CS_sRGB),
Review comment:
I think that sRGB is the default for Java and would give us the best
performance. I can double check this.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-imaging] gwlucastrig commented on a change in pull request #106: [Issue-216] Support alpha channel in TIFF RGB formats
gwlucastrig commented on a change in pull request #106: URL: https://github.com/apache/commons-imaging/pull/106#discussion_r522424325 ## File path: src/main/java/org/apache/commons/imaging/formats/tiff/constants/TiffTagConstants.java ## @@ -347,6 +347,8 @@ public static final TagInfoShorts TIFF_TAG_EXTRA_SAMPLES = new TagInfoShorts( "ExtraSamples", 0x152, -1, TiffDirectoryType.TIFF_DIRECTORY_ROOT); +public static final int EXTRA_SAMPLE_ASSOCIATED_ALPHA = 1; +public static final int EXTRA_SAMPLE_UNASSOCIATED_ALPHA = 2; Review comment: Associated and Unassociated are the names they use in the TIFF specification. In playing with the Java BufferedImage class, there seems to be a bias toward unassociated alpha (non-pre-multiplied). For example, at least in the OpenJDK Java I use, if you have a pre-multiplied images and call getRGB on it, the pixel values that come back are adjusted to look like non-pre-multiplied. Not sure I answered your question here Sorry. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-imaging] gwlucastrig commented on a change in pull request #106: [Issue-216] Support alpha channel in TIFF RGB formats
gwlucastrig commented on a change in pull request #106:
URL: https://github.com/apache/commons-imaging/pull/106#discussion_r522422434
##
File path:
src/main/java/org/apache/commons/imaging/formats/tiff/datareaders/DataReaderTiled.java
##
@@ -141,32 +141,37 @@ private void interpretTile(final ImageBuilder
imageBuilder, final byte[] bytes,
// the tile is padded to beyond the tile width
j1 = xLimit;
}
-if (predictor == 2) {
-// pre-apply the predictor logic before feeding
-// the bytes to the photometric interpretor.
+
+if (predictor ==
TiffTagConstants.PREDICTOR_VALUE_HORIZONTAL_DIFFERENCING) {
+applyPredictorToBlock(tileWidth, i1 - i0, samplesPerPixel,
bytes);
+}
+
+if (bitsPerPixel == 24) {
+// 24 bit case, we don't mask the red byte because any
+// sign-extended bits get covered by opacity mask
for (int i = i0; i < i1; i++) {
int k = (i - i0) * tileWidth * 3;
-int p0 = bytes[k++] & 0xff;
-int p1 = bytes[k++] & 0xff;
-int p2 = bytes[k++] & 0xff;
-for (int j = 1; j < tileWidth; j++) {
-p0 = (bytes[k] + p0) & 0xff;
-bytes[k++] = (byte) p0;
-p1 = (bytes[k] + p1) & 0xff;
-bytes[k++] = (byte) p1;
-p2 = (bytes[k] + p2) & 0xff;
-bytes[k++] = (byte) p2;
+for (int j = j0; j < j1; j++, k += 3) {
+final int rgb = 0xff00
+| (bytes[k] << 16)
+| ((bytes[k + 1] & 0xff) << 8)
+| (bytes[k + 2] & 0xff);
+imageBuilder.setRGB(j, i, rgb);
}
}
-}
-
-for (int i = i0; i < i1; i++) {
-int k = (i - i0) * tileWidth * 3;
-for (int j = j0; j < j1; j++, k += 3) {
-final int rgb = 0xff00
-| (((bytes[k] << 8) | (bytes[k + 1] & 0xff)) << 8)
-| (bytes[k + 2] & 0xff);
-imageBuilder.setRGB(j, i, rgb);
+} else if (bitsPerPixel == 32) {
+// 32 bit case, we don't mask the high byte because any
+// sign-extended bits get shifted up and out of result.
+for (int i = i0; i < i1; i++) {
+int k = (i - i0) * tileWidth * 4;
+for (int j = j0; j < j1; j++, k += 4) {
+final int rgb
+= ((bytes[k] & 0xff) << 16)
+| ((bytes[k + 1] & 0xff) << 8)
+| (bytes[k + 2] & 0xff)
+| (bytes[k + 3] << 24);
+imageBuilder.setRGB(j, i, rgb);
+}
Review comment:
Data reader strips and data reader tiles have always had a lot of
overlap. Really, a strip and a tile are both rectangles filled with pixels...
Though TIFF has slightly different rules for cases that run off the edges of
images... Someday, I'd like to take a look at just consolidating the two
classes. But it's going to be a pretty big change to the existing reader
classes.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (BEANUTILS-541) FluentPropertyBeanIntrospector caches corrupted writeMethod (two subclasses)
[
https://issues.apache.org/jira/browse/BEANUTILS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230811#comment-17230811
]
Sergey Chernov commented on BEANUTILS-541:
--
[~oheger] ([~oheger1]), please pay attention to this case. Also please note
that the issue still presents in current master branch (not yet released
{{commons-beanutils2}})
> FluentPropertyBeanIntrospector caches corrupted writeMethod (two subclasses)
>
>
> Key: BEANUTILS-541
> URL: https://issues.apache.org/jira/browse/BEANUTILS-541
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.9.0, 1.9.1, 1.9.2, 1.9.3, 1.9.4
>Reporter: Sergey Chernov
>Priority: Blocker
>
> There is an issue in {{FluentPropertyBeanIntrospector}} (at line 144 for
> 1.9.3), it caches wrong writeMethod in the static cache of
> {{java.beans.Introspector when base class has at least two subclasses}}.
> Simple snippet to reproduce:
> {code:java}
> import org.apache.commons.beanutils.FluentPropertyBeanIntrospector;
> import org.apache.commons.beanutils.PropertyUtilsBean;
> public class BeanUtilsTest {
> public static void main(String[] args) throws Exception {
> PropertyUtilsBean propertyUtilsBean = new PropertyUtilsBean();
> propertyUtilsBean.addBeanIntrospector(new
> FluentPropertyBeanIntrospector());
> // invert if condition and it will succeed
> if (true) {
> // fails
> SubTypeA subTypeA = new SubTypeA();
> //subTypeA.setField("name");
> propertyUtilsBean.setProperty(subTypeA, "field", "name");
> // uncomment this line and the failure will be handled
> (workaround)
> //java.beans.Introspector.flushCaches();
> SubTypeB subTypeB = new SubTypeB();
> //subTypeB.setField("name");
> propertyUtilsBean.setProperty(subTypeB, "field", "name");
> } else {
> // the same as above, but reverse order - success
> SubTypeB subTypeB = new SubTypeB();
> //subTypeB.setField("name");
> propertyUtilsBean.setProperty(subTypeB, "field", "name");
> SubTypeA subTypeA = new SubTypeA();
> //subTypeA.setField("name");
> propertyUtilsBean.setProperty(subTypeA, "field", "name");
> }
> }
> public static class BaseType {
> private String field;
> public BaseType setField(String objectName) {
> this.field = objectName;
> return this;
> }
> public String getField() {
> return field;
> }
> }
> public static class SubTypeA extends BaseType {
> @Override
> public SubTypeA setField(String field) {
> super.setField(field);
> return this;
> }
> }
> public static class SubTypeB extends BaseType {
> }
> }
> {code}
>
> It is critical, because wrong information is stored globally unless explicit
> {{Introspector.flushCaches}} ({{Introspector.flushFromCaches}}) is called.
> Failure stacktrace:
> {code}
> Exception in thread "main" java.lang.IllegalArgumentException:
> org.jeasy.random.BeanUtilsTest$SubTypeB is not assignable from
> org.jeasy.random.BeanUtilsTest$SubTypeA
> at
> org.apache.commons.beanutils.MethodUtils.getAccessibleMethod(MethodUtils.java:793)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.getWriteMethod(PropertyUtilsBean.java:1319)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.setSimpleProperty(PropertyUtilsBean.java:2094)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.setNestedProperty(PropertyUtilsBean.java:1915)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.setProperty(PropertyUtilsBean.java:2022)
> at org.jeasy.random.BeanUtilsTest.main(BeanUtilsTest.java:44)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (BEANUTILS-541) FluentPropertyBeanIntrospector caches corrupted writeMethod (two subclasses)
[
https://issues.apache.org/jira/browse/BEANUTILS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230811#comment-17230811
]
Sergey Chernov edited comment on BEANUTILS-541 at 11/12/20, 5:33 PM:
-
[~oheger], please pay attention to this case. Also please note that the issue
still presents in current master branch (not yet released
{{commons-beanutils2}})
was (Author: seregamorph):
[~oheger] ([~oheger1]), please pay attention to this case. Also please note
that the issue still presents in current master branch (not yet released
{{commons-beanutils2}})
> FluentPropertyBeanIntrospector caches corrupted writeMethod (two subclasses)
>
>
> Key: BEANUTILS-541
> URL: https://issues.apache.org/jira/browse/BEANUTILS-541
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.9.0, 1.9.1, 1.9.2, 1.9.3, 1.9.4
>Reporter: Sergey Chernov
>Priority: Blocker
>
> There is an issue in {{FluentPropertyBeanIntrospector}} (at line 144 for
> 1.9.3), it caches wrong writeMethod in the static cache of
> {{java.beans.Introspector when base class has at least two subclasses}}.
> Simple snippet to reproduce:
> {code:java}
> import org.apache.commons.beanutils.FluentPropertyBeanIntrospector;
> import org.apache.commons.beanutils.PropertyUtilsBean;
> public class BeanUtilsTest {
> public static void main(String[] args) throws Exception {
> PropertyUtilsBean propertyUtilsBean = new PropertyUtilsBean();
> propertyUtilsBean.addBeanIntrospector(new
> FluentPropertyBeanIntrospector());
> // invert if condition and it will succeed
> if (true) {
> // fails
> SubTypeA subTypeA = new SubTypeA();
> //subTypeA.setField("name");
> propertyUtilsBean.setProperty(subTypeA, "field", "name");
> // uncomment this line and the failure will be handled
> (workaround)
> //java.beans.Introspector.flushCaches();
> SubTypeB subTypeB = new SubTypeB();
> //subTypeB.setField("name");
> propertyUtilsBean.setProperty(subTypeB, "field", "name");
> } else {
> // the same as above, but reverse order - success
> SubTypeB subTypeB = new SubTypeB();
> //subTypeB.setField("name");
> propertyUtilsBean.setProperty(subTypeB, "field", "name");
> SubTypeA subTypeA = new SubTypeA();
> //subTypeA.setField("name");
> propertyUtilsBean.setProperty(subTypeA, "field", "name");
> }
> }
> public static class BaseType {
> private String field;
> public BaseType setField(String objectName) {
> this.field = objectName;
> return this;
> }
> public String getField() {
> return field;
> }
> }
> public static class SubTypeA extends BaseType {
> @Override
> public SubTypeA setField(String field) {
> super.setField(field);
> return this;
> }
> }
> public static class SubTypeB extends BaseType {
> }
> }
> {code}
>
> It is critical, because wrong information is stored globally unless explicit
> {{Introspector.flushCaches}} ({{Introspector.flushFromCaches}}) is called.
> Failure stacktrace:
> {code}
> Exception in thread "main" java.lang.IllegalArgumentException:
> org.jeasy.random.BeanUtilsTest$SubTypeB is not assignable from
> org.jeasy.random.BeanUtilsTest$SubTypeA
> at
> org.apache.commons.beanutils.MethodUtils.getAccessibleMethod(MethodUtils.java:793)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.getWriteMethod(PropertyUtilsBean.java:1319)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.setSimpleProperty(PropertyUtilsBean.java:2094)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.setNestedProperty(PropertyUtilsBean.java:1915)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.setProperty(PropertyUtilsBean.java:2022)
> at org.jeasy.random.BeanUtilsTest.main(BeanUtilsTest.java:44)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-823) StringUtils.split should handle empty strings the same as other content
[
https://issues.apache.org/jira/browse/LANG-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230802#comment-17230802
]
Arturo Bernal commented on LANG-823:
Hi [~ggregory]
I thing we can close these Issues. The behavior is correct. The method return a
empty Array with no poss
{code:java}
if (len == 0) {
return ArrayUtils.EMPTY_STRING_ARRAY;
}
{code}
The test fail cos It is trying to recover the element in position 0. But this
does not exist
{code:java}
assertTrue(StringUtils.split("",",")[0].equals(""));
{code}
java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
> StringUtils.split should handle empty strings the same as other content
> ---
>
> Key: LANG-823
> URL: https://issues.apache.org/jira/browse/LANG-823
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 2.5
>Reporter: Mark Farnsworth
>Assignee: Benedikt Ritter
>Priority: Minor
> Fix For: Review Patch, Discussion, 3.x
>
> Attachments: LANG-823.patch, LANG-823.test.patch
>
>
> When a user issues a split with a delimiter and the string does not contain
> the delimiter the result is normally an array with one item that contains the
> content of the string.
> It seems strange that StringUtils does not behave consistently in the context
> of an empty string.
> For example,
> {code}
> package maf.test;
> import junit.framework.TestCase;
> import org.apache.commons.lang.StringUtils;
> public class StringUtilsTest extends TestCase {
> public void testStringUtils() {
> // The following two lines work correctly
> assertTrue(StringUtils.split("x",",")[0].equals("x"));
> assertTrue(StringUtils.split(" ",",")[0].equals(" "));
>
> // The following should also work but
> // in commons-lang-2.5.jar the test fails here
> assertTrue(StringUtils.split("",",")[0].equals(""));
> }
> }
> {code}
> There seems to be no logic behind making split work differently in the case
> of empty strings.
> For the next release, I would suggest a behavior change for StringUtils this
> will have side effects but would be more logically consistent.
> Users who depend on the old behavior could stick with 2.5 release and/or
> implement code in the caller to simulate the behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (LANG-823) StringUtils.split should handle empty strings the same as other content
[
https://issues.apache.org/jira/browse/LANG-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230802#comment-17230802
]
Arturo Bernal edited comment on LANG-823 at 11/12/20, 5:13 PM:
---
Hi [~ggregory] [~britter]
I thing we can close these Issues. The behavior is correct. The method return a
empty Array with no poss
{code:java}
if (len == 0) {
return ArrayUtils.EMPTY_STRING_ARRAY;
}
{code}
The test fail cos It is trying to recover the element in position 0. But this
does not exist
{code:java}
assertTrue(StringUtils.split("",",")[0].equals(""));
{code}
java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
was (Author: arturobernalg):
Hi [~ggregory]
I thing we can close these Issues. The behavior is correct. The method return a
empty Array with no poss
{code:java}
if (len == 0) {
return ArrayUtils.EMPTY_STRING_ARRAY;
}
{code}
The test fail cos It is trying to recover the element in position 0. But this
does not exist
{code:java}
assertTrue(StringUtils.split("",",")[0].equals(""));
{code}
java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
> StringUtils.split should handle empty strings the same as other content
> ---
>
> Key: LANG-823
> URL: https://issues.apache.org/jira/browse/LANG-823
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 2.5
>Reporter: Mark Farnsworth
>Assignee: Benedikt Ritter
>Priority: Minor
> Fix For: Review Patch, Discussion, 3.x
>
> Attachments: LANG-823.patch, LANG-823.test.patch
>
>
> When a user issues a split with a delimiter and the string does not contain
> the delimiter the result is normally an array with one item that contains the
> content of the string.
> It seems strange that StringUtils does not behave consistently in the context
> of an empty string.
> For example,
> {code}
> package maf.test;
> import junit.framework.TestCase;
> import org.apache.commons.lang.StringUtils;
> public class StringUtilsTest extends TestCase {
> public void testStringUtils() {
> // The following two lines work correctly
> assertTrue(StringUtils.split("x",",")[0].equals("x"));
> assertTrue(StringUtils.split(" ",",")[0].equals(" "));
>
> // The following should also work but
> // in commons-lang-2.5.jar the test fails here
> assertTrue(StringUtils.split("",",")[0].equals(""));
> }
> }
> {code}
> There seems to be no logic behind making split work differently in the case
> of empty strings.
> For the next release, I would suggest a behavior change for StringUtils this
> will have side effects but would be more logically consistent.
> Users who depend on the old behavior could stick with 2.5 release and/or
> implement code in the caller to simulate the behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CSV-266) CSVRecord.toList() should be public
[ https://issues.apache.org/jira/browse/CSV-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230650#comment-17230650 ] Gary D. Gregory commented on CSV-266: - I'm glad the API works for you. Let us know if you have other issues or can contribute PRs :-) > CSVRecord.toList() should be public > --- > > Key: CSV-266 > URL: https://issues.apache.org/jira/browse/CSV-266 > Project: Commons CSV > Issue Type: Improvement > Components: Printer >Affects Versions: 1.8 >Reporter: Stephan Bublava >Priority: Minor > > I need to write CSVRecord instances to a file. > CSVPrinter supports: > * void printRecord(final Object... values) > * void printRecords(final Iterable values) > but CSVRecords only offers: > * Iterator iterator() > This is cumbersome, because I have to perform a (superfluous) Iterator -> > List conversion to make this work. > Please make CSVRecord.toList() public or add > CSVPrinter.printRecord(CSVRecord). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1562) Module name missing
[ https://issues.apache.org/jira/browse/MATH-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230616#comment-17230616 ] Gilles Sadowski commented on MATH-1562: --- bq. I'm looking forward to the next release Help is welcome to make that happen sooner! > Module name missing > --- > > Key: MATH-1562 > URL: https://issues.apache.org/jira/browse/MATH-1562 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Frank Ulbricht >Priority: Major > Fix For: 4.0, 3.7 > > > This library is not a Java module yet (because of its Java version > requirements). Nevertheless, the library should provide a stable automatic > module name via its MANIFEST.MF. Otherwise the module name will be created > from the file name which is not stable, depending on the dependency > management system. > [Automatic-Module-Name: Calling All Java Library > Maintainers|https://dzone.com/articles/automatic-module-name-calling-all-java-library-maintainers] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-95) CSG Examples
[ https://issues.apache.org/jira/browse/GEOMETRY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230614#comment-17230614 ] Matt Juntunen commented on GEOMETRY-95: --- Here is the branch containing my rough example idea: https://github.com/darkma773r/commons-geometry/tree/teapot-tutorial > CSG Examples > > > Key: GEOMETRY-95 > URL: https://issues.apache.org/jira/browse/GEOMETRY-95 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > > Adding Constructive Solid Geometry examples and userguide entries to help new > users to the library use these features. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-101) STL Reader/Writer
[ https://issues.apache.org/jira/browse/GEOMETRY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230613#comment-17230613 ] Matt Juntunen commented on GEOMETRY-101: Working on this here: https://github.com/darkma773r/commons-geometry/tree/stl-io-working > STL Reader/Writer > - > > Key: GEOMETRY-101 > URL: https://issues.apache.org/jira/browse/GEOMETRY-101 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Minor > > Add an STL reader/writer to the examples-io module, following the pattern > used by the OBJ classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-95) CSG Examples
[ https://issues.apache.org/jira/browse/GEOMETRY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230600#comment-17230600 ] Matt Juntunen commented on GEOMETRY-95: --- We still do not have a CSG tutorial in the code. I have an outline and a bit of code for what I want it to be but we need to implement a few more features before it can work the way I want it to. For example, I'd like to use STL (GEOMETRY-101) for the input/output file format since that is a very common format for models and especially for 3D printing. That is what I'm working on currently, albeit slowly. > CSG Examples > > > Key: GEOMETRY-95 > URL: https://issues.apache.org/jira/browse/GEOMETRY-95 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > > Adding Constructive Solid Geometry examples and userguide entries to help new > users to the library use these features. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MATH-1562) Module name missing
[ https://issues.apache.org/jira/browse/MATH-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230523#comment-17230523 ] Frank Ulbricht edited comment on MATH-1562 at 11/12/20, 11:01 AM: -- Thank you! Great work! I'm looking forward to the next release :) was (Author: future2r): Thank your! Great work! I'm looking forward to the next release :) > Module name missing > --- > > Key: MATH-1562 > URL: https://issues.apache.org/jira/browse/MATH-1562 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Frank Ulbricht >Priority: Major > Fix For: 4.0, 3.7 > > > This library is not a Java module yet (because of its Java version > requirements). Nevertheless, the library should provide a stable automatic > module name via its MANIFEST.MF. Otherwise the module name will be created > from the file name which is not stable, depending on the dependency > management system. > [Automatic-Module-Name: Calling All Java Library > Maintainers|https://dzone.com/articles/automatic-module-name-calling-all-java-library-maintainers] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MATH-1562) Module name missing
[ https://issues.apache.org/jira/browse/MATH-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230523#comment-17230523 ] Frank Ulbricht commented on MATH-1562: -- Thank your! Great work! I'm looking forward to the next release :) > Module name missing > --- > > Key: MATH-1562 > URL: https://issues.apache.org/jira/browse/MATH-1562 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Frank Ulbricht >Priority: Major > Fix For: 4.0, 3.7 > > > This library is not a Java module yet (because of its Java version > requirements). Nevertheless, the library should provide a stable automatic > module name via its MANIFEST.MF. Otherwise the module name will be created > from the file name which is not stable, depending on the dependency > management system. > [Automatic-Module-Name: Calling All Java Library > Maintainers|https://dzone.com/articles/automatic-module-name-calling-all-java-library-maintainers] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CSV-266) CSVRecord.toList() should be public
[ https://issues.apache.org/jira/browse/CSV-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Bublava closed CSV-266. --- Resolution: Not A Problem > CSVRecord.toList() should be public > --- > > Key: CSV-266 > URL: https://issues.apache.org/jira/browse/CSV-266 > Project: Commons CSV > Issue Type: Improvement > Components: Printer >Affects Versions: 1.8 >Reporter: Stephan Bublava >Priority: Minor > > I need to write CSVRecord instances to a file. > CSVPrinter supports: > * void printRecord(final Object... values) > * void printRecords(final Iterable values) > but CSVRecords only offers: > * Iterator iterator() > This is cumbersome, because I have to perform a (superfluous) Iterator -> > List conversion to make this work. > Please make CSVRecord.toList() public or add > CSVPrinter.printRecord(CSVRecord). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CSV-266) CSVRecord.toList() should be public
[ https://issues.apache.org/jira/browse/CSV-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230518#comment-17230518 ] Stephan Bublava commented on CSV-266: - I'm sorry, I completely missed that CSVRecord implements Iterable. > CSVRecord.toList() should be public > --- > > Key: CSV-266 > URL: https://issues.apache.org/jira/browse/CSV-266 > Project: Commons CSV > Issue Type: Improvement > Components: Printer >Affects Versions: 1.8 >Reporter: Stephan Bublava >Priority: Minor > > I need to write CSVRecord instances to a file. > CSVPrinter supports: > * void printRecord(final Object... values) > * void printRecords(final Iterable values) > but CSVRecords only offers: > * Iterator iterator() > This is cumbersome, because I have to perform a (superfluous) Iterator -> > List conversion to make this work. > Please make CSVRecord.toList() public or add > CSVPrinter.printRecord(CSVRecord). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-95) CSG Examples
[ https://issues.apache.org/jira/browse/GEOMETRY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230505#comment-17230505 ] Arturo Bernal commented on GEOMETRY-95: --- HI [~erans] The PR are merged. Can we close this feature thanks > CSG Examples > > > Key: GEOMETRY-95 > URL: https://issues.apache.org/jira/browse/GEOMETRY-95 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > > Adding Constructive Solid Geometry examples and userguide entries to help new > users to the library use these features. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LANG-1462) After version Commons-lang3.4 DateFormatUtils has a bug
[
https://issues.apache.org/jira/browse/LANG-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230411#comment-17230411
]
Lijun Liang commented on LANG-1462:
---
Hi Arturo Bernal,
The result of code execution before and after setting the time zone is the
same, and we expect to be able to set the time zone correctly. thank you for
your feedback
> After version Commons-lang3.4 DateFormatUtils has a bug
> ---
>
> Key: LANG-1462
> URL: https://issues.apache.org/jira/browse/LANG-1462
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.5, 3.6, 3.7, 3.8, 3.9, 3.8.1
>Reporter: Lijun Liang
>Priority: Critical
>
> The code is as follows ：
> Calendar cale = Calendar.getInstance();
> System.out.println("Old time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
> cale.setTimeZone(TimeZone.getTimeZone("JST"));
> System.out.println("New time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
>
> The results of commons-lang3 3.4：
> Old time is 20190605144536
> New time is 20190605154536
>
> The results of the version after commons-lang3 3.4:
> Old time is 20190605144536
> New time is 20190605144536
>
> We found that the time zone setting was invalidated when it was formatted
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
