[jira] [Comment Edited] (LANG-1462) After version Commons-lang3.4 DateFormatUtils has a bug
[
https://issues.apache.org/jira/browse/LANG-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16882642#comment-16882642
]
Arun Avanathan edited comment on LANG-1462 at 7/11/19 4:16 AM:
---
[~britter] [~ggregory1] In DateFormatUtils.java, we have this
{code:java}
public static String format(Calendar calendar, String pattern) {
return format((Calendar)calendar, pattern, (TimeZone)null, (Locale)null);
}
{code}
We could replace it with
{code:java}
public static String format(Calendar calendar, String pattern) {
return format((Calendar)calendar, pattern, calendar.getTimeZone(),
(Locale)null);
}{code}
Let me know what you guys think & if you agree, I could open a PR.
was (Author: aavanathan):
[~britter] [~ggregory1] We have this
{code:java}
public static String format(Calendar calendar, String pattern) {
return format((Calendar)calendar, pattern, (TimeZone)null, (Locale)null);
}
{code}
We could replace it with
{code:java}
public static String format(Calendar calendar, String pattern) {
return format((Calendar)calendar, pattern, calendar.getTimeZone(),
(Locale)null);
}{code}
Let me know what you guys think & if you agree, I could open a PR.
> After version Commons-lang3.4 DateFormatUtils has a bug
> ---
>
> Key: LANG-1462
> URL: https://issues.apache.org/jira/browse/LANG-1462
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.5, 3.6, 3.7, 3.8, 3.9, 3.8.1
>Reporter: Lijun Liang
>Priority: Critical
>
> The code is as follows ：
> Calendar cale = Calendar.getInstance();
> System.out.println("Old time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
> cale.setTimeZone(TimeZone.getTimeZone("JST"));
> System.out.println("New time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
>
> The results of commons-lang3 3.4：
> Old time is 20190605144536
> New time is 20190605154536
>
> The results of the version after commons-lang3 3.4:
> Old time is 20190605144536
> New time is 20190605144536
>
> We found that the time zone setting was invalidated when it was formatted
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1462) After version Commons-lang3.4 DateFormatUtils has a bug
[
https://issues.apache.org/jira/browse/LANG-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16882642#comment-16882642
]
Arun Avanathan commented on LANG-1462:
--
[~britter] [~ggregory1] We have this
{code:java}
public static String format(Calendar calendar, String pattern) {
return format((Calendar)calendar, pattern, (TimeZone)null, (Locale)null);
}
{code}
We could replace it with
{code:java}
public static String format(Calendar calendar, String pattern) {
return format((Calendar)calendar, pattern, calendar.getTimeZone(),
(Locale)null);
}{code}
Let me know what you guys think & if you agree, I could open a PR.
> After version Commons-lang3.4 DateFormatUtils has a bug
> ---
>
> Key: LANG-1462
> URL: https://issues.apache.org/jira/browse/LANG-1462
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.5, 3.6, 3.7, 3.8, 3.9, 3.8.1
>Reporter: Lijun Liang
>Priority: Critical
>
> The code is as follows ：
> Calendar cale = Calendar.getInstance();
> System.out.println("Old time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
> cale.setTimeZone(TimeZone.getTimeZone("JST"));
> System.out.println("New time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
>
> The results of commons-lang3 3.4：
> Old time is 20190605144536
> New time is 20190605154536
>
> The results of the version after commons-lang3 3.4:
> Old time is 20190605144536
> New time is 20190605144536
>
> We found that the time zone setting was invalidated when it was formatted
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-math] emopers opened a new pull request #110: Close ObjectOutputStream before calling toByteArray on underlying ByteArrayOutputStream
emopers opened a new pull request #110: Close ObjectOutputStream before calling toByteArray on underlying ByteArrayOutputStream URL: https://github.com/apache/commons-math/pull/110 When an `ObjectOutputStream` instance wraps an underlying `ByteArrayOutputStream` instance, it is recommended to flush or close the `ObjectOutputStream` before invoking the underlying instances's `toByteArray()`. Although in these cases it is not strictly necessary because `writeObject` method is invoked right before `toByteArray`, and `writeObject` internally calls `flush`/`drain`. However, it is good practice to call `flush`/`close` explicitly as mentioned, for example, [here](http://stackoverflow.com/questions/2984538/how-to-use-bytearrayoutputstream-and-dataoutputstream-simultaneously-java). This pull request adds a call to the `close` method before calls to the `toByteArray` methods. 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] (LANG-1462) After version Commons-lang3.4 DateFormatUtils has a bug
[
https://issues.apache.org/jira/browse/LANG-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16882633#comment-16882633
]
Arun Avanathan commented on LANG-1462:
--
Result:
{code:java}
Old time is 20190710203809
New time is 20190710203809
Alternatively you could use this 20190711123809{code}
> After version Commons-lang3.4 DateFormatUtils has a bug
> ---
>
> Key: LANG-1462
> URL: https://issues.apache.org/jira/browse/LANG-1462
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.5, 3.6, 3.7, 3.8, 3.9, 3.8.1
>Reporter: Lijun Liang
>Priority: Critical
>
> The code is as follows ：
> Calendar cale = Calendar.getInstance();
> System.out.println("Old time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
> cale.setTimeZone(TimeZone.getTimeZone("JST"));
> System.out.println("New time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
>
> The results of commons-lang3 3.4：
> Old time is 20190605144536
> New time is 20190605154536
>
> The results of the version after commons-lang3 3.4:
> Old time is 20190605144536
> New time is 20190605144536
>
> We found that the time zone setting was invalidated when it was formatted
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1462) After version Commons-lang3.4 DateFormatUtils has a bug
[
https://issues.apache.org/jira/browse/LANG-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16882631#comment-16882631
]
Arun Avanathan commented on LANG-1462:
--
Alternatively, you could use this method post 3.4
{code:java}
System.out.println("Alternatively you could use this
"+DateFormatUtils.format(cale,"MMddHHmmss",
TimeZone.getTimeZone("JST")));{code}
> After version Commons-lang3.4 DateFormatUtils has a bug
> ---
>
> Key: LANG-1462
> URL: https://issues.apache.org/jira/browse/LANG-1462
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.5, 3.6, 3.7, 3.8, 3.9, 3.8.1
>Reporter: Lijun Liang
>Priority: Critical
>
> The code is as follows ：
> Calendar cale = Calendar.getInstance();
> System.out.println("Old time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
> cale.setTimeZone(TimeZone.getTimeZone("JST"));
> System.out.println("New time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
>
> The results of commons-lang3 3.4：
> Old time is 20190605144536
> New time is 20190605154536
>
> The results of the version after commons-lang3 3.4:
> Old time is 20190605144536
> New time is 20190605144536
>
> We found that the time zone setting was invalidated when it was formatted
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (POOL-368) Create Auto-Closing PooledObject
David Mollitor created POOL-368:
---
Summary: Create Auto-Closing PooledObject
Key: POOL-368
URL: https://issues.apache.org/jira/browse/POOL-368
Project: Commons Pool
Issue Type: Improvement
Reporter: David Mollitor
Please create an {{PooledObject}} that implements {{AutoCloseable}}. When the
pooled object is closed, the wrapped resource is returned to the pool
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IMAGING-231) Reading tiff with LZW compression results in mangled image
Jimmy Merrild Krag created IMAGING-231:
--
Summary: Reading tiff with LZW compression results in mangled image
Key: IMAGING-231
URL: https://issues.apache.org/jira/browse/IMAGING-231
Project: Commons Imaging
Issue Type: Bug
Components: Format: TIFF
Affects Versions: 1.0-alpha1
Reporter: Jimmy Merrild Krag
Attachments: image_pages.zip, result.pdf
I am trying to create a PDF using PDFbox with Commons Imaging for loading
images. Commons imaging fixes most of the issues I have with the alternatives,
but still cannot load my tiff files correctly.
I have attached a resulting PDF as {{result.pdf}}.
The files I use for testing, are attached in {{image_pages.zip}}. The
tiff-files, which are not loaded correctly, are LZW-compressed, and that is the
only difference I can find in the format.
All images look the same if I save them to separate image files in another
format, as they do in the PDF, so PDFbox does not seem to be the one to blame.
My code for reading the files is pretty straightforward:
{code:java}
ImageInfo imageInfo = Imaging.getImageInfo(imageBytes);
if (imageInfo.getNumberOfImages() > 1) {
List allBufferedImages =
Imaging.getAllBufferedImages(imageBytes);
for (BufferedImage bufferedImage : allBufferedImages) {
appendImagePage(bufferedImage);
}
} else {
appendImagePage(Imaging.getBufferedImage(imageBytes));
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-codec] garydgregory commented on issue #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations.
garydgregory commented on issue #22: CODEC-236: MurmurHash2 and MurmurHash3
implementations.
URL: https://github.com/apache/commons-codec/pull/22#issuecomment-510239394
Hm, `XXHash32` and others implements `java.util.zip.Checksum`. Other classes
in `org.apache.commons.codec.digest` do _not_ implement Codec interfaces where
some could, like `UnixCrypt`. Food for thought. But for the new code in this
PR, the fit with the Codec interfaces might not be best.
The Travid build (https://travis-ci.org/apache/commons-codec/jobs/556975625)
reveals that the Javadoc for the new code is incomplete:
```
[ERROR]
/home/travis/build/apache/commons-codec/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java:84:
warning: no @param for l0
[ERROR] public static int hash32(long l0, int seed) {
[ERROR]^
[ERROR]
/home/travis/build/apache/commons-codec/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java:84:
warning: no @param for seed
[ERROR] public static int hash32(long l0, int seed) {
[ERROR]^
[ERROR]
/home/travis/build/apache/commons-codec/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java:84:
warning: no @return
[ERROR] public static int hash32(long l0, int seed) {
[ERROR]^
[ERROR]
/home/travis/build/apache/commons-codec/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java:97:
warning: no @param for l0
[ERROR] public static int hash32(long l0, long l1, int seed) {
[ERROR]^
[ERROR]
/home/travis/build/apache/commons-codec/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java:97:
warning: no @param for l1
[ERROR] public static int hash32(long l0, long l1, int seed) {
[ERROR]^
[ERROR]
/home/travis/build/apache/commons-codec/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java:97:
warning: no @param for seed
[ERROR] public static int hash32(long l0, long l1, int seed) {
[ERROR]^
[ERROR]
/home/travis/build/apache/commons-codec/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java:97:
warning: no @return
[ERROR] public static int hash32(long l0, long l1, int seed) {
[ERROR]^
[ERROR]
/home/travis/build/apache/commons-codec/src/main/java/org/apache/commons/codec/digest/MurmurHash3.java:275:
warning: no @param for offset
[ERROR] public static long hash64(byte[] data, int offset, int length,
int seed) {
[ERROR] ^
```
It would be best if you could address this as well as the decrease in code
coverage.
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 #50: Need *.webp type images reader and writer
kinow commented on issue #50: Need *.webp type images reader and writer URL: https://github.com/apache/commons-imaging/pull/50#issuecomment-510217728 Sounds like a good idea. I think there was some merge/rebase issue somewhere. There are way too many commits in this PR. You may want to review your commit log, rebase onto master, and make sure there are fewer changes in the PR, as that makes it easier to be reviewed/merged. Thanks! 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] changbaishan opened a new pull request #50: Need *.webp type images reader and writer
changbaishan opened a new pull request #50: Need *.webp type images reader and writer URL: https://github.com/apache/commons-imaging/pull/50 As more and more *.webp type images popping up everywhere, I hope openimaj will be able to read and write this type of images. As an example, https://i.guancha.cn/bbs/2019/07/10/20190710110612113 is pretty exciting. Thanks very much! 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-codec] coveralls edited a comment on issue #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations.
coveralls edited a comment on issue #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations. URL: https://github.com/apache/commons-codec/pull/22#issuecomment-510035888 [](https://coveralls.io/builds/24485719) Coverage decreased (-1.06%) to 91.327% when pulling **a34eb0e47ee6ec2a34fb3cf49ba9f1168726a8bb on melloware:CODEC-236** into **45a195e0776e2dfb85022f034aec3af191cf7dca 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
[GitHub] [commons-codec] melloware commented on a change in pull request #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations.
melloware commented on a change in pull request #22: CODEC-236: MurmurHash2 and
MurmurHash3 implementations.
URL: https://github.com/apache/commons-codec/pull/22#discussion_r302251209
##
File path: src/main/java/org/apache/commons/codec/digest/MurmurHash2.java
##
@@ -0,0 +1,215 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.commons.codec.digest;
+
+/**
+ * MurmurHash2 yields a 32-bit or 64-bit value.
+ *
+ * MurmurHash is a non-cryptographic hash function suitable for general
+ * hash-based lookup. The name comes from two basic operations, multiply (MU)
+ * and rotate (R), used in its inner loop. Unlike cryptographic hash functions,
+ * it is not specifically designed to be difficult to reverse by an adversary,
+ * making it unsuitable for cryptographic purposes.
+ *
+ * This is a re-implementation of the original C code plus some additional
+ * features.
+ *
+ * Public domain.
+ *
+ * @author Viliam Holub
+ * @see https://en.wikipedia.org/wiki/MurmurHash";>MurmurHash
+ * @since 1.13
+ */
+public final class MurmurHash2 {
+
+ // all methods static; private constructor.
Review comment:
Actually looking at those the intent was something was encoded. This is
more like the XXHash32 class in Commons Codec. This hashes a value to a long
or int. I don't see any interface for Hash algorithms?
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-codec] melloware commented on a change in pull request #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations.
melloware commented on a change in pull request #22: CODEC-236: MurmurHash2 and
MurmurHash3 implementations.
URL: https://github.com/apache/commons-codec/pull/22#discussion_r302243806
##
File path: src/main/java/org/apache/commons/codec/digest/MurmurHash2.java
##
@@ -0,0 +1,215 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.commons.codec.digest;
+
+/**
+ * MurmurHash2 yields a 32-bit or 64-bit value.
+ *
+ * MurmurHash is a non-cryptographic hash function suitable for general
+ * hash-based lookup. The name comes from two basic operations, multiply (MU)
+ * and rotate (R), used in its inner loop. Unlike cryptographic hash functions,
+ * it is not specifically designed to be difficult to reverse by an adversary,
+ * making it unsuitable for cryptographic purposes.
+ *
+ * This is a re-implementation of the original C code plus some additional
+ * features.
+ *
+ * Public domain.
+ *
+ * @author Viliam Holub
+ * @see https://en.wikipedia.org/wiki/MurmurHash";>MurmurHash
+ * @since 1.13
+ */
+public final class MurmurHash2 {
+
+ // all methods static; private constructor.
Review comment:
Good idea let me study those interfaces and see if I can modify.
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-codec] melloware commented on a change in pull request #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations.
melloware commented on a change in pull request #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations. URL: https://github.com/apache/commons-codec/pull/22#discussion_r302242618 ## File path: src/main/java/org/apache/commons/codec/digest/MurmurHash2.java ## @@ -0,0 +1,215 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.commons.codec.digest; + +/** + * MurmurHash2 yields a 32-bit or 64-bit value. + * + * MurmurHash is a non-cryptographic hash function suitable for general + * hash-based lookup. The name comes from two basic operations, multiply (MU) + * and rotate (R), used in its inner loop. Unlike cryptographic hash functions, + * it is not specifically designed to be difficult to reverse by an adversary, + * making it unsuitable for cryptographic purposes. + * + * This is a re-implementation of the original C code plus some additional + * features. + * + * Public domain. + * + * @author Viliam Holub Review comment: Removed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16882401#comment-16882401
]
Tomo Suzuki commented on BCEL-323:
--
[~ggregory] Thank you.
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Fix For: 6.4.0
>
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h1. Problem
> With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
> [interface's default
> method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
> Memo for myself:
> {code:java}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
> h1. Difference causing Test Failure
> In OpenJDK 13, the default parameter for the interface disappears after
> BCELifier creates the class file.
> !screenshot-1.png!
>
> {code:java}
> $ java -version
> openjdk version "13-ea" 2019-09-17
> OpenJDK Runtime Environment (build 13-ea+28)
> OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
> h2. What does BCELifierTestCase do?
> The test compares two output of javap command:
> * javap "target/test-classes/Java8Example.class" (which is copied from
> ./src/test/resources/Java8Example.class in git)
> * javap another Java8Example.class which is generated by BCELifer.
> ** Actually the class file is not directly created by BCELifer.
> *** BCELifer writes Java8ExampleCreator.java
> *** The test runs "javac" to compile Java8ExampleCreator.
> *** The test runs "java" to run Java8ExampleCreator, which in turn generates
> Java8Example.class
> JDK 13's javap command adds "default" for the first Java8Example.class but
> not on the second one.
> h2. Question to Answer
> Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
> output should not change. Which part of BCEL relies on JDK?
> A. This question is irrelevant, because the output class files are all the
> same (see below).
> Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
> JDK 13?
> A. They are the same.
> Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
> * javap (screenshot shown above)
> !screenshot-2.png!
> * binary diff editor?
> Q. What about JDK 11?
> A. JDK 11's javap does not show "default" for both Java8Example.class files.
> JDK11's generated Java8Example.class has 1 attributes. The resulting
> Java8Example.class files are all the same across JDKs:
> {code}
> $ md5sum /tmp/target-jdk*/Java8Example.class
> f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk11/Java8Example.class
> f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk13/Java8Example.class
> f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk8/Java8Example.class{code}
> So it's the matter of javap command showing "default" or not.
> Q. JDK 13's javap outputs "default" under certain condition. What is the
> condition?
> A. It's when major.minor >= 52.0, as per
> http://hg.openjdk.java.net/jdk/jdk13/rev/77b54b2822cc
> h1. Root Cause
> Open JDK 13's javap shows "default" when major.minor >= 52.0 ([commit in June
> 2019|http://hg.openjdk.java.net/jdk/jdk13/rev/77b54b2822cc]). BCEL while
> BCELifier was not copying major.minor (default: "45.3").
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed BCEL-323.
-
Resolution: Fixed
Fix Version/s: 6.4.0
In git master.
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Fix For: 6.4.0
>
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h1. Problem
> With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
> [interface's default
> method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
> Memo for myself:
> {code:java}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
> h1. Difference causing Test Failure
> In OpenJDK 13, the default parameter for the interface disappears after
> BCELifier creates the class file.
> !screenshot-1.png!
>
> {code:java}
> $ java -version
> openjdk version "13-ea" 2019-09-17
> OpenJDK Runtime Environment (build 13-ea+28)
> OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
> h2. What does BCELifierTestCase do?
> The test compares two output of javap command:
> * javap "target/test-classes/Java8Example.class" (which is copied from
> ./src/test/resources/Java8Example.class in git)
> * javap another Java8Example.class which is generated by BCELifer.
> ** Actually the class file is not directly created by BCELifer.
> *** BCELifer writes Java8ExampleCreator.java
> *** The test runs "javac" to compile Java8ExampleCreator.
> *** The test runs "java" to run Java8ExampleCreator, which in turn generates
> Java8Example.class
> JDK 13's javap command adds "default" for the first Java8Example.class but
> not on the second one.
> h2. Question to Answer
> Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
> output should not change. Which part of BCEL relies on JDK?
> A. This question is irrelevant, because the output class files are all the
> same (see below).
> Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
> JDK 13?
> A. They are the same.
> Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
> * javap (screenshot shown above)
> !screenshot-2.png!
> * binary diff editor?
> Q. What about JDK 11?
> A. JDK 11's javap does not show "default" for both Java8Example.class files.
> JDK11's generated Java8Example.class has 1 attributes. The resulting
> Java8Example.class files are all the same across JDKs:
> {code}
> $ md5sum /tmp/target-jdk*/Java8Example.class
> f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk11/Java8Example.class
> f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk13/Java8Example.class
> f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk8/Java8Example.class{code}
> So it's the matter of javap command showing "default" or not.
> Q. JDK 13's javap outputs "default" under certain condition. What is the
> condition?
> A. It's when major.minor >= 52.0, as per
> http://hg.openjdk.java.net/jdk/jdk13/rev/77b54b2822cc
> h1. Root Cause
> Open JDK 13's javap shows "default" when major.minor >= 52.0 ([commit in June
> 2019|http://hg.openjdk.java.net/jdk/jdk13/rev/77b54b2822cc]). BCEL while
> BCELifier was not copying major.minor (default: "45.3").
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?focusedWorklogId=275007&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-275007
]
ASF GitHub Bot logged work on BCEL-323:
---
Author: ASF GitHub Bot
Created on: 10/Jul/19 18:57
Start Date: 10/Jul/19 18:57
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #31:
[BCEL-323]BCELifier to set major and minor versions
URL: https://github.com/apache/commons-bcel/pull/31
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: 275007)
Time Spent: 20m (was: 10m)
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h1. Problem
> With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
> [interface's default
> method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
> Memo for myself:
> {code:java}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
> h1. Difference causing Test Failure
> In OpenJDK 13, the default parameter for the interface disappears after
> BCELifier creates the class file.
> !screenshot-1.png!
>
> {code:java}
> $ java -version
> openjdk version "13-ea" 2019-09-17
> OpenJDK Runtime Environment (build 13-ea+28)
> OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
> h2. What does BCELifierTestCase do?
> The test compares two output of javap command:
> * javap "target/test-classes/Java8Example.class" (which is copied from
> ./src/test/resources/Java8Example.class in git)
> * javap another Java8Example.class which is generated by BCELifer.
> ** Actually the class file is not directly created by BCELifer.
> *** BCELifer writes Java8ExampleCreator.java
> *** The test runs "javac" to compile Java8ExampleCreator.
> *** The test runs "java" to run Java8ExampleCreator, which in turn generates
> Java8Example.class
> JDK 13's javap command adds "default" for the first Java8Example.class but
> not on the second one.
> h2. Question to Answer
> Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
> output should not change. Which part of BCEL relies on JDK?
> A. This question is irrelevant, because the output class files are all the
> same (see below).
> Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
> JDK 13?
> A. They are the same.
> Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
> * javap (screenshot shown above)
> !screenshot-2.png!
> * binary diff editor?
> Q. What about JDK 11?
> A. JDK 11's javap does not show "default" for both Java8Example.class files.
> JDK11's generated Java8Example.class has 1 attributes. The resulting
> Java8Example.class files are all the same across JDKs:
> {code}
> $ md5sum /tmp/target-jdk*/Java8Example.class
> f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk11/Java8Example.class
> f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk13/Java8Example.class
> f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk8/Java8Example.class{code}
> So it's the matter of javap command showing "default" or not.
> Q. JDK 13's javap outputs "default" under certain condition. What is the
> condition?
> A. It's when major.minor >= 52.0, as per
> http://hg.openjdk.java.net/jdk/jdk13/rev/77b54b2822cc
> h1. Root Cause
> Open JDK 13's javap shows "default" when major.minor >= 52.0 ([commit in June
> 2019|http://hg.openjdk.java.net/jdk/jdk13/rev/77b54b2822cc]). BCEL while
> BCELifier was not copying major.minor (default: "45.3").
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-bcel] garydgregory merged pull request #31: [BCEL-323]BCELifier to set major and minor versions
garydgregory merged pull request #31: [BCEL-323]BCELifier to set major and minor versions URL: https://github.com/apache/commons-bcel/pull/31 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-bcel] suztomo commented on issue #31: [BCEL-323]BCELifier to set major and minor versions
suztomo commented on issue #31: [BCEL-323]BCELifier to set major and minor versions URL: https://github.com/apache/commons-bcel/pull/31#issuecomment-510182653 Updated changes.xml. 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] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?focusedWorklogId=274999&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-274999
]
ASF GitHub Bot logged work on BCEL-323:
---
Author: ASF GitHub Bot
Created on: 10/Jul/19 18:32
Start Date: 10/Jul/19 18:32
Worklog Time Spent: 10m
Work Description: suztomo commented on pull request #31:
[BCEL-323]BCELifier to set major and minor versions
URL: https://github.com/apache/commons-bcel/pull/31
The continuous integration builds have been failing for JDK 13.
- The failing test was comparing the output of javap command. JDK 13's javap
outputs "default" if major.minor >= 52.0
- BCELifer was not copying major minor (default 45.3).
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: 274999)
Time Spent: 10m
Remaining Estimate: 0h
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h1. Problem
> With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
> [interface's default
> method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
> Memo for myself:
> {code:java}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
> h1. Difference causing Test Failure
> In OpenJDK 13, the default parameter for the interface disappears after
> BCELifier creates the class file.
> !screenshot-1.png!
>
> {code:java}
> $ java -version
> openjdk version "13-ea" 2019-09-17
> OpenJDK Runtime Environment (build 13-ea+28)
> OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
> h2. What does BCELifierTestCase do?
> The test compares two output of javap command:
> * javap "target/test-classes/Java8Example.class" (which is copied from
> ./src/test/resources/Java8Example.class in git)
> * javap another Java8Example.class which is generated by BCELifer.
> ** Actually the class file is not directly created by BCELifer.
> *** BCELifer writes Java8ExampleCreator.java
> *** The test runs "javac" to compile Java8ExampleCreator.
> *** The test runs "java" to run Java8ExampleCreator, which in turn generates
> Java8Example.class
> JDK 13's javap command adds "default" for the first Java8Example.class but
> not on the second one.
> h2. Question to Answer
> Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
> output should not change. Which part of BCEL relies on JDK?
> A. This question is irrelevant, because the output class files are all the
> same (see below).
> Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
> JDK 13?
> A. They are the same.
> Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
> * javap (screenshot shown above)
> !screenshot-2.png!
> * binary diff editor?
> Q. What about JDK 11?
> A. JDK 11's javap does not show "default" for both Java8Example.class files.
> JDK11's generated Java8Example.class has 1 attributes. The resulting
> Java8Example.class files are all the same across JDKs:
> {code}
> $ md5sum /tmp/target-jdk*/Java8Example.class
> f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk11/Java8Example.class
> f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk13/Java8Example.class
> f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk8/Java8Example.class{code}
> So it's the matter of javap command showing "default" or not.
> Q. JDK 13's javap outputs "default" under certain condition. What is the
> condition?
> A. It's when major.minor >= 52.0, as per
> http://hg.openjdk.java.net/jdk/jdk13/rev/77b54b2822cc
> h1. Root Cause
> Open JDK 13's javap shows "default" when major.minor >= 52.0 ([commit in June
> 2019|http://hg.openjdk.java.net
[GitHub] [commons-bcel] suztomo opened a new pull request #31: [BCEL-323]BCELifier to set major and minor versions
suztomo opened a new pull request #31: [BCEL-323]BCELifier to set major and minor versions URL: https://github.com/apache/commons-bcel/pull/31 The continuous integration builds have been failing for JDK 13. - The failing test was comparing the output of javap command. JDK 13's javap outputs "default" if major.minor >= 52.0 - BCELifer was not copying major minor (default 45.3). 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] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
h1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
A. This question is irrelevant, because the output class files are all the same
(see below).
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
* javap (screenshot shown above)
!screenshot-2.png!
* binary diff editor?
Q. What about JDK 11?
A. JDK 11's javap does not show "default" for both Java8Example.class files.
JDK11's generated Java8Example.class has 1 attributes. The resulting
Java8Example.class files are all the same across JDKs:
{code}
$ md5sum /tmp/target-jdk*/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk11/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk13/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk8/Java8Example.class{code}
So it's the matter of javap command showing "default" or not.
Q. JDK 13's javap outputs "default" under certain condition. What is the
condition?
A. It's when major.minor >= 52.0, as per
http://hg.openjdk.java.net/jdk/jdk13/rev/77b54b2822cc
h1. Root Cause
Open JDK 13's javap shows "default" when major.minor >= 52.0 ([commit in June
2019|http://hg.openjdk.java.net/jdk/jdk13/rev/77b54b2822cc]). BCEL while
BCELifier was not copying major.minor (default: "45.3").
was:
h1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
[GitHub] [commons-imaging] kinow edited a comment on issue #49: Add support for EXIF 2.32
kinow edited a comment on issue #49: Add support for EXIF 2.32 URL: https://github.com/apache/commons-imaging/pull/49#issuecomment-510173518 Yeah, that's a not very nice issue finding the tags... but I think that's probably better done in another PR later. 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] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
h1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
A. This question is irrelevant, because the output class files are all the same
(see below).
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
* javap (screenshot shown above)
!screenshot-2.png!
* binary diff editor?
Q. What about JDK 11?
A. JDK 11's javap does not show "default" for both Java8Example.class files.
JDK11's generated Java8Example.class has 1 attributes. The resulting
Java8Example.class files are all the same across JDKs:
{code}
$ md5sum /tmp/target-jdk*/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk11/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk13/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk8/Java8Example.class{code}
So it's the matter of javap command showing "default" or not.
Q. JDK 13's javap outputs "default" under certain condition. What is the
condition?
A. It's when major.minor >= 52.0, as per
http://hg.openjdk.java.net/jdk/jdk13/rev/77b54b2822cc
h1. Root Cause
Open JDK 13's javap shows "default" when major.minor >= 52.0. BCEL while
BCELifier was not copying major.minor (default: "45.3").
was:
h1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8E
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
h1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
A. This question is irrelevant, because the output class files are all the same
(see below).
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
* javap (screenshot shown above)
!screenshot-2.png!
* binary diff editor?
Q. What about JDK 11?
A. JDK 11's javap does not show "default" for both Java8Example.class files.
JDK11's generated Java8Example.class has 1 attributes. The resulting
Java8Example.class files are all the same across JDKs:
{code}
$ md5sum /tmp/target-jdk*/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk11/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk13/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk8/Java8Example.class{code}
So it's the matter of javap command showing "default" or not.
Q. JDK 13's javap outputs "default" under certain condition. What is the
condition?
A. It's when major.minor >= 52.0, as per
http://hg.openjdk.java.net/jdk/jdk13/rev/77b54b2822cc
was:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output
[GitHub] [commons-imaging] kinow commented on issue #49: Add support for EXIF 2.32
kinow commented on issue #49: Add support for EXIF 2.32 URL: https://github.com/apache/commons-imaging/pull/49#issuecomment-510173518 Yeah, that's a not very nice issue finsing the tags... but I think that's probably better done in another PR later. 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] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
A. This question is irrelevant, because the output class files are all the same
(see below).
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
* javap (screenshot shown above)
!screenshot-2.png!
* binary diff editor?
Q. What about JDK 11?
A. JDK 11's javap does not show "default" for both Java8Example.class files.
JDK11's generated Java8Example.class has 1 attributes. The resulting
Java8Example.class files are all the same across JDKs:
{code}
$ md5sum /tmp/target-jdk*/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk11/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk13/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk8/Java8Example.class{code}
So it's the matter of javap command showing "default" or not.
Q. JDK 13's javap outputs "default" under certain condition. What is the
condition?
A. It's when major.minor >= 52.0, as per
http://hg.openjdk.java.net/jdk/jdk13/rev/77b54b2822cc
was:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
outp
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
A. This question is irrelevant, because the output class files are all the same
(see below).
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
* javap (screenshot shown above)
!screenshot-2.png!
* binary diff editor?
Q. What about JDK 11?
A. JDK 11's javap does not show "default" for both Java8Example.class files.
JDK11's generated Java8Example.class has 1 attributes. The resulting
Java8Example.class files are all the same across JDKs:
{code}
$ md5sum /tmp/target-jdk*/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk11/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk13/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk8/Java8Example.class{code}
So it's the matter of javap command showing "default" or not.
Q. JDK 13's javap outputs "default" under certain condition. What is the
condition?
was:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
Q. Is there difference between Java8Ex
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
* javap (screenshot shown above)
!screenshot-2.png!
* binary diff editor?
Q. What about JDK 11?
A. JDK 11's javap does not show "default" for both Java8Example.class files.
JDK11's generated Java8Example.class has 1 attributes. The resulting
Java8Example.class files are all the same across JDKs:
{code}
$ md5sum /tmp/target-jdk*/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk11/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk13/Java8Example.class
f4c51ee3d4864cb226e79cfca8dbe6da /tmp/target-jdk8/Java8Example.class{code}
So it's the matter of javap command showing "default" or not.
Q. Which part of BCEL/BCELifer is responsible to write "default" into class
files.
A. This question is irrelevant, because the output class files are all the same.
was:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
Q. Is there difference between Java8ExampleCreator.j
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
* javap (screenshot shown above)
!screenshot-2.png!
* binary diff editor?
Q. What about JDK 11?
A. JDK 11's javap does not show "default" for both Java8Example.class files
Q. Which part of BCEL/BCELifer is responsible to write "default" into class
files.
was:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
* javap (screenshot shown above)
!screenshot-2.png!
* binary diff editor?
Q. Which part of BCEL/BCELifer is responsible to write "default" into class
files.
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-3
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
JDK 13's javap command adds "default" for the first Java8Example.class but not
on the second one.
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
* javap (screenshot shown above)
!screenshot-2.png!
* binary diff editor?
Q. Which part of BCEL/BCELifer is responsible to write "default" into class
files.
was:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
* javap (screenshot shown above)
* binary diff editor
Q. Which part of BCEL/BCELifer is responsible to write "default" into class
files.
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> fdh1. Problem
> With
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Attachment: screenshot-2.png
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> fdh1. Problem
> With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
> [interface's default
> method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
> Memo for myself:
> {code:java}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
> h1. Difference causing Test Failure
> In OpenJDK 13, the default parameter for the interface disappears after
> BCELifier creates the class file.
> !screenshot-1.png!
>
> {code:java}
> $ java -version
> openjdk version "13-ea" 2019-09-17
> OpenJDK Runtime Environment (build 13-ea+28)
> OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
> h2. What does BCELifierTestCase do?
> The test compares two output of javap command:
> * javap "target/test-classes/Java8Example.class" (which is copied from
> ./src/test/resources/Java8Example.class in git)
> * javap another Java8Example.class which is generated by BCELifer.
> ** Actually the class file is not directly created by BCELifer.
> *** BCELifer writes Java8ExampleCreator.java
> *** The test runs "javac" to compile Java8ExampleCreator.
> *** The test runs "java" to run Java8ExampleCreator, which in turn generates
> Java8Example.class
> h2. Question to Answer
> Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
> output should not change. Which part of BCEL relies on JDK?
> Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
> JDK 13?
> A. They are the same.
> Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
> * javap (screenshot shown above)
> * binary diff editor
> Q. Which part of BCEL/BCELifer is responsible to write "default" into class
> files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
Q. How to see the difference between Java8Example.class from JDK 8 and JDK 13?
* javap (screenshot shown above)
* binary diff editor
Q. Which part of BCEL/BCELifer is responsible to write "default" into class
files.
was:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> fdh1. Problem
> With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
> [interface's default
> method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->tes
[GitHub] [commons-imaging] GITNE edited a comment on issue #49: Add support for EXIF 2.32
GITNE edited a comment on issue #49: Add support for EXIF 2.32 URL: https://github.com/apache/commons-imaging/pull/49#issuecomment-510045676 > [ERROR] TiffTagIntegrityTest.testTagIntegrity:62->verifyFields:115 Missing tag 34867 Thank you for catching this. :+1: I have rebased the faulty commit. I have one commit yet to come. It is just basically a reorder of `ALL_*_TAGS` lists by tag id. Additionally, IMHO all non-standard tags should either be put into separate `*TagConstants` classes or an `Extension` nested class per IFD. So, for example `GpsTagConstants` should/could actually be a nested class of `ExifTagConstants` since it is an extension of Exif but in a separate IFD. Primitve non-standard tags which live in the Exif IFD should then go into the generic `Extension` nested class of `ExifTagConstants`. `ExifTagConstants` would then be a nested class of `TiffTagConstants`. Alternatively, instead of using nested classes inheritance could be employed to model the relationships between tag sets. So, why might this be useful? The current code model produces ambiguous tag names, like `EXIF_TAG_WHITE_BALANCE_1`, `EXIF_TAG_WHITE_BALANCE_2`, … etc. Currently, `EXIF_TAG_WHITE_BALANCE_1` is the name of the Exif standard tag and `EXIF_TAG_WHITE_BALANCE_2` is a vendor specific non-standard extension to white balance metadata. Library consumers have basically no way of figuring out which one is which, unless they look into the source code or reverse engineer the behavior by reading the tag id. So, I would like to change this too. However, this might be something for a separate PR, right? 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-codec] garydgregory commented on a change in pull request #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations.
garydgregory commented on a change in pull request #22: CODEC-236: MurmurHash2
and MurmurHash3 implementations.
URL: https://github.com/apache/commons-codec/pull/22#discussion_r302111091
##
File path: src/main/java/org/apache/commons/codec/digest/MurmurHash2.java
##
@@ -0,0 +1,215 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.commons.codec.digest;
+
+/**
+ * MurmurHash2 yields a 32-bit or 64-bit value.
+ *
+ * MurmurHash is a non-cryptographic hash function suitable for general
+ * hash-based lookup. The name comes from two basic operations, multiply (MU)
+ * and rotate (R), used in its inner loop. Unlike cryptographic hash functions,
+ * it is not specifically designed to be difficult to reverse by an adversary,
+ * making it unsuitable for cryptographic purposes.
+ *
+ * This is a re-implementation of the original C code plus some additional
+ * features.
+ *
+ * Public domain.
+ *
+ * @author Viliam Holub
+ * @see https://en.wikipedia.org/wiki/MurmurHash";>MurmurHash
+ * @since 1.13
+ */
+public final class MurmurHash2 {
+
+ // all methods static; private constructor.
Review comment:
NOT all methods should be static: You should implement Codec's
`BinaryEncoder` and `BinaryDecoder` interfaces and/or `StringEncoder` and
`StringDecoder` depending on the use cases of this code.
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-codec] garydgregory commented on a change in pull request #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations.
garydgregory commented on a change in pull request #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations. URL: https://github.com/apache/commons-codec/pull/22#discussion_r302109031 ## File path: src/main/java/org/apache/commons/codec/digest/MurmurHash2.java ## @@ -0,0 +1,215 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.commons.codec.digest; + +/** + * MurmurHash2 yields a 32-bit or 64-bit value. + * + * MurmurHash is a non-cryptographic hash function suitable for general + * hash-based lookup. The name comes from two basic operations, multiply (MU) + * and rotate (R), used in its inner loop. Unlike cryptographic hash functions, + * it is not specifically designed to be difficult to reverse by an adversary, + * making it unsuitable for cryptographic purposes. + * + * This is a re-implementation of the original C code plus some additional + * features. + * + * Public domain. + * + * @author Viliam Holub Review comment: @melloware Thank you for your PR. We recommend _against_ using author tags, please remove them. 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-codec] garydgregory commented on a change in pull request #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations.
garydgregory commented on a change in pull request #22: CODEC-236: MurmurHash2
and MurmurHash3 implementations.
URL: https://github.com/apache/commons-codec/pull/22#discussion_r302111328
##
File path: src/main/java/org/apache/commons/codec/digest/MurmurHash3.java
##
@@ -0,0 +1,551 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.commons.codec.digest;
+
+/**
+ * MurmurHash3 yields a 32-bit or 128-bit value.
+ *
+ * MurmurHash is a non-cryptographic hash function suitable for general
+ * hash-based lookup. The name comes from two basic operations, multiply (MU)
+ * and rotate (R), used in its inner loop. Unlike cryptographic hash functions,
+ * it is not specifically designed to be difficult to reverse by an adversary,
+ * making it unsuitable for cryptographic purposes.
+ *
+ * 32-bit Java port of
+ * https://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp#94
+ * 128-bit Java port of
+ * https://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp#255
+ *
+ * This is a public domain code with no copyrights. From homepage of MurmurHash
+ * (https://code.google.com/p/smhasher/), "All MurmurHash versions are public
+ * domain software, and the author disclaims all copyright to their code."
+ *
+ * Copied from Apache Hive:
+ *
https://github.com/apache/hive/blob/master/storage-api/src/java/org/apache/hive/common/util/Murmur3.java
+ *
+ * @see https://en.wikipedia.org/wiki/MurmurHash";>MurmurHash
+ * @since 1.13
+ */
+public final class MurmurHash3 {
Review comment:
NOT all methods should be static: You should implement Codec's
`BinaryEncoder` and `BinaryDecoder` interfaces and/or `StringEncoder` and
`StringDecoder` depending on the use cases of this code.
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-321) Refactor subclasses of ClassPathRepository for differences in underlying cache
[ https://issues.apache.org/jira/browse/BCEL-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16882141#comment-16882141 ] Tomo Suzuki commented on BCEL-321: -- [~ggregory] Thank you. > Refactor subclasses of ClassPathRepository for differences in underlying cache > -- > > Key: BCEL-321 > URL: https://issues.apache.org/jira/browse/BCEL-321 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > Fix For: 6.4.0 > > Attachments: classpathrepository_code_duplicate.png > > Time Spent: 20m > Remaining Estimate: 0h > > (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) > BCEL has different ClassPathRepository classes with slight modification in > its underlying cache: > * ClassPathRepository uses HashMap for JavaClass cache > * MemorySensitiveClassPathRepository uses HashMap SoftReference > * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap JavaClass> for JavaClass cache > The logic of loadClass, storeClass, and findClass methods are almost same > (attached screenshot of ClassPathRepository and > MemorySensitiveClassPathRepository as below). I think they can leverage an > abstraction over the internal cache so that they will have less duplicate > code. > After BCEL-320, I'm thinking to create a PR for the abstraction. > !classpathrepository_code_duplicate.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
fdh1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
h2. Question to Answer
Q. In theory, because Java8Example.class is generated by BCEL, not JDK, the
output should not change. Which part of BCEL relies on JDK?
Q. Is there difference between Java8ExampleCreator.java files from JDK 8 and
JDK 13?
A. They are the same.
was:
h1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
h2. Question to Answer
In theory, because Java8Example.class is generated by BCEL, not JDK, the output
should not change. Which part of BCEL relies on JDK?
Is there difference between Java8ExampleCreator.java files from JDK 8 and JDK
13?
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> fdh1. Problem
> With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
> [interface's default
> method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checkin
[jira] [Closed] (COLLECTIONS-724) Simplify two remove-if loops #77
[ https://issues.apache.org/jira/browse/COLLECTIONS-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed COLLECTIONS-724. Resolution: Fixed In git master. > Simplify two remove-if loops #77 > > > Key: COLLECTIONS-724 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-724 > Project: Commons Collections > Issue Type: Improvement >Reporter: Gary Gregory >Priority: Major > > Simplify two remove-if loops #77 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Moved] (COLLECTIONS-724) Simplify two remove-if loops #77
[ https://issues.apache.org/jira/browse/COLLECTIONS-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory moved BCEL-324 to COLLECTIONS-724: --- Workflow: Default workflow, editable Closed status (was: classic default workflow) Key: COLLECTIONS-724 (was: BCEL-324) Project: Commons Collections (was: Commons BCEL) > Simplify two remove-if loops #77 > > > Key: COLLECTIONS-724 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-724 > Project: Commons Collections > Issue Type: Improvement >Reporter: Gary Gregory >Priority: Major > > Simplify two remove-if loops #77 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (BCEL-324) Simplify two remove-if loops #77
Gary Gregory created BCEL-324: - Summary: Simplify two remove-if loops #77 Key: BCEL-324 URL: https://issues.apache.org/jira/browse/BCEL-324 Project: Commons BCEL Issue Type: Improvement Reporter: Gary Gregory Simplify two remove-if loops #77 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-collections] garydgregory merged pull request #77: Simplify two remove-if loops
garydgregory merged pull request #77: Simplify two remove-if loops URL: https://github.com/apache/commons-collections/pull/77 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] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
h1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
h2. Question to Answer
In theory, because Java8Example.class is generated by BCEL, not JDK, the output
should not change. Which part of BCEL relies on JDK?
Is there difference between Java8ExampleCreator.java files from JDK 8 and JDK
13?
was:
h1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> h1. Problem
> With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
> [interface's default
> method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
> Memo for myself:
> {code:java}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
> h1. Difference causing Test Failure
> In OpenJDK 13, the default parameter for the interface disappears after
> BCELifier creates the class file.
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
h1. Problem
With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
[interface's default
method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:java}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
was:
h1. Problem
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> h1. Problem
> With OpenJDK 13 EA, BCELifer does not give "default" modifier for an
> [interface's default
> method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html].
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
> Memo for myself:
> {code:java}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
> h1. Difference causing Test Failure
> In OpenJDK 13, the default parameter for the interface disappears after
> BCELifier creates the class file.
> !screenshot-1.png!
>
> {code:java}
> $ java -version
> openjdk version "13-ea" 2019-09-17
> OpenJDK Runtime Environment (build 13-ea+28)
> OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
> h2. What does BCELifierTestCase do?
> The test compares two output of javap command:
> * javap "target/test-classes/Java8Example.class" (which is copied from
> ./src/test/resources/Java8Example.class in git)
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
h1. Problem
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code:java}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class in git)
* javap another Java8Example.class which is generated by BCELifer.
** Actually the class file is not directly created by BCELifer.
*** BCELifer writes Java8ExampleCreator.java
*** The test runs "javac" to compile Java8ExampleCreator.
*** The test runs "java" to run Java8ExampleCreator, which in turn generates
Java8Example.class
was:
h1. Problem
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:bash}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class)
* javap another Java8Example.class which is
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> h1. Problem
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
> Memo for myself:
> {code}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
> h1. Difference causing Test Failure
> In OpenJDK 13, the default parameter for the interface disappears after
> BCELifier creates the class file.
> !screenshot-1.png!
>
> {code:java}
> $ java -version
> openjdk version "13-ea" 2019-09-17
> OpenJDK Runtime Environment (build 13-ea+28)
> OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
> h2. What does BCELifierTestCase do?
> The test compares two output of javap command:
> * javap "target/test-classes/Java8Example.class" (which is copied from
> ./src/test/resources/Java8Example.class in git)
> * javap another Java8Example.class which is generated by BCELifer.
> ** Actually the class file is not directly created by BCELifer.
> *** BCELifer writes Java8ExampleCreator.java
> *** The test runs "javac" to compile Java8ExampleCreator.
> *** The test runs "java" to run Java8ExampleCreator, which in turn generates
> Java8Example.class
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-bcel] garydgregory merged pull request #30: Fix mvn site build
garydgregory merged pull request #30: Fix mvn site build URL: https://github.com/apache/commons-bcel/pull/30 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] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
h1. Problem
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:bash}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter for the interface disappears after
BCELifier creates the class file.
!screenshot-1.png!
{code}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
h2. What does BCELifierTestCase do?
The test compares two output of javap command:
* javap "target/test-classes/Java8Example.class" (which is copied from
./src/test/resources/Java8Example.class)
* javap another Java8Example.class which is
was:
h1. Problem
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:bash}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter disappears after
!screenshot-1.png!
{code}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> h1. Problem
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
> Memo for myself:
> {code:bash}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
> h1. Difference causing Test Failure
> In OpenJDK 13, the default parameter for the interface disappears after
> BCELifier creates the class file.
> !screenshot-1.png!
>
> {code}
> $ java -version
> openjdk version "13-ea" 2019-09-17
> OpenJDK Runtime Environment (build 13-ea+28)
> OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
> h2. What does BCELifierTestCase do?
> The test compares two output of javap command:
> * javap "target/test-classes/Java8Example.class" (which is copied from
> ./src/test/resources/Java8Example.class)
> * javap another Java8Example.class which is
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
h1. Problem
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:bash}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Difference causing Test Failure
In OpenJDK 13, the default parameter disappears after
!screenshot-1.png!
{code}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
was:
h1. Problem
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:bash}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Root Cause
In OpenJDK 13, the default parameter disappears after
!screenshot-1.png!
{code}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> h1. Problem
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
>
> Memo for myself:
> {code:bash}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
> h1. Difference causing Test Failure
> In OpenJDK 13, the default parameter disappears after
> !screenshot-1.png!
>
> {code}
> $ java -version
> openjdk version "13-ea" 2019-09-17
> OpenJDK Runtime Environment (build 13-ea+28)
> OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
h1. Problem
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:bash}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
h1. Root Cause
In OpenJDK 13, the default parameter disappears after
!screenshot-1.png!
{code}
$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+28)
OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
was:
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:bash}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> h1. Problem
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
> {code}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
>
> Memo for myself:
> {code:bash}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
> h1. Root Cause
> In OpenJDK 13, the default parameter disappears after
> !screenshot-1.png!
>
> {code}
> $ java -version
> openjdk version "13-ea" 2019-09-17
> OpenJDK Runtime Environment (build 13-ea+28)
> OpenJDK 64-Bit Server VM (build 13-ea+28, mixed mode, sharing){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Attachment: screenshot-1.png
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
>
> {code}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
>
> Memo for myself:
> {code:bash}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (BCEL-321) Refactor subclasses of ClassPathRepository for differences in underlying cache
[ https://issues.apache.org/jira/browse/BCEL-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed BCEL-321. - Resolution: Fixed Fix Version/s: 6.4.0 In git master. > Refactor subclasses of ClassPathRepository for differences in underlying cache > -- > > Key: BCEL-321 > URL: https://issues.apache.org/jira/browse/BCEL-321 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > Fix For: 6.4.0 > > Attachments: classpathrepository_code_duplicate.png > > Time Spent: 20m > Remaining Estimate: 0h > > (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) > BCEL has different ClassPathRepository classes with slight modification in > its underlying cache: > * ClassPathRepository uses HashMap for JavaClass cache > * MemorySensitiveClassPathRepository uses HashMap SoftReference > * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap JavaClass> for JavaClass cache > The logic of loadClass, storeClass, and findClass methods are almost same > (attached screenshot of ClassPathRepository and > MemorySensitiveClassPathRepository as below). I think they can leverage an > abstraction over the internal cache so that they will have less duplicate > code. > After BCEL-320, I'm thinking to create a PR for the abstraction. > !classpathrepository_code_duplicate.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-imaging] GITNE commented on issue #49: Add support for EXIF 2.32
GITNE commented on issue #49: Add support for EXIF 2.32 URL: https://github.com/apache/commons-imaging/pull/49#issuecomment-510045676 > [ERROR] TiffTagIntegrityTest.testTagIntegrity:62->verifyFields:115 Missing tag 34867 Thank you for catching this. :+1: I have rebased the faulty commit. I have one commit yet to come. It is just basically a reorder of `ALL_*_TAGS` lists by tag id. Additionally, IMHO all non-standard tags should either be put into separate `*TagConstants` classes or an `Extension` nested class per IFD. So, for example `GpsTagConstants` should/could actually be a nested class of ExifTagConstants since it is an extension of Exif but in a separate IFD. Extension/non-standard tags which live in the Exif IFD should then go into the generic `Extension` nested class of `ExifTagConstants`. `ExifTagConstants` would then be a nested class of `TiffTagConstants`. Alternatively, instead of using nested classes inheritance could be employed to model the relationships between tag sets. So, why might this be useful? The current code model produces ambiguous tag names, like `EXIF_TAG_WHITE_BALANCE_1`, `EXIF_TAG_WHITE_BALANCE_2`, … etc. Currently, `EXIF_TAG_WHITE_BALANCE_1` is the name of the Exif standard tag and `EXIF_TAG_WHITE_BALANCE_2` is a vendor specific non-standard extension to white balance metadata. Library consumers have basically no way of figuring out which one is which, unless they look into the source code or reverse engineer the behavior by reading the tag id. So, I would like to change this too. However, this might be something for a separate PR, right? 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] [Updated] (BCEL-321) Refactor subclasses of ClassPathRepository for differences in underlying cache
[ https://issues.apache.org/jira/browse/BCEL-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated BCEL-321: -- Summary: Refactor subclasses of ClassPathRepository for differences in underlying cache (was: Subclasses of ClassPathRepository only differ by its underlying cache?) > Refactor subclasses of ClassPathRepository for differences in underlying cache > -- > > Key: BCEL-321 > URL: https://issues.apache.org/jira/browse/BCEL-321 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > Attachments: classpathrepository_code_duplicate.png > > Time Spent: 20m > Remaining Estimate: 0h > > (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) > BCEL has different ClassPathRepository classes with slight modification in > its underlying cache: > * ClassPathRepository uses HashMap for JavaClass cache > * MemorySensitiveClassPathRepository uses HashMap SoftReference > * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap JavaClass> for JavaClass cache > The logic of loadClass, storeClass, and findClass methods are almost same > (attached screenshot of ClassPathRepository and > MemorySensitiveClassPathRepository as below). I think they can leverage an > abstraction over the internal cache so that they will have less duplicate > code. > After BCEL-320, I'm thinking to create a PR for the abstraction. > !classpathrepository_code_duplicate.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (BCEL-321) Subclasses of ClassPathRepository only differ by its underlying cache?
[ https://issues.apache.org/jira/browse/BCEL-321?focusedWorklogId=274844&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-274844 ] ASF GitHub Bot logged work on BCEL-321: --- Author: ASF GitHub Bot Created on: 10/Jul/19 12:41 Start Date: 10/Jul/19 12:41 Worklog Time Spent: 10m Work Description: garydgregory commented on pull request #29: [BCEL-321] AbstractClassPathRepository to share findClass logic for repositories URL: https://github.com/apache/commons-bcel/pull/29 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: 274844) Time Spent: 20m (was: 10m) > Subclasses of ClassPathRepository only differ by its underlying cache? > -- > > Key: BCEL-321 > URL: https://issues.apache.org/jira/browse/BCEL-321 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > Attachments: classpathrepository_code_duplicate.png > > Time Spent: 20m > Remaining Estimate: 0h > > (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) > BCEL has different ClassPathRepository classes with slight modification in > its underlying cache: > * ClassPathRepository uses HashMap for JavaClass cache > * MemorySensitiveClassPathRepository uses HashMap SoftReference > * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap JavaClass> for JavaClass cache > The logic of loadClass, storeClass, and findClass methods are almost same > (attached screenshot of ClassPathRepository and > MemorySensitiveClassPathRepository as below). I think they can leverage an > abstraction over the internal cache so that they will have less duplicate > code. > After BCEL-320, I'm thinking to create a PR for the abstraction. > !classpathrepository_code_duplicate.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-bcel] garydgregory merged pull request #29: [BCEL-321] AbstractClassPathRepository to share findClass logic for repositories
garydgregory merged pull request #29: [BCEL-321] AbstractClassPathRepository to share findClass logic for repositories URL: https://github.com/apache/commons-bcel/pull/29 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] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:bash}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin:$PATH{code}
was:
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:bash}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin{code}:$PATH
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
>
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
>
> {code}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
>
> Memo for myself:
> {code:bash}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin:$PATH{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:bash}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin{code}:$PATH
was:
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:bash}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin{code}
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
>
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
>
> {code}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
>
> Memo for myself:
> {code:bash}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin{code}:$PATH
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
[
https://issues.apache.org/jira/browse/BCEL-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-323:
-
Description:
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
Memo for myself:
{code:bash}
export JAVA_HOME=${HOME}/local/jdk-13
export PATH=${JAVA_HOME}/bin{code}
was:
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
> JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
> --
>
> Key: BCEL-323
> URL: https://issues.apache.org/jira/browse/BCEL-323
> Project: Commons BCEL
> Issue Type: Improvement
>Reporter: Tomo Suzuki
>Priority: Minor
>
> [https://travis-ci.org/apache/commons-bcel/jobs/556441835]
>
> {code}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
> expected:<...a8Example {
> public [default ]void hello();
> Code:...> but was:<...a8Example {
> public []void hello();
> Code:...>
> [INFO]
> [ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
>
> I'm checking why it fails.
>
> Memo for myself:
> {code:bash}
> export JAVA_HOME=${HOME}/local/jdk-13
> export PATH=${JAVA_HOME}/bin{code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (BCEL-323) JDK 13 build failing in master: BCELifierTestCase.testJavapCompare
Tomo Suzuki created BCEL-323:
Summary: JDK 13 build failing in master:
BCELifierTestCase.testJavapCompare
Key: BCEL-323
URL: https://issues.apache.org/jira/browse/BCEL-323
Project: Commons BCEL
Issue Type: Improvement
Reporter: Tomo Suzuki
[https://travis-ci.org/apache/commons-bcel/jobs/556441835]
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] BCELifierTestCase.testJavapCompare:90->testClassOnPath:80
expected:<...a8Example {
public [default ]void hello();
Code:...> but was:<...a8Example {
public []void hello();
Code:...>
[INFO]
[ERROR] Tests run: 130, Failures: 1, Errors: 0, Skipped: 1{code}
I'm checking why it fails.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-imaging] coveralls commented on issue #49: Add support for EXIF 2.32
coveralls commented on issue #49: Add support for EXIF 2.32 URL: https://github.com/apache/commons-imaging/pull/49#issuecomment-510038394 [](https://coveralls.io/builds/24475572) Coverage increased (+0.05%) to 74.467% when pulling **3ee1beb214f1f8f5ae34842130e25f34fe02df36 on GITNE:exif_2.32** into **e6893414a699a5f2480f2d18dc9bc9e21a0cf15d 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
[GitHub] [commons-codec] coveralls commented on issue #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations.
coveralls commented on issue #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations. URL: https://github.com/apache/commons-codec/pull/22#issuecomment-510035888 [](https://coveralls.io/builds/24475440) Coverage decreased (-1.06%) to 91.327% when pulling **6d2b19a7aa854aed46a30f1f3927cbdbc6110c0c on melloware:CODEC-236** into **45a195e0776e2dfb85022f034aec3af191cf7dca 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
[GitHub] [commons-codec] melloware opened a new pull request #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations.
melloware opened a new pull request #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations. URL: https://github.com/apache/commons-codec/pull/22 All MurmurHash implementations are public domain. Credit was given in Javadoc where both implementations came from. 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] (CODEC-236) Add MurmurHash Implementation
[ https://issues.apache.org/jira/browse/CODEC-236?focusedWorklogId=274815&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-274815 ] ASF GitHub Bot logged work on CODEC-236: Author: ASF GitHub Bot Created on: 10/Jul/19 12:10 Start Date: 10/Jul/19 12:10 Worklog Time Spent: 10m Work Description: melloware commented on pull request #22: CODEC-236: MurmurHash2 and MurmurHash3 implementations. URL: https://github.com/apache/commons-codec/pull/22 All MurmurHash implementations are public domain. Credit was given in Javadoc where both implementations came from. 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: 274815) Time Spent: 10m Remaining Estimate: 0h > Add MurmurHash Implementation > - > > Key: CODEC-236 > URL: https://issues.apache.org/jira/browse/CODEC-236 > Project: Commons Codec > Issue Type: New Feature >Affects Versions: 1.10 >Reporter: David Mollitor >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > https://en.wikipedia.org/wiki/MurmurHash > Already exists an Apache implementation: > org.apache.hive.common.util.HashCodeUtil.murmurHash(byte[], int, int) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-236) Add MurmurHash Implementation
[ https://issues.apache.org/jira/browse/CODEC-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16881987#comment-16881987 ] Melloware commented on CODEC-236: - PR Submitted on GitHub. > Add MurmurHash Implementation > - > > Key: CODEC-236 > URL: https://issues.apache.org/jira/browse/CODEC-236 > Project: Commons Codec > Issue Type: New Feature >Affects Versions: 1.10 >Reporter: David Mollitor >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > https://en.wikipedia.org/wiki/MurmurHash > Already exists an Apache implementation: > org.apache.hive.common.util.HashCodeUtil.murmurHash(byte[], int, int) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-723) commons-vfs loads id-rsa if present even if not required
Chirag Pai created VFS-723: -- Summary: commons-vfs loads id-rsa if present even if not required Key: VFS-723 URL: https://issues.apache.org/jira/browse/VFS-723 Project: Commons VFS Issue Type: Bug Affects Versions: 2.3 Reporter: Chirag Pai commons-vfs loads id-rsa if present even if not required. Even if id-rsa is present, it should not be loaded automatically. This causes the SFTP connection to fail if id-rsa key file is present but the content is invalid. Failed with error Invalid private key format. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-collections] grimreaper opened a new pull request #77: collections: fix exception error message
grimreaper opened a new pull request #77: collections: fix exception error message URL: https://github.com/apache/commons-collections/pull/77 The exception error message does not include an '=' before every field. 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
