[jira] [Resolved] (IMAGING-251) Support TIFF standard floating point data
[ https://issues.apache.org/jira/browse/IMAGING-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved IMAGING-251. Fix Version/s: (was: 1.x) 1.0-alpha2 Assignee: Bruno P. Kinoshita Resolution: Fixed > Support TIFF standard floating point data > - > > Key: IMAGING-251 > URL: https://issues.apache.org/jira/browse/IMAGING-251 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Gary Lucas >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha2 > > Attachments: ArizonaHillshade.jpg, Imaging252_USGS_n38w077.jpg > > Time Spent: 14h 20m > Remaining Estimate: 0h > > Commons Imaging does not support the floating-point format included in the > TIFF specification. There are prominent data sources that issue products in > this format. The ability to support this information would open up new > application areas for Commons Imaging. > TIFF is often used as a mechanism for distributing data from geophysical > applications in the form of GeoTIFF files. Some of this is not imagery, but > data. For example, the US Geological Survey is currently releasing > high-resolution elevation data grids for the 3DEP program under the name > Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant > potential commercial and academic applications. > To access this data means modifying the TIFF DataReaderStrips and > DataReaderTile classes to recognize floating point data (which is typically > indicated using TIFF tag #339, SampleFormat). Also, returning the data in the > form of a BufferedImage makes no sense at all, so the API on the > TiffImageParser and supporting classes would need additional methods to > return arrays of floats. The good news here is that that requirement would > mean adding new methods to the classes rather than making significant changes > to existing classes. So the probability of unintended consequences or new > bugs in existing code would be minimized. > Specification details for floating-point are given in the main TIFF-6 > documentations and Adobe Photoshop TIFF Technical Note 3. > > I am willing to volunteer to make these changes provided that there is > interest and a high probability that my contributions would be evaluated and, > if suitable, integrated into the Commons Imaging code base. > Thank you for your attention in this matter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] kinow closed pull request #72: IMAGING-251 support for TIFF floating-point formats
kinow closed pull request #72: URL: https://github.com/apache/commons-imaging/pull/72 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] (IMAGING-251) Support TIFF standard floating point data
[ https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=434147=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434147 ] ASF GitHub Bot logged work on IMAGING-251: -- Author: ASF GitHub Bot Created on: 17/May/20 04:26 Start Date: 17/May/20 04:26 Worklog Time Spent: 10m Work Description: kinow closed pull request #72: URL: https://github.com/apache/commons-imaging/pull/72 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: 434147) Time Spent: 14h 20m (was: 14h 10m) > Support TIFF standard floating point data > - > > Key: IMAGING-251 > URL: https://issues.apache.org/jira/browse/IMAGING-251 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Gary Lucas >Priority: Major > Fix For: 1.x > > Attachments: ArizonaHillshade.jpg, Imaging252_USGS_n38w077.jpg > > Time Spent: 14h 20m > Remaining Estimate: 0h > > Commons Imaging does not support the floating-point format included in the > TIFF specification. There are prominent data sources that issue products in > this format. The ability to support this information would open up new > application areas for Commons Imaging. > TIFF is often used as a mechanism for distributing data from geophysical > applications in the form of GeoTIFF files. Some of this is not imagery, but > data. For example, the US Geological Survey is currently releasing > high-resolution elevation data grids for the 3DEP program under the name > Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant > potential commercial and academic applications. > To access this data means modifying the TIFF DataReaderStrips and > DataReaderTile classes to recognize floating point data (which is typically > indicated using TIFF tag #339, SampleFormat). Also, returning the data in the > form of a BufferedImage makes no sense at all, so the API on the > TiffImageParser and supporting classes would need additional methods to > return arrays of floats. The good news here is that that requirement would > mean adding new methods to the classes rather than making significant changes > to existing classes. So the probability of unintended consequences or new > bugs in existing code would be minimized. > Specification details for floating-point are given in the main TIFF-6 > documentations and Adobe Photoshop TIFF Technical Note 3. > > I am willing to volunteer to make these changes provided that there is > interest and a high probability that my contributions would be evaluated and, > if suitable, integrated into the Commons Imaging code base. > Thank you for your attention in this matter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IMAGING-251) Support TIFF standard floating point data
[ https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=434145=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434145 ] ASF GitHub Bot logged work on IMAGING-251: -- Author: ASF GitHub Bot Created on: 17/May/20 04:19 Start Date: 17/May/20 04:19 Worklog Time Spent: 10m Work Description: kinow commented on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629740790 Approved. Rebasing and merging. Thanks @gwlucastrig ! 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: 434145) Time Spent: 14h 10m (was: 14h) > Support TIFF standard floating point data > - > > Key: IMAGING-251 > URL: https://issues.apache.org/jira/browse/IMAGING-251 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Gary Lucas >Priority: Major > Fix For: 1.x > > Attachments: ArizonaHillshade.jpg, Imaging252_USGS_n38w077.jpg > > Time Spent: 14h 10m > Remaining Estimate: 0h > > Commons Imaging does not support the floating-point format included in the > TIFF specification. There are prominent data sources that issue products in > this format. The ability to support this information would open up new > application areas for Commons Imaging. > TIFF is often used as a mechanism for distributing data from geophysical > applications in the form of GeoTIFF files. Some of this is not imagery, but > data. For example, the US Geological Survey is currently releasing > high-resolution elevation data grids for the 3DEP program under the name > Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant > potential commercial and academic applications. > To access this data means modifying the TIFF DataReaderStrips and > DataReaderTile classes to recognize floating point data (which is typically > indicated using TIFF tag #339, SampleFormat). Also, returning the data in the > form of a BufferedImage makes no sense at all, so the API on the > TiffImageParser and supporting classes would need additional methods to > return arrays of floats. The good news here is that that requirement would > mean adding new methods to the classes rather than making significant changes > to existing classes. So the probability of unintended consequences or new > bugs in existing code would be minimized. > Specification details for floating-point are given in the main TIFF-6 > documentations and Adobe Photoshop TIFF Technical Note 3. > > I am willing to volunteer to make these changes provided that there is > interest and a high probability that my contributions would be evaluated and, > if suitable, integrated into the Commons Imaging code base. > Thank you for your attention in this matter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IMAGING-251) Support TIFF standard floating point data
[ https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=434143=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434143 ] ASF GitHub Bot logged work on IMAGING-251: -- Author: ASF GitHub Bot Created on: 17/May/20 04:18 Start Date: 17/May/20 04:18 Worklog Time Spent: 10m Work Description: kinow edited a comment on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629638135 Brilliant! Then tomorrow I will finish the review. Final things I'm looking at are - [x] test coverage of new code (I lost track of how much is covered here) - [x] possible issues for security (those `N/0`, or loading values from the data without checking boundaries, etc) - [x] how much we broke backward compatibility—if any If nothing is wrong, then I will just squash. Several ways of doing it I think; I normally do with `git rebase -i HEAD~N`, where `N` is the number of commits I want to squash. Doesn't mean we need to squash to a single one, but we can probably combine a few ones. And add a changelog, and merge :-) Thanks for updating it so quickly! Bruno 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: 434143) Time Spent: 13h 50m (was: 13h 40m) > Support TIFF standard floating point data > - > > Key: IMAGING-251 > URL: https://issues.apache.org/jira/browse/IMAGING-251 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Gary Lucas >Priority: Major > Fix For: 1.x > > Attachments: ArizonaHillshade.jpg, Imaging252_USGS_n38w077.jpg > > Time Spent: 13h 50m > Remaining Estimate: 0h > > Commons Imaging does not support the floating-point format included in the > TIFF specification. There are prominent data sources that issue products in > this format. The ability to support this information would open up new > application areas for Commons Imaging. > TIFF is often used as a mechanism for distributing data from geophysical > applications in the form of GeoTIFF files. Some of this is not imagery, but > data. For example, the US Geological Survey is currently releasing > high-resolution elevation data grids for the 3DEP program under the name > Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant > potential commercial and academic applications. > To access this data means modifying the TIFF DataReaderStrips and > DataReaderTile classes to recognize floating point data (which is typically > indicated using TIFF tag #339, SampleFormat). Also, returning the data in the > form of a BufferedImage makes no sense at all, so the API on the > TiffImageParser and supporting classes would need additional methods to > return arrays of floats. The good news here is that that requirement would > mean adding new methods to the classes rather than making significant changes > to existing classes. So the probability of unintended consequences or new > bugs in existing code would be minimized. > Specification details for floating-point are given in the main TIFF-6 > documentations and Adobe Photoshop TIFF Technical Note 3. > > I am willing to volunteer to make these changes provided that there is > interest and a high probability that my contributions would be evaluated and, > if suitable, integrated into the Commons Imaging code base. > Thank you for your attention in this matter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IMAGING-251) Support TIFF standard floating point data
[ https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=434142=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434142 ] ASF GitHub Bot logged work on IMAGING-251: -- Author: ASF GitHub Bot Created on: 17/May/20 04:18 Start Date: 17/May/20 04:18 Worklog Time Spent: 10m Work Description: kinow commented on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629740729 >possible issues for security (those N/0, or loading values from the data without checking boundaries, etc) Nothing obvious. A fuzzer could still find some images that could lead to exceptions, but I couldn't find a case where it would lead to DDoS attacks (:crossed_fingers:) 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: 434142) Time Spent: 13h 40m (was: 13.5h) > Support TIFF standard floating point data > - > > Key: IMAGING-251 > URL: https://issues.apache.org/jira/browse/IMAGING-251 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Gary Lucas >Priority: Major > Fix For: 1.x > > Attachments: ArizonaHillshade.jpg, Imaging252_USGS_n38w077.jpg > > Time Spent: 13h 40m > Remaining Estimate: 0h > > Commons Imaging does not support the floating-point format included in the > TIFF specification. There are prominent data sources that issue products in > this format. The ability to support this information would open up new > application areas for Commons Imaging. > TIFF is often used as a mechanism for distributing data from geophysical > applications in the form of GeoTIFF files. Some of this is not imagery, but > data. For example, the US Geological Survey is currently releasing > high-resolution elevation data grids for the 3DEP program under the name > Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant > potential commercial and academic applications. > To access this data means modifying the TIFF DataReaderStrips and > DataReaderTile classes to recognize floating point data (which is typically > indicated using TIFF tag #339, SampleFormat). Also, returning the data in the > form of a BufferedImage makes no sense at all, so the API on the > TiffImageParser and supporting classes would need additional methods to > return arrays of floats. The good news here is that that requirement would > mean adding new methods to the classes rather than making significant changes > to existing classes. So the probability of unintended consequences or new > bugs in existing code would be minimized. > Specification details for floating-point are given in the main TIFF-6 > documentations and Adobe Photoshop TIFF Technical Note 3. > > I am willing to volunteer to make these changes provided that there is > interest and a high probability that my contributions would be evaluated and, > if suitable, integrated into the Commons Imaging code base. > Thank you for your attention in this matter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IMAGING-251) Support TIFF standard floating point data
[ https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=434144=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434144 ] ASF GitHub Bot logged work on IMAGING-251: -- Author: ASF GitHub Bot Created on: 17/May/20 04:18 Start Date: 17/May/20 04:18 Worklog Time Spent: 10m Work Description: kinow commented on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629740776 > how much we broke backward compatibility—if any Nothing too drastic—i.e. API changes OK IMHO for next **alpha** release (this will change once we have 1.0 out) 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: 434144) Time Spent: 14h (was: 13h 50m) > Support TIFF standard floating point data > - > > Key: IMAGING-251 > URL: https://issues.apache.org/jira/browse/IMAGING-251 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Gary Lucas >Priority: Major > Fix For: 1.x > > Attachments: ArizonaHillshade.jpg, Imaging252_USGS_n38w077.jpg > > Time Spent: 14h > Remaining Estimate: 0h > > Commons Imaging does not support the floating-point format included in the > TIFF specification. There are prominent data sources that issue products in > this format. The ability to support this information would open up new > application areas for Commons Imaging. > TIFF is often used as a mechanism for distributing data from geophysical > applications in the form of GeoTIFF files. Some of this is not imagery, but > data. For example, the US Geological Survey is currently releasing > high-resolution elevation data grids for the 3DEP program under the name > Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant > potential commercial and academic applications. > To access this data means modifying the TIFF DataReaderStrips and > DataReaderTile classes to recognize floating point data (which is typically > indicated using TIFF tag #339, SampleFormat). Also, returning the data in the > form of a BufferedImage makes no sense at all, so the API on the > TiffImageParser and supporting classes would need additional methods to > return arrays of floats. The good news here is that that requirement would > mean adding new methods to the classes rather than making significant changes > to existing classes. So the probability of unintended consequences or new > bugs in existing code would be minimized. > Specification details for floating-point are given in the main TIFF-6 > documentations and Adobe Photoshop TIFF Technical Note 3. > > I am willing to volunteer to make these changes provided that there is > interest and a high probability that my contributions would be evaluated and, > if suitable, integrated into the Commons Imaging code base. > Thank you for your attention in this matter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] kinow commented on pull request #72: IMAGING-251 support for TIFF floating-point formats
kinow commented on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629740776 > how much we broke backward compatibility—if any Nothing too drastic—i.e. API changes OK IMHO for next **alpha** release (this will change once we have 1.0 out) 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 pull request #72: IMAGING-251 support for TIFF floating-point formats
kinow commented on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629740790 Approved. Rebasing and merging. Thanks @gwlucastrig ! 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] (IMAGING-251) Support TIFF standard floating point data
[ https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=434141=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434141 ] ASF GitHub Bot logged work on IMAGING-251: -- Author: ASF GitHub Bot Created on: 17/May/20 04:17 Start Date: 17/May/20 04:17 Worklog Time Spent: 10m Work Description: kinow edited a comment on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629638135 Brilliant! Then tomorrow I will finish the review. Final things I'm looking at are - [x] test coverage of new code (I lost track of how much is covered here) - [x] possible issues for security (those `N/0`, or loading values from the data without checking boundaries, etc) - [ ] how much we broke backward compatibility—if any If nothing is wrong, then I will just squash. Several ways of doing it I think; I normally do with `git rebase -i HEAD~N`, where `N` is the number of commits I want to squash. Doesn't mean we need to squash to a single one, but we can probably combine a few ones. And add a changelog, and merge :-) Thanks for updating it so quickly! Bruno 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: 434141) Time Spent: 13.5h (was: 13h 20m) > Support TIFF standard floating point data > - > > Key: IMAGING-251 > URL: https://issues.apache.org/jira/browse/IMAGING-251 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Gary Lucas >Priority: Major > Fix For: 1.x > > Attachments: ArizonaHillshade.jpg, Imaging252_USGS_n38w077.jpg > > Time Spent: 13.5h > Remaining Estimate: 0h > > Commons Imaging does not support the floating-point format included in the > TIFF specification. There are prominent data sources that issue products in > this format. The ability to support this information would open up new > application areas for Commons Imaging. > TIFF is often used as a mechanism for distributing data from geophysical > applications in the form of GeoTIFF files. Some of this is not imagery, but > data. For example, the US Geological Survey is currently releasing > high-resolution elevation data grids for the 3DEP program under the name > Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant > potential commercial and academic applications. > To access this data means modifying the TIFF DataReaderStrips and > DataReaderTile classes to recognize floating point data (which is typically > indicated using TIFF tag #339, SampleFormat). Also, returning the data in the > form of a BufferedImage makes no sense at all, so the API on the > TiffImageParser and supporting classes would need additional methods to > return arrays of floats. The good news here is that that requirement would > mean adding new methods to the classes rather than making significant changes > to existing classes. So the probability of unintended consequences or new > bugs in existing code would be minimized. > Specification details for floating-point are given in the main TIFF-6 > documentations and Adobe Photoshop TIFF Technical Note 3. > > I am willing to volunteer to make these changes provided that there is > interest and a high probability that my contributions would be evaluated and, > if suitable, integrated into the Commons Imaging code base. > Thank you for your attention in this matter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] kinow edited a comment on pull request #72: IMAGING-251 support for TIFF floating-point formats
kinow edited a comment on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629638135 Brilliant! Then tomorrow I will finish the review. Final things I'm looking at are - [x] test coverage of new code (I lost track of how much is covered here) - [x] possible issues for security (those `N/0`, or loading values from the data without checking boundaries, etc) - [ ] how much we broke backward compatibility—if any If nothing is wrong, then I will just squash. Several ways of doing it I think; I normally do with `git rebase -i HEAD~N`, where `N` is the number of commits I want to squash. Doesn't mean we need to squash to a single one, but we can probably combine a few ones. And add a changelog, and merge :-) Thanks for updating it so quickly! Bruno 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 pull request #72: IMAGING-251 support for TIFF floating-point formats
kinow commented on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629740729 >possible issues for security (those N/0, or loading values from the data without checking boundaries, etc) Nothing obvious. A fuzzer could still find some images that could lead to exceptions, but I couldn't find a case where it would lead to DDoS attacks (:crossed_fingers:) 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 edited a comment on pull request #72: IMAGING-251 support for TIFF floating-point formats
kinow edited a comment on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629638135 Brilliant! Then tomorrow I will finish the review. Final things I'm looking at are - [x] test coverage of new code (I lost track of how much is covered here) - [x] possible issues for security (those `N/0`, or loading values from the data without checking boundaries, etc) - [x] how much we broke backward compatibility—if any If nothing is wrong, then I will just squash. Several ways of doing it I think; I normally do with `git rebase -i HEAD~N`, where `N` is the number of commits I want to squash. Doesn't mean we need to squash to a single one, but we can probably combine a few ones. And add a changelog, and merge :-) Thanks for updating it so quickly! Bruno 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] (IMAGING-251) Support TIFF standard floating point data
[
https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=434140=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434140
]
ASF GitHub Bot logged work on IMAGING-251:
--
Author: ASF GitHub Bot
Created on: 17/May/20 04:11
Start Date: 17/May/20 04:11
Worklog Time Spent: 10m
Work Description: kinow commented on a change in pull request #72:
URL: https://github.com/apache/commons-imaging/pull/72#discussion_r426215117
##
File path:
src/main/java/org/apache/commons/imaging/formats/tiff/TiffRasterData.java
##
@@ -0,0 +1,155 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.imaging.formats.tiff;
+
+/**
+ * Provides a simple container for floating-point data. Some TIFF files are
used
+ * to store floating-point data rather than images. This class is intended to
+ * support access to those TIFF files.
+ */
+public class TiffRasterData {
+
+
+private final int width;
+private final int height;
+private final float[] data;
+
+/**
+ * Construct an instance allocating memory for the specified dimensions.
+ *
+ * @param width a value of 1 or greater
+ * @param height a value of 1 or greater
+ */
+public TiffRasterData(int width, int height) {
+if (width <= 0 || height <= 0) {
+throw new IllegalArgumentException(
+"Raster dimensions less than or equal to zero are not
supported");
+}
+int nCells = width * height;
+data = new float[nCells];
+this.width = width;
+this.height = height;
+
+}
+
+/**
+ * Construct an instance allocating memory for the specified dimensions.
+ *
+ * @param width a value of 1 or greater
+ * @param height a value of 1 or greater
+ * @param data the data to be stored in the raster.
+ */
+public TiffRasterData(int width, int height, float[] data) {
+if (width <= 0 || height <= 0) {
+throw new IllegalArgumentException(
+"Raster dimensions less than or equal to zero are not
supported");
+}
+if (data == null || data.length < width * height) {
+throw new IllegalArgumentException(
+"Specified data does not contain sufficient elements");
+}
+this.width = width;
+this.height = height;
+this.data = data;
+
+}
+
+/**
+ * Sets the value stored at the specified raster coordinates.
+ *
+ * @param x integer coordinate in the columnar direction
+ * @param y integer coordinate in the row direction
+ * @param value the value to be stored at the specified location;
+ * potentially a FloatNaN.
+ */
+public void setValue(int x, int y, float value) {
+if (x < 0 || x >= width || y < 0 || y >= height) {
+throw new IllegalArgumentException(
+"Coordinates out of range (" + x + ", " + y + ")");
+}
+data[y * width + x] = value;
+}
+
+/**
+ * Gets the value stored at the specified raster coordinates.
+ *
+ * @param x integer coordinate in the columnar direction
+ * @param y integer coordinate in the row direction
+ * @return the value stored at the specified location; potentially a
+ * FloatNaN.
+ */
+public float getValue(int x, int y) {
+if (x < 0 || x >= width || y < 0 || y >= height) {
+throw new IllegalArgumentException(
+"Coordinates out of range (" + x + ", " + y + ")");
+}
+return data[y * width + x];
+}
+
+/**
+ * Tabulates simple statistics for the raster and returns an instance
+ * containing general metadata.
+ *
+ * @return a valid instance.
+ */
+public TiffRasterStatistics getSimpleStatistics() {
+return new TiffRasterStatistics(this, Float.NaN);
+}
+
+/**
+ * Tabulates simple statistics for the raster excluding the specified value
+ * and returns an instance containing general metadata,
Review comment:
Fixed locally.
[GitHub] [commons-imaging] kinow commented on a change in pull request #72: IMAGING-251 support for TIFF floating-point formats
kinow commented on a change in pull request #72:
URL: https://github.com/apache/commons-imaging/pull/72#discussion_r426215117
##
File path:
src/main/java/org/apache/commons/imaging/formats/tiff/TiffRasterData.java
##
@@ -0,0 +1,155 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.imaging.formats.tiff;
+
+/**
+ * Provides a simple container for floating-point data. Some TIFF files are
used
+ * to store floating-point data rather than images. This class is intended to
+ * support access to those TIFF files.
+ */
+public class TiffRasterData {
+
+
+private final int width;
+private final int height;
+private final float[] data;
+
+/**
+ * Construct an instance allocating memory for the specified dimensions.
+ *
+ * @param width a value of 1 or greater
+ * @param height a value of 1 or greater
+ */
+public TiffRasterData(int width, int height) {
+if (width <= 0 || height <= 0) {
+throw new IllegalArgumentException(
+"Raster dimensions less than or equal to zero are not
supported");
+}
+int nCells = width * height;
+data = new float[nCells];
+this.width = width;
+this.height = height;
+
+}
+
+/**
+ * Construct an instance allocating memory for the specified dimensions.
+ *
+ * @param width a value of 1 or greater
+ * @param height a value of 1 or greater
+ * @param data the data to be stored in the raster.
+ */
+public TiffRasterData(int width, int height, float[] data) {
+if (width <= 0 || height <= 0) {
+throw new IllegalArgumentException(
+"Raster dimensions less than or equal to zero are not
supported");
+}
+if (data == null || data.length < width * height) {
+throw new IllegalArgumentException(
+"Specified data does not contain sufficient elements");
+}
+this.width = width;
+this.height = height;
+this.data = data;
+
+}
+
+/**
+ * Sets the value stored at the specified raster coordinates.
+ *
+ * @param x integer coordinate in the columnar direction
+ * @param y integer coordinate in the row direction
+ * @param value the value to be stored at the specified location;
+ * potentially a FloatNaN.
+ */
+public void setValue(int x, int y, float value) {
+if (x < 0 || x >= width || y < 0 || y >= height) {
+throw new IllegalArgumentException(
+"Coordinates out of range (" + x + ", " + y + ")");
+}
+data[y * width + x] = value;
+}
+
+/**
+ * Gets the value stored at the specified raster coordinates.
+ *
+ * @param x integer coordinate in the columnar direction
+ * @param y integer coordinate in the row direction
+ * @return the value stored at the specified location; potentially a
+ * FloatNaN.
+ */
+public float getValue(int x, int y) {
+if (x < 0 || x >= width || y < 0 || y >= height) {
+throw new IllegalArgumentException(
+"Coordinates out of range (" + x + ", " + y + ")");
+}
+return data[y * width + x];
+}
+
+/**
+ * Tabulates simple statistics for the raster and returns an instance
+ * containing general metadata.
+ *
+ * @return a valid instance.
+ */
+public TiffRasterStatistics getSimpleStatistics() {
+return new TiffRasterStatistics(this, Float.NaN);
+}
+
+/**
+ * Tabulates simple statistics for the raster excluding the specified value
+ * and returns an instance containing general metadata,
Review comment:
Fixed locally.
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] (IMAGING-251) Support TIFF standard floating point data
[ https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=434139=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434139 ] ASF GitHub Bot logged work on IMAGING-251: -- Author: ASF GitHub Bot Created on: 17/May/20 04:09 Start Date: 17/May/20 04:09 Worklog Time Spent: 10m Work Description: kinow edited a comment on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629638135 Brilliant! Then tomorrow I will finish the review. Final things I'm looking at are - [x] test coverage of new code (I lost track of how much is covered here) - [ ] possible issues for security (those `N/0`, or loading values from the data without checking boundaries, etc) - [ ] how much we broke backward compatibility—if any If nothing is wrong, then I will just squash. Several ways of doing it I think; I normally do with `git rebase -i HEAD~N`, where `N` is the number of commits I want to squash. Doesn't mean we need to squash to a single one, but we can probably combine a few ones. And add a changelog, and merge :-) Thanks for updating it so quickly! Bruno 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: 434139) Time Spent: 13h 10m (was: 13h) > Support TIFF standard floating point data > - > > Key: IMAGING-251 > URL: https://issues.apache.org/jira/browse/IMAGING-251 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Gary Lucas >Priority: Major > Fix For: 1.x > > Attachments: ArizonaHillshade.jpg, Imaging252_USGS_n38w077.jpg > > Time Spent: 13h 10m > Remaining Estimate: 0h > > Commons Imaging does not support the floating-point format included in the > TIFF specification. There are prominent data sources that issue products in > this format. The ability to support this information would open up new > application areas for Commons Imaging. > TIFF is often used as a mechanism for distributing data from geophysical > applications in the form of GeoTIFF files. Some of this is not imagery, but > data. For example, the US Geological Survey is currently releasing > high-resolution elevation data grids for the 3DEP program under the name > Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant > potential commercial and academic applications. > To access this data means modifying the TIFF DataReaderStrips and > DataReaderTile classes to recognize floating point data (which is typically > indicated using TIFF tag #339, SampleFormat). Also, returning the data in the > form of a BufferedImage makes no sense at all, so the API on the > TiffImageParser and supporting classes would need additional methods to > return arrays of floats. The good news here is that that requirement would > mean adding new methods to the classes rather than making significant changes > to existing classes. So the probability of unintended consequences or new > bugs in existing code would be minimized. > Specification details for floating-point are given in the main TIFF-6 > documentations and Adobe Photoshop TIFF Technical Note 3. > > I am willing to volunteer to make these changes provided that there is > interest and a high probability that my contributions would be evaluated and, > if suitable, integrated into the Commons Imaging code base. > Thank you for your attention in this matter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] kinow edited a comment on pull request #72: IMAGING-251 support for TIFF floating-point formats
kinow edited a comment on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629638135 Brilliant! Then tomorrow I will finish the review. Final things I'm looking at are - [x] test coverage of new code (I lost track of how much is covered here) - [ ] possible issues for security (those `N/0`, or loading values from the data without checking boundaries, etc) - [ ] how much we broke backward compatibility—if any If nothing is wrong, then I will just squash. Several ways of doing it I think; I normally do with `git rebase -i HEAD~N`, where `N` is the number of commits I want to squash. Doesn't mean we need to squash to a single one, but we can probably combine a few ones. And add a changelog, and merge :-) Thanks for updating it so quickly! Bruno 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] (IMAGING-251) Support TIFF standard floating point data
[ https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=434138=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434138 ] ASF GitHub Bot logged work on IMAGING-251: -- Author: ASF GitHub Bot Created on: 17/May/20 04:08 Start Date: 17/May/20 04:08 Worklog Time Spent: 10m Work Description: kinow commented on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629740020 >test coverage of new code (I lost track of how much is covered here) Some of the new code is not covered by tests. But alas I think it's quite hard to find images for these tests. Later we may look into having some sort of image generator, or try to locate more test images. https://coveralls.io/builds/30831964  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: 434138) Time Spent: 13h (was: 12h 50m) > Support TIFF standard floating point data > - > > Key: IMAGING-251 > URL: https://issues.apache.org/jira/browse/IMAGING-251 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Gary Lucas >Priority: Major > Fix For: 1.x > > Attachments: ArizonaHillshade.jpg, Imaging252_USGS_n38w077.jpg > > Time Spent: 13h > Remaining Estimate: 0h > > Commons Imaging does not support the floating-point format included in the > TIFF specification. There are prominent data sources that issue products in > this format. The ability to support this information would open up new > application areas for Commons Imaging. > TIFF is often used as a mechanism for distributing data from geophysical > applications in the form of GeoTIFF files. Some of this is not imagery, but > data. For example, the US Geological Survey is currently releasing > high-resolution elevation data grids for the 3DEP program under the name > Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant > potential commercial and academic applications. > To access this data means modifying the TIFF DataReaderStrips and > DataReaderTile classes to recognize floating point data (which is typically > indicated using TIFF tag #339, SampleFormat). Also, returning the data in the > form of a BufferedImage makes no sense at all, so the API on the > TiffImageParser and supporting classes would need additional methods to > return arrays of floats. The good news here is that that requirement would > mean adding new methods to the classes rather than making significant changes > to existing classes. So the probability of unintended consequences or new > bugs in existing code would be minimized. > Specification details for floating-point are given in the main TIFF-6 > documentations and Adobe Photoshop TIFF Technical Note 3. > > I am willing to volunteer to make these changes provided that there is > interest and a high probability that my contributions would be evaluated and, > if suitable, integrated into the Commons Imaging code base. > Thank you for your attention in this matter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] kinow commented on pull request #72: IMAGING-251 support for TIFF floating-point formats
kinow commented on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629740020 >test coverage of new code (I lost track of how much is covered here) Some of the new code is not covered by tests. But alas I think it's quite hard to find images for these tests. Later we may look into having some sort of image generator, or try to locate more test images. https://coveralls.io/builds/30831964  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-lang] swarajsaaj commented on a change in pull request #530: LANG-1542: ToStringBuilder.reflectionToString - Wrong JSON format for List
swarajsaaj commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426171315
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
This should fix the case I mentioned earlier. I guess, test cases can
also be updated for non-enum collections, else seems good.
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-1542) ToStringBuilder.reflectionToString - Wrong JSON format when object has a List of Enum
[
https://issues.apache.org/jira/browse/LANG-1542?focusedWorklogId=434088=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434088
]
ASF GitHub Bot logged work on LANG-1542:
Author: ASF GitHub Bot
Created on: 16/May/20 17:04
Start Date: 16/May/20 17:04
Worklog Time Spent: 10m
Work Description: swarajsaaj commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426171315
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
This should fix the case I mentioned earlier. I guess, test cases can
also be updated for non-enum collections, else seems good.
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: 434088)
Time Spent: 1.5h (was: 1h 20m)
> ToStringBuilder.reflectionToString - Wrong JSON format when object has a List
> of Enum
> -
>
> Key: LANG-1542
> URL: https://issues.apache.org/jira/browse/LANG-1542
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.10
> Environment: Open JDK 1.8
>Reporter: Trần Ngọc Khoa
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> I'm trying to log an object to console with JSON style using
> {{ToStringBuilder.reflectionToString}} from {{commons-lang3:3.10}} but it
> seems generated a wrong JSON format.
> Problem happening when I have a list of enums in my field list.
>
> {code:java}
> This is the class:
> public class Person {
> private long id;
> private String name;
> private List listEnums;
> //getter and setter
> public String toString(){
> return ToStringBuilder.reflectionToString(this,
> ToStringStyle.JSON_STYLE);
> }
> }
> {code}
>
> And {{MyEnum}}:
> {code:java}
> public enum MyEnum {
> FOOD,
> SPORT,
> BOOK,
> MUSIC
> }{code}
> When I call {{toString()}} of Person object. It shows like this
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": [FRIDAY, MONDAY, TUESDAY]
> }{code}
>
> What I expected is:
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": ["FRIDAY", "MONDAY", "TUESDAY"]
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] swarajsaaj commented on a change in pull request #530: LANG-1542: ToStringBuilder.reflectionToString - Wrong JSON format for List
swarajsaaj commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426171315
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
This should fix the case I mentioned earlier. Seems good.
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-1542) ToStringBuilder.reflectionToString - Wrong JSON format when object has a List of Enum
[
https://issues.apache.org/jira/browse/LANG-1542?focusedWorklogId=434087=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434087
]
ASF GitHub Bot logged work on LANG-1542:
Author: ASF GitHub Bot
Created on: 16/May/20 17:03
Start Date: 16/May/20 17:03
Worklog Time Spent: 10m
Work Description: swarajsaaj commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426171315
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
This should fix the case I mentioned earlier. Seems good.
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: 434087)
Time Spent: 1h 20m (was: 1h 10m)
> ToStringBuilder.reflectionToString - Wrong JSON format when object has a List
> of Enum
> -
>
> Key: LANG-1542
> URL: https://issues.apache.org/jira/browse/LANG-1542
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.10
> Environment: Open JDK 1.8
>Reporter: Trần Ngọc Khoa
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> I'm trying to log an object to console with JSON style using
> {{ToStringBuilder.reflectionToString}} from {{commons-lang3:3.10}} but it
> seems generated a wrong JSON format.
> Problem happening when I have a list of enums in my field list.
>
> {code:java}
> This is the class:
> public class Person {
> private long id;
> private String name;
> private List listEnums;
> //getter and setter
> public String toString(){
> return ToStringBuilder.reflectionToString(this,
> ToStringStyle.JSON_STYLE);
> }
> }
> {code}
>
> And {{MyEnum}}:
> {code:java}
> public enum MyEnum {
> FOOD,
> SPORT,
> BOOK,
> MUSIC
> }{code}
> When I call {{toString()}} of Person object. It shows like this
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": [FRIDAY, MONDAY, TUESDAY]
> }{code}
>
> What I expected is:
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": ["FRIDAY", "MONDAY", "TUESDAY"]
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (LANG-1543) [JSON string for maps] ToStringBuilder.reflectionToString doesnt render nested maps correctly.
[
https://issues.apache.org/jira/browse/LANG-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swaraj Pal updated LANG-1543:
-
Summary: [JSON string for maps] ToStringBuilder.reflectionToString doesnt
render nested maps correctly. (was: ToStringBuilder.reflectionToString doesnt
render nested maps correctly.)
> [JSON string for maps] ToStringBuilder.reflectionToString doesnt render
> nested maps correctly.
> --
>
> Key: LANG-1543
> URL: https://issues.apache.org/jira/browse/LANG-1543
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.10
>Reporter: Swaraj Pal
>Priority: Major
>
> Nested Maps are not converted correctly as JSON using
> ToStringBuilder.reflectToString commons-lang3:3.10 . Please find below the
> example to reproduce:-
> Class:
> {code:java}
> public class Student {
> private String name;
> private Map education;
> //getters and setters...
> public String toString() {
> return ToStringBuilder.reflectionToString(this,
> ToStringStyle.JSON_STYLE);
> }}
> {code}
>
> Driver test:
> {code:java}
> Student p = new Student();
> p.setName("como");
>
> Map educationMap = new HashMap();
> educationMap.put("primary", "school");
> educationMap.put("graduation", "B.S.");
>
> p.setEducation(educationMap);
>
> System.out.println(p.toString());
> {code}
> The toString() prints
> {code:java}
> {"education":{graduation=B.S., primary=school},"name":"como"}
> {code}
> but I expect as JSON it should print as below (with proper key,value pairs as
> field names and values)
> {code:java}
> {"education":{"graduation": "B.S.", "primary":"school"},"name":"como"}
> {code}
> Suggested fix:
> I can create a Pull request for this issue handling Maps appending logic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1501) Test may fail due to a different order of fields returned by reflection API
[ https://issues.apache.org/jira/browse/LANG-1501?focusedWorklogId=434079=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434079 ] ASF GitHub Bot logged work on LANG-1501: Author: ASF GitHub Bot Created on: 16/May/20 14:54 Start Date: 16/May/20 14:54 Worklog Time Spent: 10m Work Description: TranNgocKhoa commented on pull request #481: URL: https://github.com/apache/commons-lang/pull/481#issuecomment-629658382 Could I get a JSON object with its field sorted with this order? - declare fields order in the class. - declare fields order in parents class, from direct parent to other parents. 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: 434079) Time Spent: 40m (was: 0.5h) > Test may fail due to a different order of fields returned by reflection API > --- > > Key: LANG-1501 > URL: https://issues.apache.org/jira/browse/LANG-1501 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Reporter: contextshuffling >Priority: Minor > Fix For: 3.10 > > Time Spent: 40m > Remaining Estimate: 0h > > Tests in MultilineRecursiveToStringStyleTest.java, > RecursiveToStringStyleTest.java, ToStringBuilderTest.java depends on > ReflectionToStringBuilder.appendFieldsIn. It appends the fields returned by > java.lang.Class.getDeclaredFields. > However, java.lang.Class.getDeclaredFields does not guarantee any specific > order and thus, test can fail if the order is different, (i.e., it generates > a different hash code). "The elements in the returned array are not sorted > and are not in any particular order" (reference: > https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] TranNgocKhoa commented on pull request #481: [LANG-1501] Sort fields in ReflectionToStringBuilder for deterministic order
TranNgocKhoa commented on pull request #481: URL: https://github.com/apache/commons-lang/pull/481#issuecomment-629658382 Could I get a JSON object with its field sorted with this order? - declare fields order in the class. - declare fields order in parents class, from direct parent to other parents. 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-1542) ToStringBuilder.reflectionToString - Wrong JSON format when object has a List of Enum
[
https://issues.apache.org/jira/browse/LANG-1542?focusedWorklogId=434073=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434073
]
ASF GitHub Bot logged work on LANG-1542:
Author: ASF GitHub Bot
Created on: 16/May/20 13:56
Start Date: 16/May/20 13:56
Worklog Time Spent: 10m
Work Description: coveralls edited a comment on pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#issuecomment-629603951
[](https://coveralls.io/builds/30832851)
Coverage increased (+0.0009%) to 95.092% when pulling
**59ab563d411b8e2e909af54527698d02c584f043 on TranNgocKhoa:master** into
**f6923510352fc3fbfad68bc6c5ac5258a34671b7 on apache:master**.
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: 434073)
Time Spent: 1h 10m (was: 1h)
> ToStringBuilder.reflectionToString - Wrong JSON format when object has a List
> of Enum
> -
>
> Key: LANG-1542
> URL: https://issues.apache.org/jira/browse/LANG-1542
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.10
> Environment: Open JDK 1.8
>Reporter: Trần Ngọc Khoa
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I'm trying to log an object to console with JSON style using
> {{ToStringBuilder.reflectionToString}} from {{commons-lang3:3.10}} but it
> seems generated a wrong JSON format.
> Problem happening when I have a list of enums in my field list.
>
> {code:java}
> This is the class:
> public class Person {
> private long id;
> private String name;
> private List listEnums;
> //getter and setter
> public String toString(){
> return ToStringBuilder.reflectionToString(this,
> ToStringStyle.JSON_STYLE);
> }
> }
> {code}
>
> And {{MyEnum}}:
> {code:java}
> public enum MyEnum {
> FOOD,
> SPORT,
> BOOK,
> MUSIC
> }{code}
> When I call {{toString()}} of Person object. It shows like this
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": [FRIDAY, MONDAY, TUESDAY]
> }{code}
>
> What I expected is:
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": ["FRIDAY", "MONDAY", "TUESDAY"]
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #530: LANG-1542: ToStringBuilder.reflectionToString - Wrong JSON format for List
coveralls edited a comment on pull request #530: URL: https://github.com/apache/commons-lang/pull/530#issuecomment-629603951 [](https://coveralls.io/builds/30832851) Coverage increased (+0.0009%) to 95.092% when pulling **59ab563d411b8e2e909af54527698d02c584f043 on TranNgocKhoa:master** into **f6923510352fc3fbfad68bc6c5ac5258a34671b7 on apache:master**. 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-1542) ToStringBuilder.reflectionToString - Wrong JSON format when object has a List of Enum
[
https://issues.apache.org/jira/browse/LANG-1542?focusedWorklogId=434070=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434070
]
ASF GitHub Bot logged work on LANG-1542:
Author: ASF GitHub Bot
Created on: 16/May/20 13:47
Start Date: 16/May/20 13:47
Worklog Time Spent: 10m
Work Description: TranNgocKhoa commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426155133
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
@garydgregory @swarajsaaj I added some code following your comments.
Please take a look. Thank you!
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: 434070)
Time Spent: 1h (was: 50m)
> ToStringBuilder.reflectionToString - Wrong JSON format when object has a List
> of Enum
> -
>
> Key: LANG-1542
> URL: https://issues.apache.org/jira/browse/LANG-1542
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.10
> Environment: Open JDK 1.8
>Reporter: Trần Ngọc Khoa
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I'm trying to log an object to console with JSON style using
> {{ToStringBuilder.reflectionToString}} from {{commons-lang3:3.10}} but it
> seems generated a wrong JSON format.
> Problem happening when I have a list of enums in my field list.
>
> {code:java}
> This is the class:
> public class Person {
> private long id;
> private String name;
> private List listEnums;
> //getter and setter
> public String toString(){
> return ToStringBuilder.reflectionToString(this,
> ToStringStyle.JSON_STYLE);
> }
> }
> {code}
>
> And {{MyEnum}}:
> {code:java}
> public enum MyEnum {
> FOOD,
> SPORT,
> BOOK,
> MUSIC
> }{code}
> When I call {{toString()}} of Person object. It shows like this
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": [FRIDAY, MONDAY, TUESDAY]
> }{code}
>
> What I expected is:
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": ["FRIDAY", "MONDAY", "TUESDAY"]
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] TranNgocKhoa commented on a change in pull request #530: LANG-1542: ToStringBuilder.reflectionToString - Wrong JSON format for List
TranNgocKhoa commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426155133
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
@garydgregory @swarajsaaj I added some code following your comments.
Please take a look. Thank you!
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-1542) ToStringBuilder.reflectionToString - Wrong JSON format when object has a List of Enum
[
https://issues.apache.org/jira/browse/LANG-1542?focusedWorklogId=434069=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434069
]
ASF GitHub Bot logged work on LANG-1542:
Author: ASF GitHub Bot
Created on: 16/May/20 12:43
Start Date: 16/May/20 12:43
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426150483
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
We should avoid using streams here IMO, it will likely make performance
worse in what can already be slow when reflection is involved.
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: 434069)
Time Spent: 50m (was: 40m)
> ToStringBuilder.reflectionToString - Wrong JSON format when object has a List
> of Enum
> -
>
> Key: LANG-1542
> URL: https://issues.apache.org/jira/browse/LANG-1542
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.10
> Environment: Open JDK 1.8
>Reporter: Trần Ngọc Khoa
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I'm trying to log an object to console with JSON style using
> {{ToStringBuilder.reflectionToString}} from {{commons-lang3:3.10}} but it
> seems generated a wrong JSON format.
> Problem happening when I have a list of enums in my field list.
>
> {code:java}
> This is the class:
> public class Person {
> private long id;
> private String name;
> private List listEnums;
> //getter and setter
> public String toString(){
> return ToStringBuilder.reflectionToString(this,
> ToStringStyle.JSON_STYLE);
> }
> }
> {code}
>
> And {{MyEnum}}:
> {code:java}
> public enum MyEnum {
> FOOD,
> SPORT,
> BOOK,
> MUSIC
> }{code}
> When I call {{toString()}} of Person object. It shows like this
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": [FRIDAY, MONDAY, TUESDAY]
> }{code}
>
> What I expected is:
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": ["FRIDAY", "MONDAY", "TUESDAY"]
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on a change in pull request #530: LANG-1542: ToStringBuilder.reflectionToString - Wrong JSON format for List
garydgregory commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426150483
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
We should avoid using streams here IMO, it will likely make performance
worse in what can already be slow when reflection is involved.
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] (IMAGING-251) Support TIFF standard floating point data
[ https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=434067=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434067 ] ASF GitHub Bot logged work on IMAGING-251: -- Author: ASF GitHub Bot Created on: 16/May/20 12:28 Start Date: 16/May/20 12:28 Worklog Time Spent: 10m Work Description: kinow commented on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629638135 Brilliant! Then tomorrow I will finish the review. Final things I'm looking at are - test coverage of new code (I lost track of how much is covered here) - possible issues for security (those `N/0`, or loading values from the data without checking boundaries, etc) - how much we broke backward compatibility—if any If nothing is wrong, then I will just squash. Several ways of doing it I think; I normally do with `git rebase -i HEAD~N`, where `N` is the number of commits I want to squash. Doesn't mean we need to squash to a single one, but we can probably combine a few ones. And add a changelog, and merge :-) Thanks for updating it so quickly! Bruno 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: 434067) Time Spent: 12h 50m (was: 12h 40m) > Support TIFF standard floating point data > - > > Key: IMAGING-251 > URL: https://issues.apache.org/jira/browse/IMAGING-251 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Gary Lucas >Priority: Major > Fix For: 1.x > > Attachments: ArizonaHillshade.jpg, Imaging252_USGS_n38w077.jpg > > Time Spent: 12h 50m > Remaining Estimate: 0h > > Commons Imaging does not support the floating-point format included in the > TIFF specification. There are prominent data sources that issue products in > this format. The ability to support this information would open up new > application areas for Commons Imaging. > TIFF is often used as a mechanism for distributing data from geophysical > applications in the form of GeoTIFF files. Some of this is not imagery, but > data. For example, the US Geological Survey is currently releasing > high-resolution elevation data grids for the 3DEP program under the name > Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant > potential commercial and academic applications. > To access this data means modifying the TIFF DataReaderStrips and > DataReaderTile classes to recognize floating point data (which is typically > indicated using TIFF tag #339, SampleFormat). Also, returning the data in the > form of a BufferedImage makes no sense at all, so the API on the > TiffImageParser and supporting classes would need additional methods to > return arrays of floats. The good news here is that that requirement would > mean adding new methods to the classes rather than making significant changes > to existing classes. So the probability of unintended consequences or new > bugs in existing code would be minimized. > Specification details for floating-point are given in the main TIFF-6 > documentations and Adobe Photoshop TIFF Technical Note 3. > > I am willing to volunteer to make these changes provided that there is > interest and a high probability that my contributions would be evaluated and, > if suitable, integrated into the Commons Imaging code base. > Thank you for your attention in this matter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] kinow commented on pull request #72: IMAGING-251 support for TIFF floating-point formats
kinow commented on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629638135 Brilliant! Then tomorrow I will finish the review. Final things I'm looking at are - test coverage of new code (I lost track of how much is covered here) - possible issues for security (those `N/0`, or loading values from the data without checking boundaries, etc) - how much we broke backward compatibility—if any If nothing is wrong, then I will just squash. Several ways of doing it I think; I normally do with `git rebase -i HEAD~N`, where `N` is the number of commits I want to squash. Doesn't mean we need to squash to a single one, but we can probably combine a few ones. And add a changelog, and merge :-) Thanks for updating it so quickly! Bruno 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] coveralls edited a comment on pull request #72: IMAGING-251 support for TIFF floating-point formats
coveralls edited a comment on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-610094475 [](https://coveralls.io/builds/30831964) Coverage increased (+0.8%) to 75.883% when pulling **77b5936c414762d9a62823f6ead26561cdaf5d4e on gwlucastrig:master** into **1397ca92cd3268b434ad8a18529ee3544bbcf3c5 on apache:master**. 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] (IMAGING-251) Support TIFF standard floating point data
[ https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=434066=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434066 ] ASF GitHub Bot logged work on IMAGING-251: -- Author: ASF GitHub Bot Created on: 16/May/20 12:24 Start Date: 16/May/20 12:24 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-610094475 [](https://coveralls.io/builds/30831964) Coverage increased (+0.8%) to 75.883% when pulling **77b5936c414762d9a62823f6ead26561cdaf5d4e on gwlucastrig:master** into **1397ca92cd3268b434ad8a18529ee3544bbcf3c5 on apache:master**. 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: 434066) Time Spent: 12h 40m (was: 12.5h) > Support TIFF standard floating point data > - > > Key: IMAGING-251 > URL: https://issues.apache.org/jira/browse/IMAGING-251 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Gary Lucas >Priority: Major > Fix For: 1.x > > Attachments: ArizonaHillshade.jpg, Imaging252_USGS_n38w077.jpg > > Time Spent: 12h 40m > Remaining Estimate: 0h > > Commons Imaging does not support the floating-point format included in the > TIFF specification. There are prominent data sources that issue products in > this format. The ability to support this information would open up new > application areas for Commons Imaging. > TIFF is often used as a mechanism for distributing data from geophysical > applications in the form of GeoTIFF files. Some of this is not imagery, but > data. For example, the US Geological Survey is currently releasing > high-resolution elevation data grids for the 3DEP program under the name > Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant > potential commercial and academic applications. > To access this data means modifying the TIFF DataReaderStrips and > DataReaderTile classes to recognize floating point data (which is typically > indicated using TIFF tag #339, SampleFormat). Also, returning the data in the > form of a BufferedImage makes no sense at all, so the API on the > TiffImageParser and supporting classes would need additional methods to > return arrays of floats. The good news here is that that requirement would > mean adding new methods to the classes rather than making significant changes > to existing classes. So the probability of unintended consequences or new > bugs in existing code would be minimized. > Specification details for floating-point are given in the main TIFF-6 > documentations and Adobe Photoshop TIFF Technical Note 3. > > I am willing to volunteer to make these changes provided that there is > interest and a high probability that my contributions would be evaluated and, > if suitable, integrated into the Commons Imaging code base. > Thank you for your attention in this matter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IMAGING-251) Support TIFF standard floating point data
[ https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=434065=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434065 ] ASF GitHub Bot logged work on IMAGING-251: -- Author: ASF GitHub Bot Created on: 16/May/20 12:21 Start Date: 16/May/20 12:21 Worklog Time Spent: 10m Work Description: gwlucastrig commented on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629637256 @kinow I would prefer that you squash the commits. I didn't know that there was a git command that allowed you to do that. I renamed IPaletteEntry to simple PaletteEntry. I got a list of all Java files in the commons-imaging source code and saw that none of the others used the leading-I convention. So it makes sense to rename the class. 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: 434065) Time Spent: 12.5h (was: 12h 20m) > Support TIFF standard floating point data > - > > Key: IMAGING-251 > URL: https://issues.apache.org/jira/browse/IMAGING-251 > Project: Commons Imaging > Issue Type: New Feature > Components: Format: TIFF >Affects Versions: 1.x >Reporter: Gary Lucas >Priority: Major > Fix For: 1.x > > Attachments: ArizonaHillshade.jpg, Imaging252_USGS_n38w077.jpg > > Time Spent: 12.5h > Remaining Estimate: 0h > > Commons Imaging does not support the floating-point format included in the > TIFF specification. There are prominent data sources that issue products in > this format. The ability to support this information would open up new > application areas for Commons Imaging. > TIFF is often used as a mechanism for distributing data from geophysical > applications in the form of GeoTIFF files. Some of this is not imagery, but > data. For example, the US Geological Survey is currently releasing > high-resolution elevation data grids for the 3DEP program under the name > Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant > potential commercial and academic applications. > To access this data means modifying the TIFF DataReaderStrips and > DataReaderTile classes to recognize floating point data (which is typically > indicated using TIFF tag #339, SampleFormat). Also, returning the data in the > form of a BufferedImage makes no sense at all, so the API on the > TiffImageParser and supporting classes would need additional methods to > return arrays of floats. The good news here is that that requirement would > mean adding new methods to the classes rather than making significant changes > to existing classes. So the probability of unintended consequences or new > bugs in existing code would be minimized. > Specification details for floating-point are given in the main TIFF-6 > documentations and Adobe Photoshop TIFF Technical Note 3. > > I am willing to volunteer to make these changes provided that there is > interest and a high probability that my contributions would be evaluated and, > if suitable, integrated into the Commons Imaging code base. > Thank you for your attention in this matter. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] gwlucastrig commented on pull request #72: IMAGING-251 support for TIFF floating-point formats
gwlucastrig commented on pull request #72: URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-629637256 @kinow I would prefer that you squash the commits. I didn't know that there was a git command that allowed you to do that. I renamed IPaletteEntry to simple PaletteEntry. I got a list of all Java files in the commons-imaging source code and saw that none of the others used the leading-I convention. So it makes sense to rename the class. 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-compress] coveralls commented on pull request #101: Implement ZCompressorInputStreamTest without powermock
coveralls commented on pull request #101: URL: https://github.com/apache/commons-compress/pull/101#issuecomment-629636885 [](https://coveralls.io/builds/30831935) Coverage decreased (-0.02%) to 87.224% when pulling **a3702fa64defef7fa5bc0c3e182f6ead1b0807c3 on theobisproject:remove-powermock** into **a5ccbd6c55f8df73aa5c13f48aed8d363c722c3a on apache:master**. 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-compress] theobisproject opened a new pull request #101: Implement ZCompressorInputStreamTest without powermock
theobisproject opened a new pull request #101: URL: https://github.com/apache/commons-compress/pull/101 Noticed this test is skipped while checking the unit tests log. The mockito dependency was transitive before. Is there a Jira ticket needed for a change like 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
[jira] [Work logged] (COMPRESS-404) Add Path equivalents to TarArchiveEntry, with methods using File delegating to equivalents
[ https://issues.apache.org/jira/browse/COMPRESS-404?focusedWorklogId=434061=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434061 ] ASF GitHub Bot logged work on COMPRESS-404: --- Author: ASF GitHub Bot Created on: 16/May/20 12:01 Start Date: 16/May/20 12:01 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #97: URL: https://github.com/apache/commons-compress/pull/97#issuecomment-623476662 [](https://coveralls.io/builds/30831849) Coverage decreased (-0.1%) to 87.091% when pulling **afaaacf8ce5ffd0735c4b5e70259068327741ab0 on theobisproject:COMPRESS-404** into **69de512db43c9ca35da11664a1502702353a6fdd on apache:master**. 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: 434061) Time Spent: 2h 10m (was: 2h) > Add Path equivalents to TarArchiveEntry, with methods using File delegating > to equivalents > -- > > Key: COMPRESS-404 > URL: https://issues.apache.org/jira/browse/COMPRESS-404 > Project: Commons Compress > Issue Type: Sub-task >Reporter: Simon Spero >Priority: Minor > Time Spent: 2h 10m > Remaining Estimate: 0h > > (This is a reasonable place to start, as Paths give better access to > tar-relevant metadata on unix system). > Symlink info is easier to obtain > Unix based Paths allow access to useful attributes under "unix:*" > - numeric uid and gid > - string owner and group names > - mtime,ctime,atime > - numeric mode > - numeric dev and inode > - numeric rdev > - Linux, Solaris and Windows allow access to extended attributes > (MacOS X xattrs aren't supported as of jdk 9) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COMPRESS-404) Add Path equivalents to TarArchiveEntry, with methods using File delegating to equivalents
[ https://issues.apache.org/jira/browse/COMPRESS-404?focusedWorklogId=434060=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434060 ] ASF GitHub Bot logged work on COMPRESS-404: --- Author: ASF GitHub Bot Created on: 16/May/20 12:01 Start Date: 16/May/20 12:01 Worklog Time Spent: 10m Work Description: theobisproject commented on pull request #97: URL: https://github.com/apache/commons-compress/pull/97#issuecomment-629634892 In the last commit I removed the delegation from the File constructor to the Path constructor so we keep the backwards compatibility. Also this should address all previous made comments. 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: 434060) Time Spent: 2h (was: 1h 50m) > Add Path equivalents to TarArchiveEntry, with methods using File delegating > to equivalents > -- > > Key: COMPRESS-404 > URL: https://issues.apache.org/jira/browse/COMPRESS-404 > Project: Commons Compress > Issue Type: Sub-task >Reporter: Simon Spero >Priority: Minor > Time Spent: 2h > Remaining Estimate: 0h > > (This is a reasonable place to start, as Paths give better access to > tar-relevant metadata on unix system). > Symlink info is easier to obtain > Unix based Paths allow access to useful attributes under "unix:*" > - numeric uid and gid > - string owner and group names > - mtime,ctime,atime > - numeric mode > - numeric dev and inode > - numeric rdev > - Linux, Solaris and Windows allow access to extended attributes > (MacOS X xattrs aren't supported as of jdk 9) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] theobisproject commented on pull request #97: COMPRESS-404: Use java.nio.Path in TarArchiveEntry
theobisproject commented on pull request #97: URL: https://github.com/apache/commons-compress/pull/97#issuecomment-629634892 In the last commit I removed the delegation from the File constructor to the Path constructor so we keep the backwards compatibility. Also this should address all previous made comments. 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-compress] coveralls edited a comment on pull request #97: COMPRESS-404: Use java.nio.Path in TarArchiveEntry
coveralls edited a comment on pull request #97: URL: https://github.com/apache/commons-compress/pull/97#issuecomment-623476662 [](https://coveralls.io/builds/30831849) Coverage decreased (-0.1%) to 87.091% when pulling **afaaacf8ce5ffd0735c4b5e70259068327741ab0 on theobisproject:COMPRESS-404** into **69de512db43c9ca35da11664a1502702353a6fdd on apache:master**. 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] (LANG-1543) ToStringBuilder.reflectionToString doesnt render nested maps correctly.
Swaraj Pal created LANG-1543:
Summary: ToStringBuilder.reflectionToString doesnt render nested
maps correctly.
Key: LANG-1543
URL: https://issues.apache.org/jira/browse/LANG-1543
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.10
Reporter: Swaraj Pal
Nested Maps are not converted correctly as JSON using
ToStringBuilder.reflectToString commons-lang3:3.10 . Please find below the
example to reproduce:-
Class:
{code:java}
public class Student {
private String name;
private Map education;
//getters and setters...
public String toString() {
return ToStringBuilder.reflectionToString(this,
ToStringStyle.JSON_STYLE);
}}
{code}
Driver test:
{code:java}
Student p = new Student();
p.setName("como");
Map educationMap = new HashMap();
educationMap.put("primary", "school");
educationMap.put("graduation", "B.S.");
p.setEducation(educationMap);
System.out.println(p.toString());
{code}
The toString() prints
{code:java}
{"education":{graduation=B.S., primary=school},"name":"como"}
{code}
but I expect as JSON it should print as below (with proper key,value pairs as
field names and values)
{code:java}
{"education":{"graduation": "B.S.", "primary":"school"},"name":"como"}
{code}
Suggested fix:
I can create a Pull request for this issue handling Maps appending logic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1542) ToStringBuilder.reflectionToString - Wrong JSON format when object has a List of Enum
[
https://issues.apache.org/jira/browse/LANG-1542?focusedWorklogId=434053=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434053
]
ASF GitHub Bot logged work on LANG-1542:
Author: ASF GitHub Bot
Created on: 16/May/20 11:08
Start Date: 16/May/20 11:08
Worklog Time Spent: 10m
Work Description: swarajsaaj commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426143710
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
Hello, this will restrict only enums to be appended from a collection, a
list of other types (e.g. Collection of Integers or Strings) will be ignored.
This filter should be removed to allow all types of collections (or we should
allow buffer.append(col1) at last line of method to run for other types, either
way)
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: 434053)
Time Spent: 40m (was: 0.5h)
> ToStringBuilder.reflectionToString - Wrong JSON format when object has a List
> of Enum
> -
>
> Key: LANG-1542
> URL: https://issues.apache.org/jira/browse/LANG-1542
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.10
> Environment: Open JDK 1.8
>Reporter: Trần Ngọc Khoa
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I'm trying to log an object to console with JSON style using
> {{ToStringBuilder.reflectionToString}} from {{commons-lang3:3.10}} but it
> seems generated a wrong JSON format.
> Problem happening when I have a list of enums in my field list.
>
> {code:java}
> This is the class:
> public class Person {
> private long id;
> private String name;
> private List listEnums;
> //getter and setter
> public String toString(){
> return ToStringBuilder.reflectionToString(this,
> ToStringStyle.JSON_STYLE);
> }
> }
> {code}
>
> And {{MyEnum}}:
> {code:java}
> public enum MyEnum {
> FOOD,
> SPORT,
> BOOK,
> MUSIC
> }{code}
> When I call {{toString()}} of Person object. It shows like this
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": [FRIDAY, MONDAY, TUESDAY]
> }{code}
>
> What I expected is:
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": ["FRIDAY", "MONDAY", "TUESDAY"]
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] swarajsaaj commented on a change in pull request #530: LANG-1542: ToStringBuilder.reflectionToString - Wrong JSON format for List
swarajsaaj commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426143710
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
Hello, this will restrict only enums to be appended from a collection, a
list of other types (e.g. Collection of Integers or Strings) will be ignored.
This filter should be removed to allow all types of collections (or we should
allow buffer.append(col1) at last line of method to run for other types, either
way)
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-1542) ToStringBuilder.reflectionToString - Wrong JSON format when object has a List of Enum
[
https://issues.apache.org/jira/browse/LANG-1542?focusedWorklogId=434050=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434050
]
ASF GitHub Bot logged work on LANG-1542:
Author: ASF GitHub Bot
Created on: 16/May/20 11:05
Start Date: 16/May/20 11:05
Worklog Time Spent: 10m
Work Description: swarajsaaj commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426143710
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
This will restrict only enums to be appended in a collection, a list of
other types (e.g. Collection or Collection) will be ignored.
This filter should be removed.
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: 434050)
Time Spent: 20m (was: 10m)
> ToStringBuilder.reflectionToString - Wrong JSON format when object has a List
> of Enum
> -
>
> Key: LANG-1542
> URL: https://issues.apache.org/jira/browse/LANG-1542
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.10
> Environment: Open JDK 1.8
>Reporter: Trần Ngọc Khoa
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I'm trying to log an object to console with JSON style using
> {{ToStringBuilder.reflectionToString}} from {{commons-lang3:3.10}} but it
> seems generated a wrong JSON format.
> Problem happening when I have a list of enums in my field list.
>
> {code:java}
> This is the class:
> public class Person {
> private long id;
> private String name;
> private List listEnums;
> //getter and setter
> public String toString(){
> return ToStringBuilder.reflectionToString(this,
> ToStringStyle.JSON_STYLE);
> }
> }
> {code}
>
> And {{MyEnum}}:
> {code:java}
> public enum MyEnum {
> FOOD,
> SPORT,
> BOOK,
> MUSIC
> }{code}
> When I call {{toString()}} of Person object. It shows like this
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": [FRIDAY, MONDAY, TUESDAY]
> }{code}
>
> What I expected is:
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": ["FRIDAY", "MONDAY", "TUESDAY"]
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1542) ToStringBuilder.reflectionToString - Wrong JSON format when object has a List of Enum
[
https://issues.apache.org/jira/browse/LANG-1542?focusedWorklogId=434051=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434051
]
ASF GitHub Bot logged work on LANG-1542:
Author: ASF GitHub Bot
Created on: 16/May/20 11:05
Start Date: 16/May/20 11:05
Worklog Time Spent: 10m
Work Description: swarajsaaj commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426143710
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
This will restrict only enums to be appended in a collection, a list of
other types (e.g. Collection of Integers or Strings) will be ignored. This
filter should be removed.
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: 434051)
Time Spent: 0.5h (was: 20m)
> ToStringBuilder.reflectionToString - Wrong JSON format when object has a List
> of Enum
> -
>
> Key: LANG-1542
> URL: https://issues.apache.org/jira/browse/LANG-1542
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.10
> Environment: Open JDK 1.8
>Reporter: Trần Ngọc Khoa
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I'm trying to log an object to console with JSON style using
> {{ToStringBuilder.reflectionToString}} from {{commons-lang3:3.10}} but it
> seems generated a wrong JSON format.
> Problem happening when I have a list of enums in my field list.
>
> {code:java}
> This is the class:
> public class Person {
> private long id;
> private String name;
> private List listEnums;
> //getter and setter
> public String toString(){
> return ToStringBuilder.reflectionToString(this,
> ToStringStyle.JSON_STYLE);
> }
> }
> {code}
>
> And {{MyEnum}}:
> {code:java}
> public enum MyEnum {
> FOOD,
> SPORT,
> BOOK,
> MUSIC
> }{code}
> When I call {{toString()}} of Person object. It shows like this
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": [FRIDAY, MONDAY, TUESDAY]
> }{code}
>
> What I expected is:
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": ["FRIDAY", "MONDAY", "TUESDAY"]
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] swarajsaaj commented on a change in pull request #530: LANG-1542: ToStringBuilder.reflectionToString - Wrong JSON format for List
swarajsaaj commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426143710
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
This will restrict only enums to be appended in a collection, a list of
other types (e.g. Collection of Integers or Strings) will be ignored. This
filter should be removed.
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-lang] swarajsaaj commented on a change in pull request #530: LANG-1542: ToStringBuilder.reflectionToString - Wrong JSON format for List
swarajsaaj commented on a change in pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#discussion_r426143710
##
File path: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
##
@@ -635,6 +635,14 @@ protected void appendDetail(final StringBuffer buffer,
final String fieldName, f
* {@code toString}, not {@code null}
*/
protected void appendDetail(final StringBuffer buffer, final String
fieldName, final Collection coll) {
+if (coll != null && !coll.isEmpty()) {
+coll.stream().findFirst()
+.map(Object::getClass)
+.filter(Class::isEnum)
Review comment:
This will restrict only enums to be appended in a collection, a list of
other types (e.g. Collection or Collection) will be ignored.
This filter should be removed.
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-collections] Claudenw commented on a change in pull request #160: add Simple bloom filter
Claudenw commented on a change in pull request #160:
URL:
https://github.com/apache/commons-collections/pull/160#discussion_r426135325
##
File path:
src/test/java/org/apache/commons/collections4/bloomfilter/hasher/HasherBuilderTest.java
##
@@ -58,10 +62,9 @@ public Builder with(byte[] item) {
public void withCharSequenceTest() {
final String ascii = "plain";
final String extended = getExtendedString();
-for (final String s : new String[] {ascii, extended}) {
-for (final Charset cs : new Charset[] {
-StandardCharsets.ISO_8859_1, StandardCharsets.UTF_8,
StandardCharsets.UTF_16
-}) {
+for (final String s : new String[] { ascii, extended }) {
+for (final Charset cs : new Charset[] {
StandardCharsets.ISO_8859_1, StandardCharsets.UTF_8,
+StandardCharsets.UTF_16 }) {
TestBuilder builder = new TestBuilder();
Review comment:
I can not figure out how to get Eclipse to format the line so that the
continued array initialization (line 67 above) is not indented an extra 4
space. Anyone have any idea how to do 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-collections] coveralls edited a comment on pull request #159: [WIP] Updated the fail() exceptions with Junit5.
coveralls edited a comment on pull request #159: URL: https://github.com/apache/commons-collections/pull/159#issuecomment-625612511 [](https://coveralls.io/builds/30830134) Coverage remained the same at 90.123% when pulling **c2feee10ee74dc81e74892ba65ae5d215886db1b on dota17:junit5WithExceptions** into **a3eb3be4b0063351115a02f56c884b31a6cc8bff on apache:master**. 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-collections] Claudenw commented on a change in pull request #160: add Simple bloom filter
Claudenw commented on a change in pull request #160:
URL:
https://github.com/apache/commons-collections/pull/160#discussion_r426132251
##
File path:
src/main/java/org/apache/commons/collections4/bloomfilter/SimpleBloomFilter.java
##
@@ -0,0 +1,127 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.collections4.bloomfilter;
+
+import java.util.function.Function;
+
+import org.apache.commons.collections4.bloomfilter.hasher.DynamicHasher;
+import org.apache.commons.collections4.bloomfilter.hasher.Hasher;
+import org.apache.commons.collections4.bloomfilter.hasher.Shape;
+import
org.apache.commons.collections4.bloomfilter.hasher.function.Murmur128x64Cyclic;
+
+/**
+ * A bloom filter that uses a BitSetBloomFilter to create a Bloom filter that
+ * can merge instances of a specific class.
+ *
+ * @param The Class to merge.
+ * @since 4.5
+ */
+public class SimpleBloomFilter extends BitSetBloomFilter implements
BloomFilter {
+
+/**
+ * The function that converts the instance of T to the SimpleBuilder.
+ *
+ * If the object T is to be considered as a single item in the filter then
+ * function must create the {@code SimpleBuilder} and only call a single
{@code with()}
+ * method.
+ *
+ * If the object T is to be considered as several items then the function
must
+ * create the {@code SimpleBuilder} and call the {@code with()} method
once for each item.
+ */
+private Function func;
+
+/**
+ * Constructs a SimpleBloomFilter from the shape and function. This
constructor
+ * creates an empty Bloom filter.
+ * @param hasher the Hasher to use.
+ * @param shape the Shape of the Bloom filter.
+ * @param func a Function to convert T to a SimpleBuilder.
+ * @see #func
+ */
+public SimpleBloomFilter(Hasher hasher, Shape shape, Function func) {
+super(hasher, shape);
+this.func = func;
+}
+
+/**
+ * Constructs a SimpleBloomFilter from the shape and function. This
constructor
+ * creates an empty Bloom filter.
+ * @param shape the Shape of the Bloom filter.
+ * @param func a Function to convert T to a SimpleBuilder.
+ * @see #func
+ */
+public SimpleBloomFilter(Shape shape, Function func) {
+super(shape);
+this.func = func;
+}
+
+/**
+ * Constructs a SimpleBloomFilter from the shape, function and a data
object.
+ * This constructor creates an Bloom filter populated with the data from
the
+ * {@code data} parameter.
+ * @param shape the Shape of the Bloom filter.
+ * @param func a Function to convert T to a SimpleBuilder.
+ * @param data the data object to populate the filter with.
+ * @see #func
+ */
+public SimpleBloomFilter(Shape shape, Function func, T
data) {
+this(shape, func);
+this.merge( data );
Review comment:
The BloomFilter constructor that takes a Hasher effectively does the
same thing: creates the container and populates it. Should that also be
removed? Perhaps a Jira ticket should be opened for that change.
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-collections] aherbert commented on a change in pull request #160: add Simple bloom filter
aherbert commented on a change in pull request #160:
URL:
https://github.com/apache/commons-collections/pull/160#discussion_r426131821
##
File path:
src/test/java/org/apache/commons/collections4/bloomfilter/hasher/HasherBuilderTest.java
##
@@ -58,10 +62,9 @@ public Builder with(byte[] item) {
public void withCharSequenceTest() {
final String ascii = "plain";
final String extended = getExtendedString();
-for (final String s : new String[] {ascii, extended}) {
-for (final Charset cs : new Charset[] {
-StandardCharsets.ISO_8859_1, StandardCharsets.UTF_8,
StandardCharsets.UTF_16
-}) {
+for (final String s : new String[] { ascii, extended }) {
+for (final Charset cs : new Charset[] {
StandardCharsets.ISO_8859_1, StandardCharsets.UTF_8,
+StandardCharsets.UTF_16 }) {
TestBuilder builder = new TestBuilder();
Review comment:
If you are using Eclipse to format the entire file then there is a
problem with your Eclipse formatting since it changed what was already in the
file. There is no formatting file that has been applied to the collections
source code. All formatting is done manually and must pass the checkstyle
rules. These rules are not as strict as they could be but that is for another
discussion.
In general you should only format new additions to existing source. If you
reformat the existing source then you are adding noise to the PR.
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-collections] Claudenw commented on a change in pull request #160: add Simple bloom filter
Claudenw commented on a change in pull request #160:
URL:
https://github.com/apache/commons-collections/pull/160#discussion_r426131447
##
File path:
src/test/java/org/apache/commons/collections4/bloomfilter/hasher/HasherBuilderTest.java
##
@@ -58,10 +62,9 @@ public Builder with(byte[] item) {
public void withCharSequenceTest() {
final String ascii = "plain";
final String extended = getExtendedString();
-for (final String s : new String[] {ascii, extended}) {
-for (final Charset cs : new Charset[] {
-StandardCharsets.ISO_8859_1, StandardCharsets.UTF_8,
StandardCharsets.UTF_16
-}) {
+for (final String s : new String[] { ascii, extended }) {
+for (final Charset cs : new Charset[] {
StandardCharsets.ISO_8859_1, StandardCharsets.UTF_8,
+StandardCharsets.UTF_16 }) {
TestBuilder builder = new TestBuilder();
Review comment:
I tried to format using the src/conf/checkstyle.xml and the Eclipse
checkstyle plugin. Is that checkstyle.xml up to date or is there a problem
with my Eclipse checkstyle configuration?
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-collections] aherbert commented on a change in pull request #160: add Simple bloom filter
aherbert commented on a change in pull request #160:
URL:
https://github.com/apache/commons-collections/pull/160#discussion_r426131444
##
File path:
src/test/java/org/apache/commons/collections4/bloomfilter/hasher/HasherBuilderTest.java
##
@@ -29,7 +32,8 @@
/**
* Tests the
- * {@link org.apache.commons.collections4.bloomfilter.hasher.Hasher.Builder
Hasher.Builder}.
+ * {@link org.apache.commons.collections4.bloomfilter.hasher.Hasher.Builder
+ * Hasher.Builder}.
Review comment:
I think I was not clear. The `byte[]` is just the part of the item T
that you want to hash. So you have two situations where you convert the item T
to either:
1. T -> List
2. T -> byte[]
These are then fed into the DynamicHasher. In case 1 you have a byte[] for
each property or part of T you want to add to the Bloom filter. In case 2 you
are adding the entire item T as a single entity.
You could group 1 and 2 into the same situation where I concatenate the
parts that would make up the List to a single longer array and create a
SimpleBuilder containing the result. The idea is the same: a single item T
should only add one set of indices to the Bloom filter.
I do not suggest by-passing the Hasher. I suggest making it easier to
specify case 2. Thus as a user I can convert my item to a binary form `byte[]`
then the SimpleBloomFilter would do the rest of the work to hash the binary
form and create a sequence of indexes for the filter shape.
This is why I suggested a `Function` version. The `byte[]` would
be used internally by the SimpleBloomFilter to create a Hasher and generate
indices for the Shape. Essentially this would be:
```java
byte[] b = ...;
Hasher h = new SimpleBuilder().with(b).build();
```
But this could be done using a specialised route that avoids all the object
creation, for example using a variant of DynamicHasher that has a single
`byte[]` to hash:
```java
byte[] b = ...; // The SimpleBloomFilter converts T to byte[]
HashFunction hf = ...; // From the SimpleBloomFilter
Hasher h = new DynamicHasher(hf, b);
```
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-collections] Claudenw commented on a change in pull request #160: add Simple bloom filter
Claudenw commented on a change in pull request #160:
URL:
https://github.com/apache/commons-collections/pull/160#discussion_r426130303
##
File path:
src/test/java/org/apache/commons/collections4/bloomfilter/hasher/HasherBuilderTest.java
##
@@ -29,7 +32,8 @@
/**
* Tests the
- * {@link org.apache.commons.collections4.bloomfilter.hasher.Hasher.Builder
Hasher.Builder}.
+ * {@link org.apache.commons.collections4.bloomfilter.hasher.Hasher.Builder
+ * Hasher.Builder}.
Review comment:
The problem with converting T directly to a byte[] is two fold.
First, to do the conversion to the byte[] you need to know the Shape.
Second, it confuses the architecture. In the architecture
The Hasher is responsible for
- hashing one or more items.
- being able to replay the hash of the item(s).
- converting the hash(es) into a collection of indexes into a bit vector.
The Shape is responsible for:
- providing the number of bits that is represented by each item in the Bloom
filter, also known as the number of hash functions, or _k_.
- providing the length of the bit vector, also known as _m_.
- providing the number of expected items in the Bloom filter, also known as
_n_.
- calculating the probability of false positive results, also known as _p_.
The Bloom filter is responsible for:
- the implementation and management of a logical bit vector of _m_ bits.
- determining if another Bloom filter is contained in this filter.
`contains( BloomFilter )`
- determining if the items contained in Hasher, taken as a whole, are
contained in this filter. `contains( Hasher )`. This is equivalent to
constructing a second Bloom filter and calling the above but without the
overhead.
- merging another bloom filter into this filter. `merge( BloomFilter )`
- merging the items contained in a Hasher, taken as a whole, into this
filter. `merge( Hasher )`. As with the contains method this is equivalent to
constructing a Bloom filter and calling the above.
By using a function to go directly from T to byte[], the the function has to
know the Shape of the filter that it is going to be used in. Under the current
architecture the Hasher does not care what the Shape is until the collection of
indexes for a specific Shape are requested.
The SimpleHasher was chosen because it defines the underlying hash function
(Murmur128x64Cyclic), any Hasher implementation would be an acceptable return
value for the Function in the constructor.
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-1542) ToStringBuilder.reflectionToString - Wrong JSON format when object has a List of Enum
[
https://issues.apache.org/jira/browse/LANG-1542?focusedWorklogId=434034=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-434034
]
ASF GitHub Bot logged work on LANG-1542:
Author: ASF GitHub Bot
Created on: 16/May/20 07:45
Start Date: 16/May/20 07:45
Worklog Time Spent: 10m
Work Description: coveralls commented on pull request #530:
URL: https://github.com/apache/commons-lang/pull/530#issuecomment-629603951
[](https://coveralls.io/builds/30829712)
Coverage increased (+0.002%) to 95.093% when pulling
**4391efd0b40a2455c84e8950d70b3668b7992bf6 on TranNgocKhoa:master** into
**f6923510352fc3fbfad68bc6c5ac5258a34671b7 on apache:master**.
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: 434034)
Remaining Estimate: 0h
Time Spent: 10m
> ToStringBuilder.reflectionToString - Wrong JSON format when object has a List
> of Enum
> -
>
> Key: LANG-1542
> URL: https://issues.apache.org/jira/browse/LANG-1542
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.10
> Environment: Open JDK 1.8
>Reporter: Trần Ngọc Khoa
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm trying to log an object to console with JSON style using
> {{ToStringBuilder.reflectionToString}} from {{commons-lang3:3.10}} but it
> seems generated a wrong JSON format.
> Problem happening when I have a list of enums in my field list.
>
> {code:java}
> This is the class:
> public class Person {
> private long id;
> private String name;
> private List listEnums;
> //getter and setter
> public String toString(){
> return ToStringBuilder.reflectionToString(this,
> ToStringStyle.JSON_STYLE);
> }
> }
> {code}
>
> And {{MyEnum}}:
> {code:java}
> public enum MyEnum {
> FOOD,
> SPORT,
> BOOK,
> MUSIC
> }{code}
> When I call {{toString()}} of Person object. It shows like this
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": [FRIDAY, MONDAY, TUESDAY]
> }{code}
>
> What I expected is:
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": ["FRIDAY", "MONDAY", "TUESDAY"]
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] coveralls commented on pull request #530: LANG-1542: ToStringBuilder.reflectionToString - Wrong JSON format for List
coveralls commented on pull request #530: URL: https://github.com/apache/commons-lang/pull/530#issuecomment-629603951 [](https://coveralls.io/builds/30829712) Coverage increased (+0.002%) to 95.093% when pulling **4391efd0b40a2455c84e8950d70b3668b7992bf6 on TranNgocKhoa:master** into **f6923510352fc3fbfad68bc6c5ac5258a34671b7 on apache:master**. 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] (LANG-1542) ToStringBuilder.reflectionToString - Wrong JSON format when object has a List of Enum
[
https://issues.apache.org/jira/browse/LANG-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108900#comment-17108900
]
Trần Ngọc Khoa commented on LANG-1542:
--
[~ggregory] I created a pull request
> ToStringBuilder.reflectionToString - Wrong JSON format when object has a List
> of Enum
> -
>
> Key: LANG-1542
> URL: https://issues.apache.org/jira/browse/LANG-1542
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.10
> Environment: Open JDK 1.8
>Reporter: Trần Ngọc Khoa
>Priority: Major
>
> I'm trying to log an object to console with JSON style using
> {{ToStringBuilder.reflectionToString}} from {{commons-lang3:3.10}} but it
> seems generated a wrong JSON format.
> Problem happening when I have a list of enums in my field list.
>
> {code:java}
> This is the class:
> public class Person {
> private long id;
> private String name;
> private List listEnums;
> //getter and setter
> public String toString(){
> return ToStringBuilder.reflectionToString(this,
> ToStringStyle.JSON_STYLE);
> }
> }
> {code}
>
> And {{MyEnum}}:
> {code:java}
> public enum MyEnum {
> FOOD,
> SPORT,
> BOOK,
> MUSIC
> }{code}
> When I call {{toString()}} of Person object. It shows like this
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": [FRIDAY, MONDAY, TUESDAY]
> }{code}
>
> What I expected is:
> {code:java}
> {
> "id": 1,
> "name": "Karl",
> "listEnums": ["FRIDAY", "MONDAY", "TUESDAY"]
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] TranNgocKhoa opened a new pull request #530: Fix ToStringBuilder.reflectionToString - Wrong JSON format for List
TranNgocKhoa opened a new pull request #530: URL: https://github.com/apache/commons-lang/pull/530 I add some code to fix an issue about **ToStringBuilder.reflectionToString - Wrong JSON format when object has a List of Enum**. Link issue: https://issues.apache.org/jira/browse/LANG-1542 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
