On Thu, Jan 28, 2010 at 10:05 AM, Les Hazlewood <[email protected]> wrote: > Yes, that was my next recommendation - to ask the community :)
Sent the email. > JavaEnvironment class in Shiro allows you to program to different APIs > depending on the platform. I've used this in the past when we > Would this be usable for your needs Kalle? I know there are still No - there's no code in the aspectj module that requires 1.6 - it's just that the aspectj libs on Central are compiled with 1.6, so going to 1.6 would merely be for convenience reasons only (for us). I'm sure I can get it to work with 1.5 one way or another (for example use earlier versions of aspectj libs, require 1.6 only that module or re-compile dependencies in 1.6). > quite a few Fortune 100 companies that are tied to JDK 1.5 in one way > or another, and we might abandon those users even if they may not have > a voice represented on the user list. It'd probably be better not to > have to switch unless there is a really compelling reason to do so > (e.g. new language feature or some critical API). Ah it's always those big dinosaurs. If you know that for a fact then I think it's settled. Agree with the principle that only if there's a really compelling reason. Kalle > On Thu, Jan 28, 2010 at 12:41 PM, Kalle Korhonen > <[email protected]> wrote: >> Actually I might feel differently :) I know it sucks that for these >> kind of projects there are much stronger requirements and demand to >> stick with older version of JVM even if most of the users of >> JSecurity/Shiro have happily moved on to newer JVMs ages ago. But >> there's bound to be a few poor souls who are limited to 1.5 Java for >> one reason or another. Since we've been compiling in 1.5 before an >> optional aspectJ module (currently detached) I don't think one >> supporting module is necessarily strong enough reason to move to 1.5, >> even it being end-of-lifed. But hey, I have a crazy idea, maybe we >> should just ask our users :) I'll send an email to users list on this. >> In the meantime, I'll look into making the aspectJ module compile on >> 1.5 (got the 1.5 jdk downloaded...). We can take the decision later >> based on that information. >> >> Kalle >> >> >> On Thu, Jan 28, 2010 at 6:36 AM, Les Hazlewood <[email protected]> wrote: >>> I believe the only reason is that we had a discussion thread about 4 >>> or so months ago concurring that we should use 1.5-compatible APIs >>> moving forward (we used to support 1.4 via RetroWeaver at the time). >>> >>> I tend to agree that if 1.5 is already end-of-lifed (and has been for >>> 4 months), it doesn't make much sense to release a brand new (first >>> ever) Shiro release that targets a platform that Sun no longer even >>> supports. >>> >>> Does anyone feel differently? >>> >>> On Tue, Jan 26, 2010 at 3:23 PM, Kalle Korhonen >>> <[email protected]> wrote: >>>> Bah, I just managed to break the build by adding the new aspectj >>>> module. It fails on: >>>> [INFO] Compilation failure >>>> /export/home/hudson/hudson/jobs/Shiro/workspace/trunk/support/aspectj/src/test/java/org/apache/shiro/aspectj/DummyServiceTest.java:[32,-1] >>>> cannot access >>>> org.apache.shiro.aspectj.AspectjAnnotationsAuthorizingMethodInterceptor >>>> bad class file: >>>> /export/home/hudson/hudson/jobs/Shiro/workspace/trunk/support/aspectj/target/classes/org/apache/shiro/aspectj/AspectjAnnotationsAuthorizingMethodInterceptor.class >>>> class file has wrong version 50.0, should be 49.0 >>>> >>>> I.e. the builder jdk is 1.5 but 1.6 is required. What I don't get >>>> though is that it just compiled that >>>> AspectjAnnotationsAuthorizingMethodInterceptor but I suppose it's >>>> actually the imported AspectJ classes that are built on jdk 1.6. Now, >>>> 1.5 was end-of-lifed last October. Funny, but I don't even have 1.5 >>>> jdk anymore on my system and Sun has really made it difficult to get >>>> to it anymore (just checked). >>>> >>>> What's our policy regarding supporting jre versions? The easiest fix >>>> is probably to use a different builder on Hudson, but we might be >>>> using jdk 1.5 for a reason. I can detach the new module in the >>>> meantime. >>>> >>>> Kalle >>>> >>> >> >
