Wicket and Java 7
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?
Re: Wicketstuff Jenkins Status?
I added an assertNotNull to the CDNTest to see what's happening. Weird enough, it works just fine in my laptop. Builds OK https://github.com/wicketstuff/core/commit/82fa876572e49f99267a0a899ca24508990ffc49 Could you rebuild through Jenkins? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Mon, Jul 4, 2011 at 6:45 PM, Martin Grigorov mgrigo...@apache.orgwrote: Thanks! I added Ant but Dojo-Resources project still fails for unknown reason. JSLibraries fails as well with broken test: http://wicketstuff.org/hudson/job/Wicket%20Stuff%20Core%20Java5%20(wicket%201.4-SNAPSHOT)/87/org.wicketstuff$jslibraries/ I removed two of my accounts. On Mon, Jul 4, 2011 at 9:26 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Mon, Jul 4, 2011 at 8:38 PM, Martin Grigorov mgrigo...@apache.org wrote: I have few accounts in Jenkins but none of them is admin. Can someone with Admin rights to give me the karma for user martin-g ? done Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Wicketstuff Jenkins Status?
Sorry, not to see what's happening. But to make sure it's not null and let the test fail correctly, if it fails. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Tue, Jul 5, 2011 at 9:09 AM, Bruno Borges bruno.bor...@gmail.com wrote: I added an assertNotNull to the CDNTest to see what's happening. Weird enough, it works just fine in my laptop. Builds OK https://github.com/wicketstuff/core/commit/82fa876572e49f99267a0a899ca24508990ffc49 Could you rebuild through Jenkins? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Mon, Jul 4, 2011 at 6:45 PM, Martin Grigorov mgrigo...@apache.orgwrote: Thanks! I added Ant but Dojo-Resources project still fails for unknown reason. JSLibraries fails as well with broken test: http://wicketstuff.org/hudson/job/Wicket%20Stuff%20Core%20Java5%20(wicket%201.4-SNAPSHOT)/87/org.wicketstuff$jslibraries/ I removed two of my accounts. On Mon, Jul 4, 2011 at 9:26 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Mon, Jul 4, 2011 at 8:38 PM, Martin Grigorov mgrigo...@apache.org wrote: I have few accounts in Jenkins but none of them is admin. Can someone with Admin rights to give me the karma for user martin-g ? done Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Wicket and Java 7
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.itwrote: 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?
Re: Wicket and Java 7
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.itwrote: 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
Re: Wicketstuff Jenkins Status?
I didn't notice it was building 1.4.x. Anyway, I ran the build again and it worked. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Tue, Jul 5, 2011 at 9:10 AM, Bruno Borges bruno.bor...@gmail.com wrote: Sorry, not to see what's happening. But to make sure it's not null and let the test fail correctly, if it fails. *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Tue, Jul 5, 2011 at 9:09 AM, Bruno Borges bruno.bor...@gmail.comwrote: I added an assertNotNull to the CDNTest to see what's happening. Weird enough, it works just fine in my laptop. Builds OK https://github.com/wicketstuff/core/commit/82fa876572e49f99267a0a899ca24508990ffc49 Could you rebuild through Jenkins? *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Mon, Jul 4, 2011 at 6:45 PM, Martin Grigorov mgrigo...@apache.orgwrote: Thanks! I added Ant but Dojo-Resources project still fails for unknown reason. JSLibraries fails as well with broken test: http://wicketstuff.org/hudson/job/Wicket%20Stuff%20Core%20Java5%20(wicket%201.4-SNAPSHOT)/87/org.wicketstuff$jslibraries/ I removed two of my accounts. On Mon, Jul 4, 2011 at 9:26 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Mon, Jul 4, 2011 at 8:38 PM, Martin Grigorov mgrigo...@apache.org wrote: I have few accounts in Jenkins but none of them is admin. Can someone with Admin rights to give me the karma for user martin-g ? done Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Wicket and Java 7
I know, I was just mentioning what could be used of JDK 7 in advantage for Wicket in a far far future. :-) *Bruno Borges* www.brunoborges.com.br +55 21 76727099 On Tue, Jul 5, 2011 at 9:26 AM, Martin Grigorov mgrigo...@apache.orgwrote: 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
Re: Wicket and Java 7
For Wicket 1.6 we can move to JDK6 but this will be discussed later. Usage of JDK7 for frameworks is not very close. this is an understatement :) wicket and java 7... my guess? more then 4 years... But who knows if Oracle speeds it up (they say Java 8 next year..) also the upgrades are a little bit faster by the users them selfs? For example when will java 6 be out of support by Oracle? (what java 5 currently already is..)
Re: Wicket and Java 7
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 Borgesbruno.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 Beneadelb...@ciseonweb.itwrote: 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
Re: Wicket and Java 7
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 Borgesbruno.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 Beneadelb...@ciseonweb.itwrote: 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
Re: Wicket and Java 7
:-) 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 Borgesbruno.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 Beneadelb...@ciseonweb.itwrote: 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
Re: Wicket and Java 7
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 Borgesbruno.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 Beneadelb...@ciseonweb.itwrote: 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
Re: Wicket and Java 7
My fault Martin, I have not explained well myself. I try to summarize what I wanted to say: -Java 7 introduces some tools to implement Fork/Join parallelism ( http://en.wikipedia.org/wiki/Fork-join_queue ) -Should we adopt this pattern? Is Wicket ready for implementing such a pattern? Render phase is probably the most time-expensive part of Wicket. Do you think it could be splitted in subtasks? For example it would be nice if a page could apply Fork/Join parallelism to render its children components. 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 Beneadelb...@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 Borgesbruno.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 Beneadelb...@ciseonweb.itwrote: 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?
Re: Wicket and Java 7
hrm, dont think that is going to happen - at least not as far as page rendering goes. i dont think anyone has cracked how to take code and automatically figure out how to run it in parallel :) -igor On Tue, Jul 5, 2011 at 8:52 AM, Andrea Del Bene adelb...@ciseonweb.it wrote: My fault Martin, I have not explained well myself. I try to summarize what I wanted to say: -Java 7 introduces some tools to implement Fork/Join parallelism ( http://en.wikipedia.org/wiki/Fork-join_queue ) -Should we adopt this pattern? Is Wicket ready for implementing such a pattern? Render phase is probably the most time-expensive part of Wicket. Do you think it could be splitted in subtasks? For example it would be nice if a page could apply Fork/Join parallelism to render its children components. 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 Beneadelb...@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 Borgesbruno.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 Beneadelb...@ciseonweb.itwrote: 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?
Re: Wicket and Java 7
Parallelizing code is great when your single machine is never under very heavy load (all worker threads used). Under very heavy load, the parallelization management code simply adds additional overhead (my experience). To shed, throttle, rollback, checkpointfreeze or migrate (transactional?) tasks as heavy load conditions are approached on a machine is a system-level, multi-machine, architectural issue that is not easily inserted into an existing code base. Richard On 07/05/2011 08:52 AM, Andrea Del Bene wrote: My fault Martin, I have not explained well myself. I try to summarize what I wanted to say: -Java 7 introduces some tools to implement Fork/Join parallelism ( http://en.wikipedia.org/wiki/Fork-join_queue ) -Should we adopt this pattern? Is Wicket ready for implementing such a pattern? Render phase is probably the most time-expensive part of Wicket. Do you think it could be splitted in subtasks? For example it would be nice if a page could apply Fork/Join parallelism to render its children components. 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 Beneadelb...@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 Borgesbruno.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 Beneadelb...@ciseonweb.itwrote: 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? -- Quis custodiet ipsos custodes
Re: Wicket and Java 7
Hi Andrea, I understood you. But it seems you didn't understand me :-) Component rendering is currently not pluggable, i.e. you cannot set a different strategy and any of the IXyzSettings and use different code to do the rendering. Unless this is refactored to be pluggable there is no sense to think in this direction. JDK6 users will not be able to use Wicket if Wicket is build with JDK7. On Tue, Jul 5, 2011 at 5:52 PM, Andrea Del Bene adelb...@ciseonweb.it wrote: My fault Martin, I have not explained well myself. I try to summarize what I wanted to say: -Java 7 introduces some tools to implement Fork/Join parallelism ( http://en.wikipedia.org/wiki/Fork-join_queue ) -Should we adopt this pattern? Is Wicket ready for implementing such a pattern? Render phase is probably the most time-expensive part of Wicket. Do you think it could be splitted in subtasks? For example it would be nice if a page could apply Fork/Join parallelism to render its children components. 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 Beneadelb...@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 Borgesbruno.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 Beneadelb...@ciseonweb.itwrote: 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
Re: Wicket and Java 7
All this parallelism thing is overrated, and in web apps in particular, it's pretty irrelevant. Web apps already use parallelism: requests are handled in parallel. This is the kind of thing that server vendors must worry about, so that we don't. The more CPUs/cores you have, the more simultaneous users you'll be able to handle. And, if you don't have that many users, you won't need this kind of optimization either. Some very specific applications need parallel processing, but they will need parallelism in the backend (parallel search, raytracing, scientific calculations/simulations), not while generating HTML. Besides, this kind of fork/join processing has its own overhead, both in CPU cycles and in code complexity. Not worth it. Tetsuo On Tue, Jul 5, 2011 at 12:52 PM, Andrea Del Bene adelb...@ciseonweb.it wrote: My fault Martin, I have not explained well myself. I try to summarize what I wanted to say: -Java 7 introduces some tools to implement Fork/Join parallelism ( http://en.wikipedia.org/wiki/Fork-join_queue ) -Should we adopt this pattern? Is Wicket ready for implementing such a pattern? Render phase is probably the most time-expensive part of Wicket. Do you think it could be splitted in subtasks? For example it would be nice if a page could apply Fork/Join parallelism to render its children components. 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 Beneadelb...@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 Borgesbruno.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 Beneadelb...@ciseonweb.itwrote: 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?
