Yes, that was my next recommendation - to ask the community :) However, I'm totally ok with staying with 1.5 too. The JavaEnvironment class in Shiro allows you to program to different APIs depending on the platform. I've used this in the past when we supported 1.4 to return, say, a integer sequence for session IDs, whereas on 1.5, I just used the UUID class. I used the JavaEnvironment class to turn on or off functionality as necessary.
Would this be usable for your needs Kalle? I know there are still 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). - Les 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 >>> >> >
