[
https://issues.jboss.org/browse/SHRINKRES-78?page=com.atlassian.jira.plug...
]
Andrew Rubinger edited comment on SHRINKRES-78 at 10/18/12 7:38 PM:
--------------------------------------------------------------------
It's funny; I consulted with some JVM and bytecode heads when writing this part of the
API because I hadn't expected this kind of overloading (including the return type) to
compile. Yet it did, to bytecode with includes the return type in the method signature.
So:
{code} /**
* Formats the resultant artifacts as an array of {@link File}s. If nothing matches
resolution, an empty array will
* be returned.
*
* @param type
* @return
* @throws IllegalArgumentException
* If the type is not specified
*/
File[] as(Class<File> type) throws IllegalArgumentException;
/**
* Formats the resultant artifact as an {@link InputStream}. If nothing matches
resolution, an empty array will be
* returned.
*
* @param type
* @return
* @throws IllegalArgumentException
* If the type is not specified
*/
InputStream[] as(Class<InputStream> type) throws
IllegalArgumentException;{code}
results in:
{code} // access flags 0x401
// signature (Ljava/lang/Class<Ljava/io/File;>;)[Ljava/io/File;
// declaration: java.io.File[] as(java.lang.Class<java.io.File>)
public abstract as(Ljava/lang/Class;)[Ljava/io/File; throws
java/lang/IllegalArgumentException
// access flags 0x401
// signature (Ljava/lang/Class<Ljava/io/InputStream;>;)[Ljava/io/InputStream;
// declaration: java.io.InputStream[] as(java.lang.Class<java.io.InputStream>)
public abstract as(Ljava/lang/Class;)[Ljava/io/InputStream; throws
java/lang/IllegalArgumentException
{code}
So it's unfortunate to see that JDK7 "fixed" this innocent issue. The
runtime is wired just fine with a less explicit interpretation by the compiler, as
evidenced by this:
http://kohsuke.org/2010/08/07/potd-bridge-method-injector/
For the time-being, I'm unsure what to do here. I rather like the API as it is.
Perhaps the medium-term solution is to add an Enforcer Plugin check to ensure we're
building with JDK6.
was (Author: alrubinger):
It's funny; I consulted with some JVM and bytecode heads when writing this part of
the API because I hadn't expected this kind of overloading (including the return type)
to compile. Yet it did, to bytecode with includes the return type in the method
signature:
{code}// class version 50.0 (50)
// access flags 0x601
public abstract interface org/jboss/shrinkwrap/resolver/api/maven/MavenFormatStage
implements org/jboss/shrinkwrap/resolver/api/FormatStage {
// compiled from: MavenFormatStage.java
// access flags 0x401
// signature
(Ljava/lang/Class<Lorg/jboss/shrinkwrap/resolver/api/maven/ResolvedArtifactInfo;>;)[Lorg/jboss/shrinkwrap/resolver/api/maven/ResolvedArtifactInfo;
// declaration: org.jboss.shrinkwrap.resolver.api.maven.ResolvedArtifactInfo[]
as(java.lang.Class<org.jboss.shrinkwrap.resolver.api.maven.ResolvedArtifactInfo>)
public abstract
as(Ljava/lang/Class;)[Lorg/jboss/shrinkwrap/resolver/api/maven/ResolvedArtifactInfo;
throws java/lang/IllegalArgumentException
// access flags 0x401
// signature
(Ljava/lang/Class<Lorg/jboss/shrinkwrap/resolver/api/maven/ResolvedArtifactInfo;>;)Lorg/jboss/shrinkwrap/resolver/api/maven/ResolvedArtifactInfo;
// declaration: org.jboss.shrinkwrap.resolver.api.maven.ResolvedArtifactInfo
asSingle(java.lang.Class<org.jboss.shrinkwrap.resolver.api.maven.ResolvedArtifactInfo>)
public abstract
asSingle(Ljava/lang/Class;)Lorg/jboss/shrinkwrap/resolver/api/maven/ResolvedArtifactInfo;
throws java/lang/IllegalArgumentException
org/jboss/shrinkwrap/resolver/api/NonUniqueResultException
org/jboss/shrinkwrap/resolver/api/NoResolvedResultException
}
{code}
So it's unfortunate to see that JDK7 "fixed" this innocent issue. The
runtime is wired just fine with a less explicit interpretation by the compiler, as
evidenced by this:
http://kohsuke.org/2010/08/07/potd-bridge-method-injector/
For the time-being, I'm unsure what to do here. I rather like the API as it is.
Perhaps the medium-term solution is to add an Enforcer Plugin check to ensure we're
building with JDK6.
Build under JDK 7 fails
-----------------------
Key: SHRINKRES-78
URL:
https://issues.jboss.org/browse/SHRINKRES-78
Project: ShrinkWrap Resolvers
Issue Type: Bug
Environment: jdk 7
Reporter: Michal Matloka
Assignee: Andrew Rubinger
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project
shrinkwrap-resolver-api: Compilation failure: Compilation failure:
[ERROR] \Dev\JBoss\shrinkwrap
resolver\api\src\main\java\org\jboss\shrinkwrap\resolver\api\FormatStage.java:[67,18]
error: name clash: as(Class<InputStream>) and as(Class<File>) have the same
erasure
[ERROR] \Dev\JBoss\shrinkwrap
resolver\api\src\main\java\org\jboss\shrinkwrap\resolver\api\FormatStage.java:[81,16]
error: name clash: asSingle(Class<InputStream>) and asSingle(Class<File>) have
the same erasure
{noformat}
This article describes cause of this problem:
http://notatube.blogspot.com/2010/07/interesting-change-to-method-signatu...
Resoluion - API change?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira