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?




Reply via email to