Yeah, we did this crazy refactoring to move a part that had a similar issue with source level incompatibilities with different jdks to a separate module that was from there after used as a pre-compiled lib. We don't have the luxury to do so and I don't want to overcomplicate things. It seems that many projects are using jdk 1.6 compiler in Apache Hudson server though so I think the simplest thing to do is change the compiler to jdk1.6. There should a jdk section available in the job configuration if multiple jdks are installed - but only PMC members are allowed to access the configuration so can't be sure of this particular Hudson instance, so Les please take a look. The binaries will run the same on 1.5.
Kalle On Mon, Feb 22, 2010 at 9:37 AM, Kalle Korhonen <[email protected]> wrote: > Thanks for tracking it down. I think I had a similar case with a > different codebase - I'll dig it up and see if we can follow that. > > Kalle > > > On Mon, Feb 22, 2010 at 8:52 AM, Les Hazlewood <[email protected]> wrote: >> I figured it out - and it's just plain evil: >> >> The methods and argument types (at runtime) are essentially the same >> between 1.5 and 1.6. But the 1.5 ExecutorService API does not use >> generics captures for its method arguments while 1.6 does: >> >> 1.5: <T> T invokeAny(Collection<Callable<T>> tasks) ... >> >> 1.6: <T> T invokeAny(Collection<? extends Callable<T>> tasks) ... >> >> dunno how to resolve this. It simply won't compile on one or the >> other, depending on what method signature you want to declare. >> >> This is frustrating because the end runtime result is identical for both >> JVMs :( >> >> On Mon, Feb 22, 2010 at 11:13 AM, Kalle Korhonen >> <[email protected]> wrote: >>> It's a JDK5 thing. You need a cast somewhere to the proper subtype. >>> JDK6 is better/more lenient with these. 1.5 language level just checks >>> for the correctness of syntax but you will not catch errors like this >>> (or say, a missing class from rt.jar) if you don't use the right JDK. >>> I'll take a look - I was holding off since I knew you were working on >>> it. >>> >>> Kalle >>> >>> >>> On Mon, Feb 22, 2010 at 7:26 AM, Les Hazlewood <[email protected]> >>> wrote: >>>> Does anyone know why this is happening? The project compiles fine on >>>> all machines I've used. The implementation most certainly does >>>> implement the interface method that the Hudson build is complaining >>>> about. >>>> >>>> I'm assuming it's a JDK 1.5 vs 1.6 thing? Because the implementation >>>> does exist. My IDE is configured to use a 1.5 language level, but my >>>> maven build is running against 1.6. >>>> >>>> Any ideas? >>>> >>>> On Fri, Feb 19, 2010 at 6:16 PM, Apache Hudson Server >>>> <[email protected]> wrote: >>>>> See >>>>> <http://hudson.zones.apache.org/hudson/job/Shiro/org.apache.shiro$shiro-core/147/changes> >>>>> >>>>> Changes: >>>>> >>>>> [lhazlewood] SHIRO-140 - added initial implementations with basic tests. >>>>> More tests to come over the weekend. Need to document this in the wiki >>>>> too. >>>>> >>>>> ------------------------------------------ >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> [INFO] Building Apache Shiro :: Core >>>>> [INFO] task-segment: [deploy] >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> [INFO] [remote-resources:process {execution: default}] >>>>> [INFO] [resources:resources {execution: default-resources}] >>>>> [INFO] Using 'UTF-8' encoding to copy filtered resources. >>>>> [INFO] Copying 1 resource >>>>> [INFO] Copying 3 resources >>>>> [INFO] [compiler:compile {execution: default-compile}] >>>>> [INFO] Compiling 253 source files to >>>>> <http://hudson.zones.apache.org/hudson/job/Shiro/org.apache.shiro$shiro-core/ws/target/classes> >>>>> [HUDSON] Archiving >>>>> <http://hudson.zones.apache.org/hudson/job/Shiro/org.apache.shiro$shiro-core/ws/pom.xml> >>>>> to >>>>> /export/home/hudson/hudson/jobs/Shiro/modules/org.apache.shiro$shiro-core/builds/2010-02-19_23-16-04/archive/org.apache.shiro/shiro-core/1.0-incubating-SNAPSHOT/pom.xml >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> [ERROR] BUILD FAILURE >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> [INFO] Compilation failure >>>>> >>>>> <http://hudson.zones.apache.org/hudson/job/Shiro/org.apache.shiro$shiro-core/ws/src/main/java/org/apache/shiro/concurrent/SubjectAwareExecutorService.java>:[59,7] >>>>> org.apache.shiro.concurrent.SubjectAwareExecutorService is not abstract >>>>> and does not override abstract method >>>>> <T>invokeAny(java.util.Collection<java.util.concurrent.Callable<T>>,long,java.util.concurrent.TimeUnit) >>>>> in java.util.concurrent.ExecutorService >>>>> >>>>> <http://hudson.zones.apache.org/hudson/job/Shiro/org.apache.shiro$shiro-core/ws/src/main/java/org/apache/shiro/concurrent/SubjectAwareScheduledExecutorService.java>:[30,7] >>>>> org.apache.shiro.concurrent.SubjectAwareScheduledExecutorService is not >>>>> abstract and does not override abstract method >>>>> <T>invokeAny(java.util.Collection<java.util.concurrent.Callable<T>>,long,java.util.concurrent.TimeUnit) >>>>> in java.util.concurrent.ExecutorService >>>>> >>>>> >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> [INFO] For more information, run Maven with the -e switch >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> [INFO] Total time: 20 seconds >>>>> [INFO] Finished at: Fri Feb 19 23:16:40 UTC 2010 >>>>> [INFO] Final Memory: 27M/208M >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> Waiting for Hudson to finish collecting data >>>>> >>>>> >>>> >>> >> >
