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
