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?
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
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
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
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
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
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)
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
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
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
:-)
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
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
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?
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
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?)
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
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
17 matches
Mail list logo
