[jira] [Commented] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread Bruno P. Kinoshita (JIRA)


[ 
https://issues.apache.org/jira/browse/IMAGING-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859098#comment-16859098
 ] 

Bruno P. Kinoshita commented on IMAGING-134:


Provided some initial feedback on GitHub on style, typos, etc. But will check 
test coverage as we have some if/elses with arrays, and recently had a couple 
CVE's due to infinite loops or not checking some conditions in if/else blocks.

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread Bruno P. Kinoshita (JIRA)


[ 
https://issues.apache.org/jira/browse/IMAGING-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859097#comment-16859097
 ] 

Bruno P. Kinoshita commented on IMAGING-134:


I got some description of reset/restart markers from other projects issues 
(Golang has an open issue similar to this one I think), and some useful 
information from StackOverflow answers. It looks like some useful information 
is hidden away in paid versions of ISO documents (may have access through work 
research subscriptions).

But my understanding of this change was that we are adding the support for the 
reset markers, and some extra logic in the code handling the segments with the 
RST markers. It looks to me as if instead of going through a single input 
stream with the whole segment data, we split it by the RST markers (based on 
the length of the markers) into multiple blocks, and then process each block 
with MCU's (minimum coded units, or tiles).

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256361=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256361
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 03:54
Start Date: 08/Jun/19 03:54
Worklog Time Spent: 10m 
  Work Description: kinow commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291792699
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -71,11 +73,23 @@ public boolean beginSOS() {
 public void visitSOS(final int marker, final byte[] markerBytes, final 
byte[] imageData) {
 final ByteArrayInputStream is = new ByteArrayInputStream(imageData);
 try {
+// read the scan header
 final int segmentLength = read2Bytes("segmentLength", is, "Not a 
Valid JPEG File", getByteOrder());
 final byte[] sosSegmentBytes = readBytes("SosSegment",
 is, segmentLength - 2, "Not a Valid JPEG File");
 sosSegment = new SosSegment(marker, sosSegmentBytes);
 
+// read the payload of the scan, this is the remainder of image 
data after the header
+// the payload contains the entropy-encoded segments (or ECS) 
divded by RST markers
 
 Review comment:
   s/divded/divided
 

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: 256361)
Time Spent: 1h 20m  (was: 1h 10m)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256357=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256357
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 03:54
Start Date: 08/Jun/19 03:54
Worklog Time Spent: 10m 
  Work Description: kinow commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793143
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
+ */
+static List getIntervalStartPositions(final int[] scanPayload) {
+final List intervalStarts = new ArrayList();
+intervalStarts.add( 0 );
+boolean foundFF = false;
+boolean foundD0toD7 = false;
+int pos = 0;
+while ( pos < scanPayload.length ) {
 
 Review comment:
   `while (pos < scanPayload.length) {`, spaces
 

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: 256357)
Time Spent: 50m  (was: 40m)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--

[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256367=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256367
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 03:54
Start Date: 08/Jun/19 03:54
Worklog Time Spent: 10m 
  Work Description: kinow commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793193
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
 
 Review comment:
   What about moving the longer text to the main body of the javadocs comment? 
i.e.
   
   ```java
* Returns the positions of where each interval in the provided array 
starts. The number
* of start positions is also the count of intervals while the number of 
restart markers
* found is equal to the number of start positions minus one (because 
restart markers
* are between intervals).
* @param scanPayload array to examine
* @return the start positions
   ```
 

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: 256367)
Time Spent: 2h 10m  (was: 2h)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> 

[GitHub] [commons-imaging] kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling 
for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793042
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
+ */
+static List getIntervalStartPositions(final int[] scanPayload) {
+final List intervalStarts = new ArrayList();
+intervalStarts.add( 0 );
+boolean foundFF = false;
+boolean foundD0toD7 = false;
+int pos = 0;
+while ( pos < scanPayload.length ) {
+if ( foundFF == true ) {
 
 Review comment:
   `if ( foundFF ) {`


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


With regards,
Apache Git Services


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256359=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256359
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 03:54
Start Date: 08/Jun/19 03:54
Worklog Time Spent: 10m 
  Work Description: kinow commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793200
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -122,8 +134,21 @@ public void visitSOS(final int marker, final byte[] 
markerBytes, final byte[] im
 }
 final DataBuffer dataBuffer = raster.getDataBuffer();
 
+final JpegInputStream[] bitInputStreams = 
splitByRstMarkers(scanPayload);
+int bitInputStreamCount = 0;
+JpegInputStream bitInputStream = bitInputStreams[0];
+
 for (int y1 = 0; y1 < vSize * yMCUs; y1 += vSize) {
 for (int x1 = 0; x1 < hSize * xMCUs; x1 += hSize) {
+// provide a the next interval if an interval is read 
until it's end
+// as long there are unread intervals available
+if (bitInputStream.hasNext() == false) {
 
 Review comment:
   `if (!bitInputStream.hasNext()) {`
 

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: 256359)
Time Spent: 1h  (was: 50m)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] [commons-imaging] kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling 
for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793031
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
+ */
+static List getIntervalStartPositions(final int[] scanPayload) {
+final List intervalStarts = new ArrayList();
+intervalStarts.add( 0 );
+boolean foundFF = false;
+boolean foundD0toD7 = false;
+int pos = 0;
+while ( pos < scanPayload.length ) {
+if ( foundFF == true ) {
+// found 0xFF D0 .. 0xFF D7 => RST marker
+if ( scanPayload[ pos ] >= ( 0xff & JpegConstants.RST0_MARKER 
) &&
+scanPayload[ pos ] <= ( 0xff & JpegConstants.RST7_MARKER ) 
) {
+foundD0toD7 = true;
+} else { // found 0xFF followed by something else => no RST 
marker
+foundFF = false;
+}
+}
+
+if ( scanPayload[ pos ] == 0xFF ) {
+foundFF = true;
+}
+
+// true if one of the RST markers was found
+if ( foundFF == true && foundD0toD7 == true ) {
 
 Review comment:
   `if (foundFF && foundD0toD7)`


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


With regards,
Apache Git Services


[GitHub] [commons-imaging] kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling 
for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291792933
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegInputStream.java
 ##
 @@ -15,31 +15,39 @@
 
 package org.apache.commons.imaging.formats.jpeg.decoder;
 
-import java.io.IOException;
-import java.io.InputStream;
-
 import org.apache.commons.imaging.ImageReadException;
 import org.apache.commons.imaging.formats.jpeg.JpegConstants;
 
 class JpegInputStream {
 // Figure F.18, F.2.2.5, page 111 of ITU-T T.81
-private final InputStream is;
+private final int[] interval;
+// next position in the array to read
+private int nextPos;
 private int cnt;
 private int b;
 
-JpegInputStream(final InputStream is) {
-this.is = is;
+JpegInputStream(final int[] interval) {
+this.interval = interval;
 
 Review comment:
   `this.interval = Arrays.copyOf(interval, interval.length);` to prevent 
mutability issues? Not sure if there is any risk (i.e. if internal only, 
probably not at risk, but may be still a good idea to play defensively here)


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


With regards,
Apache Git Services


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256358=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256358
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 03:54
Start Date: 08/Jun/19 03:54
Worklog Time Spent: 10m 
  Work Description: kinow commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793148
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
+ */
+static List getIntervalStartPositions(final int[] scanPayload) {
+final List intervalStarts = new ArrayList();
+intervalStarts.add( 0 );
 
 Review comment:
   `intervalStarts.add(0);`, spaces
 

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: 256358)
Time Spent: 1h  (was: 50m)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256365=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256365
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 03:54
Start Date: 08/Jun/19 03:54
Worklog Time Spent: 10m 
  Work Description: kinow commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291792959
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegInputStream.java
 ##
 @@ -57,4 +65,19 @@ public int nextBit() throws IOException, ImageReadException 
{
 b <<= 1;
 return bit;
 }
+
+/**
+ * Returns the value from current field (as {@code InputStream.read()} 
would do)
+ * and set the position of the pointer to the next field to read.
+ * @return
+ * @throws IllegalStateException if the stream hasn't any other value.
+ */
+int read() {
+if (this.hasNext() == false) {
 
 Review comment:
   `if (!this.hasNext())`
 

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: 256365)
Time Spent: 1h 50m  (was: 1h 40m)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256363=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256363
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 03:54
Start Date: 08/Jun/19 03:54
Worklog Time Spent: 10m 
  Work Description: kinow commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793031
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
+ */
+static List getIntervalStartPositions(final int[] scanPayload) {
+final List intervalStarts = new ArrayList();
+intervalStarts.add( 0 );
+boolean foundFF = false;
+boolean foundD0toD7 = false;
+int pos = 0;
+while ( pos < scanPayload.length ) {
+if ( foundFF == true ) {
+// found 0xFF D0 .. 0xFF D7 => RST marker
+if ( scanPayload[ pos ] >= ( 0xff & JpegConstants.RST0_MARKER 
) &&
+scanPayload[ pos ] <= ( 0xff & JpegConstants.RST7_MARKER ) 
) {
+foundD0toD7 = true;
+} else { // found 0xFF followed by something else => no RST 
marker
+foundFF = false;
+}
+}
+
+if ( scanPayload[ pos ] == 0xFF ) {
+foundFF = true;
+}
+
+// true if one of the RST markers was found
+if ( foundFF == true && foundD0toD7 == true ) {
 
 Review comment:
   `if (foundFF && foundD0toD7)`
 

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: 256363)
Time Spent: 1h 40m  (was: 1.5h)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> 

[GitHub] [commons-imaging] kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling 
for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291792959
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegInputStream.java
 ##
 @@ -57,4 +65,19 @@ public int nextBit() throws IOException, ImageReadException 
{
 b <<= 1;
 return bit;
 }
+
+/**
+ * Returns the value from current field (as {@code InputStream.read()} 
would do)
+ * and set the position of the pointer to the next field to read.
+ * @return
+ * @throws IllegalStateException if the stream hasn't any other value.
+ */
+int read() {
+if (this.hasNext() == false) {
 
 Review comment:
   `if (!this.hasNext())`


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


With regards,
Apache Git Services


[GitHub] [commons-imaging] kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling 
for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793193
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
 
 Review comment:
   What about moving the longer text to the main body of the javadocs comment? 
i.e.
   
   ```java
* Returns the positions of where each interval in the provided array 
starts. The number
* of start positions is also the count of intervals while the number of 
restart markers
* found is equal to the number of start positions minus one (because 
restart markers
* are between intervals).
* @param scanPayload array to examine
* @return the start positions
   ```


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


With regards,
Apache Git Services


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256366=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256366
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 03:54
Start Date: 08/Jun/19 03:54
Worklog Time Spent: 10m 
  Work Description: kinow commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793124
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
+ */
+static List getIntervalStartPositions(final int[] scanPayload) {
+final List intervalStarts = new ArrayList();
+intervalStarts.add( 0 );
+boolean foundFF = false;
+boolean foundD0toD7 = false;
+int pos = 0;
+while ( pos < scanPayload.length ) {
+if ( foundFF == true ) {
+// found 0xFF D0 .. 0xFF D7 => RST marker
+if ( scanPayload[ pos ] >= ( 0xff & JpegConstants.RST0_MARKER 
) &&
+scanPayload[ pos ] <= ( 0xff & JpegConstants.RST7_MARKER ) 
) {
+foundD0toD7 = true;
+} else { // found 0xFF followed by something else => no RST 
marker
+foundFF = false;
+}
+}
+
+if ( scanPayload[ pos ] == 0xFF ) {
 
 Review comment:
   `if (scanPayload[ pos ] == 0xFF) {`, spaces
 

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: 256366)
Time Spent: 2h  (was: 1h 50m)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> 

[GitHub] [commons-imaging] kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling 
for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793124
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
+ */
+static List getIntervalStartPositions(final int[] scanPayload) {
+final List intervalStarts = new ArrayList();
+intervalStarts.add( 0 );
+boolean foundFF = false;
+boolean foundD0toD7 = false;
+int pos = 0;
+while ( pos < scanPayload.length ) {
+if ( foundFF == true ) {
+// found 0xFF D0 .. 0xFF D7 => RST marker
+if ( scanPayload[ pos ] >= ( 0xff & JpegConstants.RST0_MARKER 
) &&
+scanPayload[ pos ] <= ( 0xff & JpegConstants.RST7_MARKER ) 
) {
+foundD0toD7 = true;
+} else { // found 0xFF followed by something else => no RST 
marker
+foundFF = false;
+}
+}
+
+if ( scanPayload[ pos ] == 0xFF ) {
 
 Review comment:
   `if (scanPayload[ pos ] == 0xFF) {`, spaces


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


With regards,
Apache Git Services


[GitHub] [commons-imaging] kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling 
for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291792699
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -71,11 +73,23 @@ public boolean beginSOS() {
 public void visitSOS(final int marker, final byte[] markerBytes, final 
byte[] imageData) {
 final ByteArrayInputStream is = new ByteArrayInputStream(imageData);
 try {
+// read the scan header
 final int segmentLength = read2Bytes("segmentLength", is, "Not a 
Valid JPEG File", getByteOrder());
 final byte[] sosSegmentBytes = readBytes("SosSegment",
 is, segmentLength - 2, "Not a Valid JPEG File");
 sosSegment = new SosSegment(marker, sosSegmentBytes);
 
+// read the payload of the scan, this is the remainder of image 
data after the header
+// the payload contains the entropy-encoded segments (or ECS) 
divded by RST markers
 
 Review comment:
   s/divded/divided


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


With regards,
Apache Git Services


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256362=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256362
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 03:54
Start Date: 08/Jun/19 03:54
Worklog Time Spent: 10m 
  Work Description: kinow commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291792933
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegInputStream.java
 ##
 @@ -15,31 +15,39 @@
 
 package org.apache.commons.imaging.formats.jpeg.decoder;
 
-import java.io.IOException;
-import java.io.InputStream;
-
 import org.apache.commons.imaging.ImageReadException;
 import org.apache.commons.imaging.formats.jpeg.JpegConstants;
 
 class JpegInputStream {
 // Figure F.18, F.2.2.5, page 111 of ITU-T T.81
-private final InputStream is;
+private final int[] interval;
+// next position in the array to read
+private int nextPos;
 private int cnt;
 private int b;
 
-JpegInputStream(final InputStream is) {
-this.is = is;
+JpegInputStream(final int[] interval) {
+this.interval = interval;
 
 Review comment:
   `this.interval = Arrays.copyOf(interval, interval.length);` to prevent 
mutability issues? Not sure if there is any risk (i.e. if internal only, 
probably not at risk, but may be still a good idea to play defensively here)
 

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: 256362)
Time Spent: 1.5h  (was: 1h 20m)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256356=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256356
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 03:54
Start Date: 08/Jun/19 03:54
Worklog Time Spent: 10m 
  Work Description: kinow commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793112
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
+ */
+static List getIntervalStartPositions(final int[] scanPayload) {
+final List intervalStarts = new ArrayList();
+intervalStarts.add( 0 );
+boolean foundFF = false;
+boolean foundD0toD7 = false;
+int pos = 0;
+while ( pos < scanPayload.length ) {
+if ( foundFF == true ) {
+// found 0xFF D0 .. 0xFF D7 => RST marker
+if ( scanPayload[ pos ] >= ( 0xff & JpegConstants.RST0_MARKER 
) &&
+scanPayload[ pos ] <= ( 0xff & JpegConstants.RST7_MARKER ) 
) {
+foundD0toD7 = true;
+} else { // found 0xFF followed by something else => no RST 
marker
+foundFF = false;
+}
+}
+
+if ( scanPayload[ pos ] == 0xFF ) {
+foundFF = true;
+}
+
+// true if one of the RST markers was found
+if ( foundFF == true && foundD0toD7 == true ) {
+// we need to add the position after the current position 
because
+// we had already read 0xFF and are now at 0xDn
+intervalStarts.add( pos + 1 );
 
 Review comment:
   `intervalStarts.add(pos + 1);`, spaces
 

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: 256356)
Time Spent: 40m  (was: 0.5h)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> 

[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256360=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256360
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 03:54
Start Date: 08/Jun/19 03:54
Worklog Time Spent: 10m 
  Work Description: kinow commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793216
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -122,8 +134,21 @@ public void visitSOS(final int marker, final byte[] 
markerBytes, final byte[] im
 }
 final DataBuffer dataBuffer = raster.getDataBuffer();
 
+final JpegInputStream[] bitInputStreams = 
splitByRstMarkers(scanPayload);
+int bitInputStreamCount = 0;
+JpegInputStream bitInputStream = bitInputStreams[0];
+
 for (int y1 = 0; y1 < vSize * yMCUs; y1 += vSize) {
 for (int x1 = 0; x1 < hSize * xMCUs; x1 += hSize) {
+// provide a the next interval if an interval is read 
until it's end
+// as long there are unread intervals available
 
 Review comment:
   Maybe
   
   ```
   provide the next interval if an interval is read until its end
   as long as there are unread intervals available
   ```
   ?
 

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: 256360)
Time Spent: 1h 10m  (was: 1h)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256364=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256364
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 03:54
Start Date: 08/Jun/19 03:54
Worklog Time Spent: 10m 
  Work Description: kinow commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793042
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
+ */
+static List getIntervalStartPositions(final int[] scanPayload) {
+final List intervalStarts = new ArrayList();
+intervalStarts.add( 0 );
+boolean foundFF = false;
+boolean foundD0toD7 = false;
+int pos = 0;
+while ( pos < scanPayload.length ) {
+if ( foundFF == true ) {
 
 Review comment:
   `if ( foundFF ) {`
 

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: 256364)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--
This message was 

[GitHub] [commons-imaging] kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling 
for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793112
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
+ */
+static List getIntervalStartPositions(final int[] scanPayload) {
+final List intervalStarts = new ArrayList();
+intervalStarts.add( 0 );
+boolean foundFF = false;
+boolean foundD0toD7 = false;
+int pos = 0;
+while ( pos < scanPayload.length ) {
+if ( foundFF == true ) {
+// found 0xFF D0 .. 0xFF D7 => RST marker
+if ( scanPayload[ pos ] >= ( 0xff & JpegConstants.RST0_MARKER 
) &&
+scanPayload[ pos ] <= ( 0xff & JpegConstants.RST7_MARKER ) 
) {
+foundD0toD7 = true;
+} else { // found 0xFF followed by something else => no RST 
marker
+foundFF = false;
+}
+}
+
+if ( scanPayload[ pos ] == 0xFF ) {
+foundFF = true;
+}
+
+// true if one of the RST markers was found
+if ( foundFF == true && foundD0toD7 == true ) {
+// we need to add the position after the current position 
because
+// we had already read 0xFF and are now at 0xDn
+intervalStarts.add( pos + 1 );
 
 Review comment:
   `intervalStarts.add(pos + 1);`, spaces


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


With regards,
Apache Git Services


[GitHub] [commons-imaging] kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling 
for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793143
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
+ */
+static List getIntervalStartPositions(final int[] scanPayload) {
+final List intervalStarts = new ArrayList();
+intervalStarts.add( 0 );
+boolean foundFF = false;
+boolean foundD0toD7 = false;
+int pos = 0;
+while ( pos < scanPayload.length ) {
 
 Review comment:
   `while (pos < scanPayload.length) {`, spaces


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


With regards,
Apache Git Services


[GitHub] [commons-imaging] kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling 
for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793148
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -393,6 +418,74 @@ private void readMCU(final JpegInputStream is, final 
int[] preds, final Block[]
 }
 }
 
+/**
+ * Returns an array of JpegInputStream where each field contains the 
JpegInputStream
+ * for one interval.
+ * @param scanPayload array to read intervals from
+ * @return JpegInputStreams for all intervals, at least one stream is 
always provided
+ */
+static JpegInputStream[] splitByRstMarkers(final int[] scanPayload) {
+final List intervalStarts = 
getIntervalStartPositions(scanPayload);
+// get number of intervals in payload to init an array of approbiate 
length
+final int intervalCount = intervalStarts.size();
+JpegInputStream[] streams = new JpegInputStream[intervalCount];
+for (int i = 0; i < intervalCount; i++) {
+int from = intervalStarts.get(i);
+int to;
+if (i < intervalCount - 1) {
+// because each restart marker needs two bytes the end of
+// this interval is two bytes before the next interval starts
+to = intervalStarts.get(i + 1) - 2;
+} else { // the last interval ends with the array
+to = scanPayload.length;
+}
+int[] interval = Arrays.copyOfRange(scanPayload, from, to);
+streams[i] = new JpegInputStream(interval);
+}
+return streams;
+}
+
+/**
+ * Returns the positions of where each interval in the provided array 
starts.
+ * @param scanPayload array to examine
+ * @return the start positions, the number of start positions is also the 
count of intervals
+ * while the number of restart markers found = number of start positions - 
1
+ * because restart markers are between intervals
+ */
+static List getIntervalStartPositions(final int[] scanPayload) {
+final List intervalStarts = new ArrayList();
+intervalStarts.add( 0 );
 
 Review comment:
   `intervalStarts.add(0);`, spaces


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


With regards,
Apache Git Services


[GitHub] [commons-imaging] kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling 
for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793200
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -122,8 +134,21 @@ public void visitSOS(final int marker, final byte[] 
markerBytes, final byte[] im
 }
 final DataBuffer dataBuffer = raster.getDataBuffer();
 
+final JpegInputStream[] bitInputStreams = 
splitByRstMarkers(scanPayload);
+int bitInputStreamCount = 0;
+JpegInputStream bitInputStream = bitInputStreams[0];
+
 for (int y1 = 0; y1 < vSize * yMCUs; y1 += vSize) {
 for (int x1 = 0; x1 < hSize * xMCUs; x1 += hSize) {
+// provide a the next interval if an interval is read 
until it's end
+// as long there are unread intervals available
+if (bitInputStream.hasNext() == false) {
 
 Review comment:
   `if (!bitInputStream.hasNext()) {`


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


With regards,
Apache Git Services


[GitHub] [commons-imaging] kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on a change in pull request #47: IMAGING-134: Fix JPEG handling 
for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#discussion_r291793216
 
 

 ##
 File path: 
src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 ##
 @@ -122,8 +134,21 @@ public void visitSOS(final int marker, final byte[] 
markerBytes, final byte[] im
 }
 final DataBuffer dataBuffer = raster.getDataBuffer();
 
+final JpegInputStream[] bitInputStreams = 
splitByRstMarkers(scanPayload);
+int bitInputStreamCount = 0;
+JpegInputStream bitInputStream = bitInputStreams[0];
+
 for (int y1 = 0; y1 < vSize * yMCUs; y1 += vSize) {
 for (int x1 = 0; x1 < hSize * xMCUs; x1 += hSize) {
+// provide a the next interval if an interval is read 
until it's end
+// as long there are unread intervals available
 
 Review comment:
   Maybe
   
   ```
   provide the next interval if an interval is read until its end
   as long as there are unread intervals available
   ```
   ?


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


With regards,
Apache Git Services


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256346=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256346
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 08/Jun/19 02:50
Start Date: 08/Jun/19 02:50
Worklog Time Spent: 10m 
  Work Description: kinow commented on issue #47: IMAGING-134: Fix JPEG 
handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#issuecomment-500087264
 
 
   PR related: #13 
 

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: 256346)
Time Spent: 0.5h  (was: 20m)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] [commons-imaging] kinow commented on issue #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
kinow commented on issue #47: IMAGING-134: Fix JPEG handling for files encoded 
with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#issuecomment-500087264
 
 
   PR related: #13 


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


With regards,
Apache Git Services


[GitHub] [commons-imaging] kinow commented on issue #43: Feature/deflate

2019-06-07 Thread GitBox
kinow commented on issue #43: Feature/deflate
URL: https://github.com/apache/commons-imaging/pull/43#issuecomment-500087235
 
 
   Done @pauldaustin . If you rebase this PR onto master, the tests should 
finally pass. Sorry for the delay!


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


With regards,
Apache Git Services


[GitHub] [commons-numbers] grimreaper commented on issue #48: [WIP] perform the actual migration to JUnit 5

2019-06-07 Thread GitBox
grimreaper commented on issue #48: [WIP] perform the actual migration to JUnit 5
URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-500085481
 
 
   All tests but one test passes now: FieldParametricTest
   
   This class was giving me confusion before too - I have not yet figured out 
how to create parameterized tests in a similar way to junit 4 via the 
constructor. I did manage to make this pass by writing an argumentresolver but 
that seemes like overkill 
   


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


With regards,
Apache Git Services


[GitHub] [commons-numbers] grimreaper commented on issue #48: [WIP] perform the actual migration to JUnit 5

2019-06-07 Thread GitBox
grimreaper commented on issue #48: [WIP] perform the actual migration to JUnit 5
URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-500084376
 
 
   I had fixed it on this branch, and the upstream fix broke my fix. In any 
case, master is now merged.


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


With regards,
Apache Git Services


[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8

2019-06-07 Thread Tomo Suzuki (JIRA)


[ 
https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859059#comment-16859059
 ] 

Tomo Suzuki commented on BCEL-317:
--

For my OutOfMemoryError problem, I came up with a solution by introducing [a 
custom 
ClassPathRepository|https://github.com/GoogleCloudPlatform/cloud-opensource-java/pull/677/files#diff-350e89a9cc5571e1bad7fccd9ca174d3]
 that maintains fixed-size LRU cache of JavaClass. (BCEL's 
MemorySensitiveClassPathRepository also suffers from OutOfMemoryError) The 
solution works good without relying on ConstantUtf8's cache.

While I still believe a cache for  (immutable) ConstantUtf8 is a nice-to-have 
feature to reduce BCEL memory usage, its implementation (example 
[#27|https://github.com/apache/commons-bcel/pull/27]) turned out to be 
difficult without introducing static (global) variables or relying on system 
properties. For now, I stop seeking for a better solution on this ticket.

[~ggregory],
Thank you very much for your help and feedback!


> Pluggable cache for ConstantUtf8
> 
>
> Key: BCEL-317
> URL: https://issues.apache.org/jira/browse/BCEL-317
> Project: Commons BCEL
>  Issue Type: Improvement
>  Components: Main
>Affects Versions: 6.3.1
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: 2644k_constantutf8_without_getCachedInstance.png, 
> 621k_constantutf8_with_getCachedInstance.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Follow-up of BCEL-186. This enhancement is to provide an option to cache 
> ConstantUtf8 instances that have the same value.
>  
> Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass 
> instances
> 
>  We use BCEL library to inspect Java class. Thank you for the great library.
>   
>  When our tool checks classes in ~200 jar files, it creates more than 2 
> million BCEL ConstantUtf8 instances. I suspect many of them share the same 
> values such as "java.lang.String".
>   
> Without cache, my tool created 2,6 million ConstantUtf8 instances (before 
> failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
> !2644k_constantutf8_without_getCachedInstance.png!
>  
> With the cache, my tool created just 0.6 million ConstantUtf8 instances. It 
> didn't throw the OutOfMemoryError.
> !621k_constantutf8_with_getCachedInstance.png!
>  
>  Old commit that made ConstantUtf8.getInstance 
> [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383]
> The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 
> [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541]
>  
> h1. How our project uses BCEL
>  - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 
> 200 JAR files as its input class path in 
> ClassDumper.createClassRepository([source code 
> URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83])
> {code:java}
>   private static Repository createClassRepository(List paths) {
> ClassPath classPath = new LinkageCheckClassPath(paths);
> return new ClassPathRepository(classPath);   # This is BCEL API
>   }{code}
>  - reads JavaClasses one by one in ClassDumper.listClassesInJar ([source code 
> URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360])
>  through the ClassPathRepository.
> {code:java}
>   private ImmutableSet listClassesInJar(Path jar) throws 
> IOException {
> ImmutableSet.Builder javaClasses = ImmutableSet.builder();
> for (String className : listClassNamesInJar(jar)) {
>   try {
> JavaClass javaClass = classRepository.loadClass(className); # This is 
> BCEL API. ConstantUtf8 is not cached.
> javaClasses.add(javaClass);
>   ...(omit)
> return javaClasses.build();
>   }{code}
>   Stacktrace from the ClassDumper.listClassesInJar to BCEL's 
> ConstantUtf8.getInstance would look like this:
>   {code:java}
> ConstantUtf8.getInstance
> Constant.readConstant
> ConstantPool.
> ClassParser.readConstantPool
> ClassParser.parse
> ClassPathRepository.loadClass
> ClassPathRepository.loadClass
> ClassDumper.listClassesInJar {code}
>  - Use the JavaClass instances to check if any symbol references (entries in 
> constant pool [Java Virtual Machine Specification 4.4. The Constant 
> Pool|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4]:
>  CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, and 
> 

[jira] [Commented] (NUMBERS-114) Class LinearCombinationTest in arrays module does not compile

2019-06-07 Thread Heinrich Bohne (JIRA)


[ 
https://issues.apache.org/jira/browse/NUMBERS-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859026#comment-16859026
 ] 

Heinrich Bohne commented on NUMBERS-114:


Thank you. BTW, I think I figured out why Maven was able to build the module. I 
ran {{mvn clean test}} from {{commons-numbers-arrays}} while the build of 
{{commons-numbers-fraction}} was still stuck at an older revision before the 
merge of fraction-dev, so the obsolete constructors invoked from the test class 
in {{commons-numbers-arrays}} were still present in the .class files of the 
{{commons-numbers-fraction}} build, even if they did not exist anymore in the 
source files.

> Class LinearCombinationTest in arrays module does not compile
> -
>
> Key: NUMBERS-114
> URL: https://issues.apache.org/jira/browse/NUMBERS-114
> Project: Commons Numbers
>  Issue Type: Bug
>Reporter: Heinrich Bohne
>Priority: Major
>
> The recent merge of the fraction-dev branch into the master branch broke the 
> class {{LinearCombinationTest}} in the arrays module. This class accesses a 
> constructor {{BigFraction(long, long)}}, which was available before the merge 
> but is no longer so.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (NUMBERS-114) Class LinearCombinationTest in arrays module does not compile

2019-06-07 Thread Heinrich Bohne (JIRA)


 [ 
https://issues.apache.org/jira/browse/NUMBERS-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Heinrich Bohne closed NUMBERS-114.
--
Resolution: Fixed

> Class LinearCombinationTest in arrays module does not compile
> -
>
> Key: NUMBERS-114
> URL: https://issues.apache.org/jira/browse/NUMBERS-114
> Project: Commons Numbers
>  Issue Type: Bug
>Reporter: Heinrich Bohne
>Priority: Major
>
> The recent merge of the fraction-dev branch into the master branch broke the 
> class {{LinearCombinationTest}} in the arrays module. This class accesses a 
> constructor {{BigFraction(long, long)}}, which was available before the merge 
> but is no longer so.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NUMBERS-114) Class LinearCombinationTest in arrays module does not compile

2019-06-07 Thread Gilles (JIRA)


[ 
https://issues.apache.org/jira/browse/NUMBERS-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859016#comment-16859016
 ] 

Gilles commented on NUMBERS-114:


Fixed in commit c97fc79f4dbebc15128c5bc77afde4c2319ca3c4 ("master").

> Class LinearCombinationTest in arrays module does not compile
> -
>
> Key: NUMBERS-114
> URL: https://issues.apache.org/jira/browse/NUMBERS-114
> Project: Commons Numbers
>  Issue Type: Bug
>Reporter: Heinrich Bohne
>Priority: Major
>
> The recent merge of the fraction-dev branch into the master branch broke the 
> class {{LinearCombinationTest}} in the arrays module. This class accesses a 
> constructor {{BigFraction(long, long)}}, which was available before the merge 
> but is no longer so.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NUMBERS-114) Class LinearCombinationTest in arrays module does not compile

2019-06-07 Thread Heinrich Bohne (JIRA)


[ 
https://issues.apache.org/jira/browse/NUMBERS-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858982#comment-16858982
 ] 

Heinrich Bohne commented on NUMBERS-114:


This is very curious, because Maven does not complain about this when trying to 
run the tests. Apparently, it both automatically converts the passed {{long}} 
parameters to {{BigInteger}}, and it also does not care about the fact that the 
constructor {{BigFraction(BigInteger, BigInteger)}} is declared {{private}} and 
should therefore be out of scope. Can anyone shed light on the reason for this 
behavior? Is this a bug in Maven?

> Class LinearCombinationTest in arrays module does not compile
> -
>
> Key: NUMBERS-114
> URL: https://issues.apache.org/jira/browse/NUMBERS-114
> Project: Commons Numbers
>  Issue Type: Bug
>Reporter: Heinrich Bohne
>Priority: Major
>
> The recent merge of the fraction-dev branch into the master branch broke the 
> class {{LinearCombinationTest}} in the arrays module. This class accesses a 
> constructor {{BigFraction(long, long)}}, which was available before the merge 
> but is no longer so.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256141=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256141
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 07/Jun/19 18:32
Start Date: 07/Jun/19 18:32
Worklog Time Spent: 10m 
  Work Description: coveralls commented on issue #47: IMAGING-134: Fix JPEG 
handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#issuecomment-42538
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/23866146/badge)](https://coveralls.io/builds/23866146)
   
   Coverage increased (+0.09%) to 74.411% when pulling 
**9ddc4c45847d48ab4835c3cf38b307d7083886e9 on 
mgs255:imaging-134-jpeg-entropy-exception** into 
**e9f975a8eb487369211dc83a84cd618c2214c2da 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: 256141)
Time Spent: 20m  (was: 10m)

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] [commons-imaging] coveralls commented on issue #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
coveralls commented on issue #47: IMAGING-134: Fix JPEG handling for files 
encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47#issuecomment-42538
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/23866146/badge)](https://coveralls.io/builds/23866146)
   
   Coverage increased (+0.09%) to 74.411% when pulling 
**9ddc4c45847d48ab4835c3cf38b307d7083886e9 on 
mgs255:imaging-134-jpeg-entropy-exception** into 
**e9f975a8eb487369211dc83a84cd618c2214c2da 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


With regards,
Apache Git Services


[jira] [Work logged] (IMAGING-134) Invalid marker found in entropy data

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/IMAGING-134?focusedWorklogId=256112=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-256112
 ]

ASF GitHub Bot logged work on IMAGING-134:
--

Author: ASF GitHub Bot
Created on: 07/Jun/19 17:47
Start Date: 07/Jun/19 17:47
Worklog Time Spent: 10m 
  Work Description: mgs255 commented on pull request #47: IMAGING-134: Fix 
JPEG handling for files encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47
 
 
   Shamelessly pulled from @mgmechanics pull request for the same bug.   
 

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: 256112)
Time Spent: 10m
Remaining Estimate: 0h

> Invalid marker found in entropy data
> 
>
> Key: IMAGING-134
> URL: https://issues.apache.org/jira/browse/IMAGING-134
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: John Hewson
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: Patch Needed
>
> Attachments: image.jpeg
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I'm getting the following exception when trying to read a JPEG:
> Exception in thread "main" org.apache.commons.imaging.ImageReadException: 
> Invalid marker found in entropy data
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegInputStream.nextBit(JpegInputStream.java:50)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:426)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.readMCU(JpegDecoder.java:320)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSOS(JpegDecoder.java:124)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:80)
>   at 
> org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:436)
>   at 
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:98)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
>   at 
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1341)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] [commons-imaging] mgs255 opened a new pull request #47: IMAGING-134: Fix JPEG handling for files encoded with RST markers

2019-06-07 Thread GitBox
mgs255 opened a new pull request #47: IMAGING-134: Fix JPEG handling for files 
encoded with RST markers
URL: https://github.com/apache/commons-imaging/pull/47
 
 
   Shamelessly pulled from @mgmechanics pull request for the same bug.   


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


With regards,
Apache Git Services


[GitHub] [commons-numbers] Schamschi edited a comment on issue #48: [WIP] perform the actual migration to JUnit 5

2019-06-07 Thread GitBox
Schamschi edited a comment on issue #48: [WIP] perform the actual migration to 
JUnit 5
URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-499901864
 
 
   @grimreaper [JIRA ticket](https://issues.apache.org/jira/browse/NUMBERS-114) 
created.


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


With regards,
Apache Git Services


[GitHub] [commons-numbers] Schamschi commented on issue #48: [WIP] perform the actual migration to JUnit 5

2019-06-07 Thread GitBox
Schamschi commented on issue #48: [WIP] perform the actual migration to JUnit 5
URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-499901864
 
 
   [JIRA ticket](https://issues.apache.org/jira/browse/NUMBERS-114) created.


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


With regards,
Apache Git Services


[jira] [Created] (NUMBERS-114) Class LinearCombinationTest in arrays module does not compile

2019-06-07 Thread Heinrich Bohne (JIRA)
Heinrich Bohne created NUMBERS-114:
--

 Summary: Class LinearCombinationTest in arrays module does not 
compile
 Key: NUMBERS-114
 URL: https://issues.apache.org/jira/browse/NUMBERS-114
 Project: Commons Numbers
  Issue Type: Bug
Reporter: Heinrich Bohne


The recent merge of the fraction-dev branch into the master branch broke the 
class {{LinearCombinationTest}} in the arrays module. This class accesses a 
constructor {{BigFraction(long, long)}}, which was available before the merge 
but is no longer so.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] [commons-numbers] Schamschi commented on issue #48: [WIP] perform the actual migration to JUnit 5

2019-06-07 Thread GitBox
Schamschi commented on issue #48: [WIP] perform the actual migration to JUnit 5
URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-499899659
 
 
   @grimreaper Indeed, this class does not compile (I hadn't noticed until 
now), however, this has nothing to do with your merge. It was the merging of 
the fraction-dev branch into the master branch that caused the class 
`LinearCombinationTest` to break. Apparently, the class `BigFraction` does no 
longer contain a `BigFraction(long, long)` constructor, so naturally, the class 
`LinearCombinationTest` cannot compile. It worked before the merge (you can 
test it with the master branch).
   
   I'm going to create a JIRA ticket. This is frustrating.


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


With regards,
Apache Git Services


[GitHub] [commons-geometry] darkma773r opened a new pull request #34: GEOMETRY-32

2019-06-07 Thread GitBox
darkma773r opened a new pull request #34: GEOMETRY-32
URL: https://github.com/apache/commons-geometry/pull/34
 
 
   Draft pull request for work on BSP tree refactoring (GEOMETRY-32).


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


With regards,
Apache Git Services


[GitHub] [commons-numbers] grimreaper commented on issue #48: [WIP] perform the actual migration to JUnit 5

2019-06-07 Thread GitBox
grimreaper commented on issue #48: [WIP] perform the actual migration to JUnit 5
URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-499861252
 
 
   > but the next time you do this, could you please first update your local 
copy of the branch?
   I think I figured out what I did wrong: my branch was set up to track 
origin/master instead of our working branch. thus, when I did `git pull` it 
didn't actually do what I wanted. 
   
   > because in some cases the merge from the fraction-dev branch to the master 
branch caused the test methods to invoke different methods/constructors than 
before, ... I think I have fixed these issues now with my latest commit.
   
   Thank you.
   
   Right now the only things failing are
   ```
   [ERROR] 
/Users/eax/svn/apache/commons/numbers/commons-numbers-arrays/src/test/java/org/apache/commons/numbers/arrays/LinearCombinationTest.java:[39,29]
 incompatible types: long cannot be converted to java.math.BigInteger
   [ERROR] 
/Users/eax/svn/apache/commons/numbers/commons-numbers-arrays/src/test/java/org/apache/commons/numbers/arrays/LinearCombinationTest.java:[40,29]
 incompatible types: long cannot be converted to java.math.BigInteger
   [ERROR] 
/Users/eax/svn/apache/commons/numbers/commons-numbers-arrays/src/test/java/org/apache/commons/numbers/arrays/LinearCombinationTest.java:[41,29]
 incompatible types: long cannot be converted to java.math.BigInteger
   [ERROR] 
/Users/eax/svn/apache/commons/numbers/commons-numbers-arrays/src/test/java/org/apache/commons/numbers/arrays/LinearCombinationTest.java:[44,29]
 incompatible types: long cannot be converted to java.math.BigInteger
   [ERROR] 
/Users/eax/svn/apache/commons/numbers/commons-numbers-arrays/src/test/java/org/apache/commons/numbers/arrays/LinearCombinationTest.java:[45,29]
 incompatible types: long cannot be converted to java.math.BigInteger
   [ERROR] 
/Users/eax/svn/apache/commons/numbers/commons-numbers-arrays/src/test/java/org/apache/commons/numbers/arrays/LinearCombinationTest.java:[46,29]
 incompatible types: long cannot be converted to java.math.BigInteger
   [ERROR] -> [Help 1]
    
   
   which I'm looking at now


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


With regards,
Apache Git Services


[jira] [Closed] (NUMBERS-113) Broken/deprecated/old JUnit dependencies in pom.xml

2019-06-07 Thread Heinrich Bohne (JIRA)


 [ 
https://issues.apache.org/jira/browse/NUMBERS-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Heinrich Bohne closed NUMBERS-113.
--
Resolution: Fixed

> Broken/deprecated/old JUnit dependencies in pom.xml
> ---
>
> Key: NUMBERS-113
> URL: https://issues.apache.org/jira/browse/NUMBERS-113
> Project: Commons Numbers
>  Issue Type: Bug
>Reporter: Heinrich Bohne
>Priority: Major
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The recent 
> [commit|https://github.com/apache/commons-numbers/commit/35b53cff1a9fc8c9a5b4a44bd33d22c959c4]
>  where JUnit 5 was introduced seems to have broken something. Apparently, the 
> version number for the junit-platform-runner dependency (version 5.0.0-M4) 
> does not exist.
> Also, the latest stable version of junit-jupiter-engine is 5.4.2, but the 
> pom.xml declares a version number 5.0.0-M4 also for this dependency.
> Besides, I'm getting a warning when trying to run tests:
> bq. The junit-platform-surefire-provider has been deprecated and is scheduled 
> to be removed in JUnit Platform 1.4. Please use the built-in support in Maven 
> Surefire >= 2.22.0 instead.
> I'm not sure what this means, but I assume it has something to do with the 
> dependencies configured for the surefire plugin, which were not there before.
> Besides, I think the appropriate scope for the junit-jupiter-engine 
> dependency is {{test}} (currently, it is not set, so it defaults to 
> {{compile}}).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work logged] (NUMBERS-113) Broken/deprecated/old JUnit dependencies in pom.xml

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/NUMBERS-113?focusedWorklogId=255864=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-255864
 ]

ASF GitHub Bot logged work on NUMBERS-113:
--

Author: ASF GitHub Bot
Created on: 07/Jun/19 11:50
Start Date: 07/Jun/19 11:50
Worklog Time Spent: 10m 
  Work Description: Schamschi commented on issue #50: NUMBERS-113: Fix 
JUnit dependencies in pom.xml
URL: https://github.com/apache/commons-numbers/pull/50#issuecomment-499855737
 
 
   @aherbert Yes, it seems fixed now, I'm going to close the pull request and 
the JIRA ticket.
 

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: 255864)
Time Spent: 1h 10m  (was: 1h)

> Broken/deprecated/old JUnit dependencies in pom.xml
> ---
>
> Key: NUMBERS-113
> URL: https://issues.apache.org/jira/browse/NUMBERS-113
> Project: Commons Numbers
>  Issue Type: Bug
>Reporter: Heinrich Bohne
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The recent 
> [commit|https://github.com/apache/commons-numbers/commit/35b53cff1a9fc8c9a5b4a44bd33d22c959c4]
>  where JUnit 5 was introduced seems to have broken something. Apparently, the 
> version number for the junit-platform-runner dependency (version 5.0.0-M4) 
> does not exist.
> Also, the latest stable version of junit-jupiter-engine is 5.4.2, but the 
> pom.xml declares a version number 5.0.0-M4 also for this dependency.
> Besides, I'm getting a warning when trying to run tests:
> bq. The junit-platform-surefire-provider has been deprecated and is scheduled 
> to be removed in JUnit Platform 1.4. Please use the built-in support in Maven 
> Surefire >= 2.22.0 instead.
> I'm not sure what this means, but I assume it has something to do with the 
> dependencies configured for the surefire plugin, which were not there before.
> Besides, I think the appropriate scope for the junit-jupiter-engine 
> dependency is {{test}} (currently, it is not set, so it defaults to 
> {{compile}}).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work logged] (NUMBERS-113) Broken/deprecated/old JUnit dependencies in pom.xml

2019-06-07 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/NUMBERS-113?focusedWorklogId=255865=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-255865
 ]

ASF GitHub Bot logged work on NUMBERS-113:
--

Author: ASF GitHub Bot
Created on: 07/Jun/19 11:50
Start Date: 07/Jun/19 11:50
Worklog Time Spent: 10m 
  Work Description: Schamschi commented on pull request #50: NUMBERS-113: 
Fix JUnit dependencies in pom.xml
URL: https://github.com/apache/commons-numbers/pull/50
 
 
   
 

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: 255865)
Time Spent: 1h 20m  (was: 1h 10m)

> Broken/deprecated/old JUnit dependencies in pom.xml
> ---
>
> Key: NUMBERS-113
> URL: https://issues.apache.org/jira/browse/NUMBERS-113
> Project: Commons Numbers
>  Issue Type: Bug
>Reporter: Heinrich Bohne
>Priority: Major
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The recent 
> [commit|https://github.com/apache/commons-numbers/commit/35b53cff1a9fc8c9a5b4a44bd33d22c959c4]
>  where JUnit 5 was introduced seems to have broken something. Apparently, the 
> version number for the junit-platform-runner dependency (version 5.0.0-M4) 
> does not exist.
> Also, the latest stable version of junit-jupiter-engine is 5.4.2, but the 
> pom.xml declares a version number 5.0.0-M4 also for this dependency.
> Besides, I'm getting a warning when trying to run tests:
> bq. The junit-platform-surefire-provider has been deprecated and is scheduled 
> to be removed in JUnit Platform 1.4. Please use the built-in support in Maven 
> Surefire >= 2.22.0 instead.
> I'm not sure what this means, but I assume it has something to do with the 
> dependencies configured for the surefire plugin, which were not there before.
> Besides, I think the appropriate scope for the junit-jupiter-engine 
> dependency is {{test}} (currently, it is not set, so it defaults to 
> {{compile}}).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] [commons-numbers] Schamschi closed pull request #50: NUMBERS-113: Fix JUnit dependencies in pom.xml

2019-06-07 Thread GitBox
Schamschi closed pull request #50: NUMBERS-113: Fix JUnit dependencies in 
pom.xml
URL: https://github.com/apache/commons-numbers/pull/50
 
 
   


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


With regards,
Apache Git Services


[GitHub] [commons-numbers] Schamschi commented on issue #50: NUMBERS-113: Fix JUnit dependencies in pom.xml

2019-06-07 Thread GitBox
Schamschi commented on issue #50: NUMBERS-113: Fix JUnit dependencies in pom.xml
URL: https://github.com/apache/commons-numbers/pull/50#issuecomment-499855737
 
 
   @aherbert Yes, it seems fixed now, I'm going to close the pull request and 
the JIRA ticket.


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


With regards,
Apache Git Services


[GitHub] [commons-numbers] Schamschi commented on issue #48: [WIP] perform the actual migration to JUnit 5

2019-06-07 Thread GitBox
Schamschi commented on issue #48: [WIP] perform the actual migration to JUnit 5
URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-499840635
 
 
   Thanks for letting me know, and it's a good thing you did, because with this 
force push, you overwrote my migrations of 13 classes from the gamma module, 
which I had already pushed to the branch. Luckily, I still had them saved in my 
local repository so I could re-commit them, but the next time you do this, 
could you please first update your local copy of the branch?
   
   Also, when you merged the master branch, you overwrote several changes from 
the fraction-dev branch when resolving the arisen merge conflicts. Some of 
these overwrites were beneficial, e.g. converting tabs to spaces or removing 
redundant whitespace, but some, i.e. those where you refactored the code to use 
assertThrows, were problematic, because in some cases the merge from the 
fraction-dev branch to the master branch caused the test methods to invoke 
different methods/constructors than before, and when you resolved the merge 
conflicts, you reverted the test methods to invoke the old 
methods/constructors, which in some cases did not exist anymore, causing the 
code to be not compilable.
   
   I think I have fixed these issues now with my latest commmit.


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


With regards,
Apache Git Services


[GitHub] [commons-numbers] aherbert commented on issue #50: NUMBERS-113: Fix JUnit dependencies in pom.xml

2019-06-07 Thread GitBox
aherbert commented on issue #50: NUMBERS-113: Fix JUnit dependencies in pom.xml
URL: https://github.com/apache/commons-numbers/pull/50#issuecomment-499829590
 
 
   The JUnit change is now restored in master. @Schamschi can you confirm if 
this has fixed your JUnit issues on your branch and close?


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


With regards,
Apache Git Services


[jira] [Created] (JEXL-306) Ternary operator ? protects also its branches from resolvance errors

2019-06-07 Thread Dmitri Blinov (JIRA)
Dmitri Blinov created JEXL-306:
--

 Summary: Ternary operator ? protects also its branches from 
resolvance errors
 Key: JEXL-306
 URL: https://issues.apache.org/jira/browse/JEXL-306
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 3.1
Reporter: Dmitri Blinov


Consider the following test case (suppose its added to IfTest)
{code:java}
    @Test
    public void testTernaryFail() throws Exception {
    JexlEvalContext jc = new JexlEvalContext();
    JexlExpression e = JEXL.createExpression("false ? bar : quux");
    Object o;

    jc.setStrict(true);
    jc.setSilent(false);
    try {
   o = e.evaluate(jc);
   Assert.fail("Should have failed");
    } catch (Exception ex) {
   // OK
    }
    }
{code}
The expected behavior is to fail with {{undefined variable...}} because neither 
{{bar}} nor {{quux}} is defined 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)