[jira] [Comment Edited] (MSHADE-228) Shade can incorrectly re-write an InterfaceMethodRef in the constant pool to a MethodRef
[
https://issues.apache.org/jira/browse/MSHADE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15331631#comment-15331631
]
Harvey Raja edited comment on MSHADE-228 at 6/15/16 12:30 PM:
--
BTW - looks like I can trivially work around it by bumping the ASM version:
{code}
org.apache.maven.plugins
maven-shade-plugin
org.ow2.asm
asm
5.1
org.ow2.asm
asm-commons
5.1
{code}
was (Author: harveyraja):
BTW - looks like I can trivially work around it by bumping the ASM version:
{code}
org.apache.maven.plugins
maven-shade-plugin
org.ow2.asm
asm
${asm.version}
org.ow2.asm
asm-commons
${asm.version}
{code}
> Shade can incorrectly re-write an InterfaceMethodRef in the constant pool to
> a MethodRef
>
>
> Key: MSHADE-228
> URL: https://issues.apache.org/jira/browse/MSHADE-228
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
>Reporter: Harvey Raja
>
> Given an interface such as:
> {code}
> public interface InvalidMethodRefExample
> {
> String getLocation();
> static InvalidMethodRefExample autoDetect()
> {
> return () -> "$Default$";
> }
> }
> {code}
> {{javac}} correctly produces a bootstrap method that has a {{MethodHandle}}
> for its second argument to {{LambdaMetafactory.metafactory}}, and the
> {{MethodHandle}} is to an {{InterfaceMethodref}}.
> After running shade the {{InterfaceMethodref}} becomes a {{Methodref}}.
> This seems to have been the result for some time now but with Java 9 it
> appears that the java team have decided to enforce this CP type and will be a
> real problem when using shade and Java 9.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSHADE-228) Shade can incorrectly re-write an InterfaceMethodRef in the constant pool to a MethodRef
[
https://issues.apache.org/jira/browse/MSHADE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15331631#comment-15331631
]
Harvey Raja commented on MSHADE-228:
BTW - looks like I can trivially work around it by bumping the ASM version:
{code}
org.apache.maven.plugins
maven-shade-plugin
org.ow2.asm
asm
${asm.version}
org.ow2.asm
asm-commons
${asm.version}
{code}
> Shade can incorrectly re-write an InterfaceMethodRef in the constant pool to
> a MethodRef
>
>
> Key: MSHADE-228
> URL: https://issues.apache.org/jira/browse/MSHADE-228
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
>Reporter: Harvey Raja
>
> Given an interface such as:
> {code}
> public interface InvalidMethodRefExample
> {
> String getLocation();
> static InvalidMethodRefExample autoDetect()
> {
> return () -> "$Default$";
> }
> }
> {code}
> {{javac}} correctly produces a bootstrap method that has a {{MethodHandle}}
> for its second argument to {{LambdaMetafactory.metafactory}}, and the
> {{MethodHandle}} is to an {{InterfaceMethodref}}.
> After running shade the {{InterfaceMethodref}} becomes a {{Methodref}}.
> This seems to have been the result for some time now but with Java 9 it
> appears that the java team have decided to enforce this CP type and will be a
> real problem when using shade and Java 9.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSHADE-228) Shade can incorrectly re-write an InterfaceMethodRef in the constant pool to a MethodRef
[
https://issues.apache.org/jira/browse/MSHADE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15329500#comment-15329500
]
Harvey Raja commented on MSHADE-228:
You will be able to see the difference in the constant pool in the ClassFile
generated by javac and the ClassFile generated by shade.
You can also run against java 9 to see the runtime error:
{code}
Exception in thread "main" java.lang.BootstrapMethodError:
java.lang.IncompatibleClassChangeError: Inconsistent constant data for
com/screwed/constantpool/InvalidMethodRefExample.lambda$autoDetect$0()Ljava/lang/String;
at index 26
at
com.screwed.constantpool.InvalidMethodRefExample.autoDetect(InvalidMethodRefExample.java:10)
at Test.main(Test.java:5)
Caused by: java.lang.IncompatibleClassChangeError: Inconsistent constant data
for
com/screwed/constantpool/InvalidMethodRefExample.lambda$autoDetect$0()Ljava/lang/String;
at index 26
... 2 more
{code}
> Shade can incorrectly re-write an InterfaceMethodRef in the constant pool to
> a MethodRef
>
>
> Key: MSHADE-228
> URL: https://issues.apache.org/jira/browse/MSHADE-228
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
>Reporter: Harvey Raja
>
> Given an interface such as:
> {code}
> public interface InvalidMethodRefExample
> {
> String getLocation();
> static InvalidMethodRefExample autoDetect()
> {
> return () -> "$Default$";
> }
> }
> {code}
> {{javac}} correctly produces a bootstrap method that has a {{MethodHandle}}
> for its second argument to {{LambdaMetafactory.metafactory}}, and the
> {{MethodHandle}} is to an {{InterfaceMethodref}}.
> After running shade the {{InterfaceMethodref}} becomes a {{Methodref}}.
> This seems to have been the result for some time now but with Java 9 it
> appears that the java team have decided to enforce this CP type and will be a
> real problem when using shade and Java 9.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSHADE-228) Shade can incorrectly re-write an InterfaceMethodRef in the constant pool to a MethodRef
[
https://issues.apache.org/jira/browse/MSHADE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15329499#comment-15329499
]
Harvey Raja commented on MSHADE-228:
Unfortunately I can not attach the maven project I have that shows the issue,
but other than the interface in the description there is the pom file:
{code}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0
com.screwed
constant-pool
Screwed Constant Pool
1.0-SNAPSHOT
org.apache.maven.plugins
maven-compiler-plugin
3.5.1
1.8
1.8
org.apache.maven.plugins
maven-shade-plugin
2.4.3
shade
package
shade
screwed-jar
false
true
true
*:*
META-INF/maven/**/*
org.something
com.screwed.something
{code}
> Shade can incorrectly re-write an InterfaceMethodRef in the constant pool to
> a MethodRef
>
>
> Key: MSHADE-228
> URL: https://issues.apache.org/jira/browse/MSHADE-228
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
>Reporter: Harvey Raja
>
> Given an interface such as:
> {code}
> public interface InvalidMethodRefExample
> {
> String getLocation();
> static InvalidMethodRefExample autoDetect()
> {
> return () -> "$Default$";
> }
> }
> {code}
> {{javac}} correctly produces a bootstrap method that has a {{MethodHandle}}
> for its second argument to {{LambdaMetafactory.metafactory}}, and the
> {{MethodHandle}} is to an {{InterfaceMethodref}}.
> After running shade the {{InterfaceMethodref}} becomes a {{Methodref}}.
> This seems to have been the result for some time now but with Java 9 it
> appears that the java team have decided to enforce this CP type and will be a
> real problem when using shade and Java 9.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MSHADE-228) Shade can incorrectly re-write an InterfaceMethodRef in the constant pool to a MethodRef
Harvey Raja created MSHADE-228:
--
Summary: Shade can incorrectly re-write an InterfaceMethodRef in
the constant pool to a MethodRef
Key: MSHADE-228
URL: https://issues.apache.org/jira/browse/MSHADE-228
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 2.4.3
Reporter: Harvey Raja
Given an interface such as:
{code}
public interface InvalidMethodRefExample
{
String getLocation();
static InvalidMethodRefExample autoDetect()
{
return () -> "$Default$";
}
}
{code}
{{javac}} correctly produces a bootstrap method that has a {{MethodHandle}} for
its second argument to {{LambdaMetafactory.metafactory}}, and the
{{MethodHandle}} is to an {{InterfaceMethodref}}.
After running shade the {{InterfaceMethodref}} becomes a {{Methodref}}.
This seems to have been the result for some time now but with Java 9 it appears
that the java team have decided to enforce this CP type and will be a real
problem when using shade and Java 9.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MEAR-161) Accept custom EarModule implementations
Harvey Raja created MEAR-161: Summary: Accept custom EarModule implementations Key: MEAR-161 URL: https://jira.codehaus.org/browse/MEAR-161 Project: Maven 2.x Ear Plugin Issue Type: Improvement Reporter: Harvey Raja It would be great if the plugin allowed users to specify custom EarModule, i.e. a Map configuration parameter with key being module type and value being the EarModule class implementation. This would allow any module types not specified in the jee spec to be supported by the plugin by vendors providing their own implementations. Additionally this could result in the generation of a container specific descriptor file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
