Yep, I agree - I'm changing the Hudson target JDK to 1.6 and then I'll
re-enabled those methods and it should work.

On Mon, Feb 22, 2010 at 3:28 PM, Kalle Korhonen
<[email protected]> wrote:
> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply via email to