papegaaij opened a new pull request #432:
URL: https://github.com/apache/wicket/pull/432
This PR suggest a minor change to the contract of
IRequestComponent.getBehaviorId to prepare for a refactoring of the component
internals.
solomax commented on pull request #431:
URL: https://github.com/apache/wicket/pull/431#issuecomment-624932135
@bitstorm this should be added to "Migration guide", I guess, but I was
unable to find it :((
this https://cwiki.apache.org/confluence/display/WICKET#Index-Migrations
seems to
solomax opened a new pull request #429:
URL: https://github.com/apache/wicket/pull/429
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go
Hello All,
ConcurrentHashSet can be safely removed from wicket codebase due to
since Java8 it is possible to use ConcurrentHashMap.newKeySet()
Can we @deprecate in in wicket9 and remove in Wicket10?
--
Best regards,
Maxim
On Wed, May 6, 2020 at 1:20 PM Maxim Solodovnik
wrote:
> Hello All,
>
> ConcurrentHashSet can be safely removed from wicket codebase due to
> since Java8 it is possible to use ConcurrentHashMap.newKeySet()
>
> Can we @deprecate in in wicket9 and remove in Wicket10?
>
+1
>
> --
> Best regards,
I'd go further and deprecate it in wicket 8 as well... Since the
replacement is in Java 8.
I would be +1 on removing it from Wicket 9 final if it came to a vote. It
is not a core class in Wicket, it was not supposed to be used widely
(mostly for our internal stuff), and would make it clear that
+1 to replace it with ConcurrentHashMap.newKeySet()
On 06/05/20 12:53, Martijn Dashorst wrote:
I'd go further and deprecate it in wicket 8 as well... Since the
replacement is in Java 8.
I would be +1 on removing it from Wicket 9 final if it came to a vote. It
is not a core class in Wicket, it
I would propose to remove it in Wicket9, but don't want to slow down the
release :)
Will create PR :)
On Wed, 6 May 2020 at 17:56, Andrea Del Bene wrote:
> +1 to replace it with ConcurrentHashMap.newKeySet()
>
> On 06/05/20 12:53, Martijn Dashorst wrote:
> > I'd go further and deprecate it in
solomax opened a new pull request #431:
URL: https://github.com/apache/wicket/pull/431
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go
Hi all,
During my refactoring of the component state (WICKET-6774) I noticed
that behavior ids are currently stored in a very inefficient way: an
ArrayList is added to Component data to store references to behaviors
with a stable id. On my branch I have eliminated this ArrayList,
greatly reducing
bitstorm commented on pull request #431:
URL: https://github.com/apache/wicket/pull/431#issuecomment-624670513
Looks good to me!
This is an automated message from the Apache Git Service.
To respond to the message, please log
solomax opened a new pull request #430:
URL: https://github.com/apache/wicket/pull/430
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go
MicroMap can easily be replaced with Map.of(key, value)
I can deprecate it for wicket9 in same PR, should I?
On Wed, 6 May 2020 at 18:06, Maxim Solodovnik wrote:
> I would propose to remove it in Wicket9, but don't want to slow down the
> release :)
> Will create PR :)
>
> On Wed, 6 May 2020
On 06/05/20 16:52, Emond Papegaaij wrote:
Hi all,
During my refactoring of the component state (WICKET-6774) I noticed
that behavior ids are currently stored in a very inefficient way: an
ArrayList is added to Component data to store references to behaviors
with a stable id. On my branch I
Hi Andrea,
Stateful is fine, stateless is not. A component cannot keep a stable
id when it's stateless. I'm trying out a change that forbids
getBehaviorId() for stateless behaviors, and I'm hitting a few tests
with stateless ajax. I don't see how this is supposed to work anyway.
We request the
Hi,
While running, I came up with a solution for which only a minor change
to the contract of the method is needed: ids for stateless behaviors
will be stable within a single requests, but can change over requests.
I think this is reasonable, given the way stateless components work.
I would like
16 matches
Mail list logo
