[ 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. -- 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

[ https://issues.jboss.org/browse/SHRINKRES-78?page=com.atlassian.jira.plug... ] Andrew Rubinger updated SHRINKRES-78: ------------------------------------- Forum Reference: https://community.jboss.org/thread/208010 -- 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

[ https://issues.jboss.org/browse/SHRINKRES-78?page=com.atlassian.jira.plug... ] Andrew Rubinger resolved SHRINKRES-78. -------------------------------------- Resolution: Done Upstream: https://github.com/shrinkwrap/resolver/commit/30f40207c74674c46df50ca65a9... https://github.com/shrinkwrap/resolver/commit/010bf4045c6622a98fb4207285b... Verified as compiling in JDK7 in CI: https://shrinkwrap.ci.cloudbees.com/job/ShrinkWrap_Resolver_upstream-mast... -- 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

[ https://issues.jboss.org/browse/SHRINKRES-78?page=com.atlassian.jira.plug... ] Andrew Rubinger updated SHRINKRES-78: ------------------------------------- Fix Version/s: 2.0.0-alpha-5 -- 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