It's not a problem to keep supporting 'old' JDKs, if newer ones don't give you any significant advantage.
When Java 8 comes out with closures, that would be a big reason to break backwards compatibility (just like Java 5's generics). I don't see any of this in Java 7. Breaking compatibility just for the sake of it is not being 'bleeding edge', it's just begging to lose users. Tetsuo On Tue, Jul 5, 2011 at 10:20 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > :-) > The diamond notation is just about the declaration at the right side > of equals sign. This part is automatically typed for me by my IDE. > So I'd say it saves me some reading, not writing :-) > > On Tue, Jul 5, 2011 at 3:16 PM, Johan Compagner <jcompag...@gmail.com> wrote: >> the nice thing is that the diamond notation for generics is working >> out of the box when you can target 1.7 your self in your app. >> Thats can be quite a bit lot less typing of characters in wicket apps. >> >> >> On Tue, Jul 5, 2011 at 14:57, Martin Grigorov <mgrigo...@apache.org> wrote: >>> I'm saying only that JDK7 based solutions should be in a separate >>> module and pluggable. >>> If my application runs on JDK7 then I can replace the default >>> functionalityX (based on JDK5/6) with the improved one (based on >>> JDK7). >>> >>> On Tue, Jul 5, 2011 at 2:52 PM, Andrea Del Bene <adelb...@ciseonweb.it> >>> wrote: >>>> Well, I wasn't expecting a rapid or easy adoption of JDK7, but I think that >>>> is useful starting to explore how to parallelize some of the stages of >>>> Wicket's rendering pipeline. This could lead to a strong performance gain >>>> in >>>> the future, with adoption of JDK7 or using a parallel programming library. >>>>> >>>>> You know that Wicket still uses JDK 1.5 (not even 1.6) because many >>>>> users still use JDK1.5 and cannot upgrade to the newer. >>>>> So any improvements based on JDK7 should be out of wicket-core. They >>>>> can be plugged but the default impl should be 1.5 based. >>>>> For example you can create ModificationWatcher based on NIO2 but it >>>>> will in wicket-jdk7 module (or similar) or in wicketstuff project. >>>>> >>>>> For Wicket 1.6 we can move to JDK6 but this will be discussed later. >>>>> Usage of JDK7 for frameworks is not very close. >>>>> >>>>> On Tue, Jul 5, 2011 at 2:11 PM, Bruno Borges<bruno.bor...@gmail.com> >>>>> wrote: >>>>>> >>>>>> Some internals of Wicket don't use collections. Take for instance >>>>>> ResourceNameIterator. >>>>>> >>>>>> But certainly there are some things that can be used, like the new File >>>>>> watching API. >>>>>> >>>>>> *Bruno Borges* >>>>>> www.brunoborges.com.br >>>>>> +55 21 76727099 >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 5, 2011 at 9:04 AM, Andrea Del >>>>>> Bene<adelb...@ciseonweb.it>wrote: >>>>>> >>>>>>> I know it could sound a bit premature, but hasanyone starting to think >>>>>>> how >>>>>>> improve Wicket with the new JDK? I think that the new concurrency and >>>>>>> collections API could help to speed up Wicket. >>>>>>> >>>>>>> Has anyone run some tests? >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Martin Grigorov >>> jWeekend >>> Training, Consulting, Development >>> http://jWeekend.com >>> >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com >
