Java itself has moved to a faster//release cycle so I also think we
might speed up a little bit //
//
On 10/04/2018 16:00, Maxim Solodovnik wrote:
Browser versions topic seems to be popular so here are some stats
Wicket 8.0.0M1 was release Jul 2016 [1]
Since then Google Chrome has changed 15 major releases [2]
This seems to be common practice right now ...
Maybe it worth to release more often?
[1] http://mvnrepository.com/artifact/org.apache.wicket/wicket-core
[2] https://en.wikipedia.org/wiki/Google_Chrome_version_history
On Tue, Apr 10, 2018 at 7:48 PM, Andrea Del Bene <an.delb...@gmail.com> wrote:
The issue with CGLIB looks serious, but I don't think we should postpone
Wicket 8 because of it. Wicket 8 has already a lot of API changes and new
features and moving away from CGLIB would further complicate the migration
path. In addition, I guess it won't be a simple task to get rid of CGLIB,
so I don't see any reason to not release Wicket 8 while we work on this
delicate issue.
My 2 cents.
On Tue, Apr 10, 2018 at 2:22 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
On Tue, Apr 10, 2018 at 2:09 PM, Maxim Solodovnik <solomax...@gmail.com>
wrote:
Current version is Java 10 (non LTS)
Maybe we can release 8.0.0 and add this to Wicket 9 ?
The issue is that you can't upgrade to Java 11 when you are running
CGLIB due to its use of sun.misc.Unsafe.
This will cause problems. I'd rather ensure we have a good path
forward, and Java 11 is in september. We can't break API in 8.x so we
are stuck with CGLIB apis we expose.
Unfortunately CGLIB usage is not private/internal to wicket itself but
is exposed in a couple public APIs.
Of course, if we had relesed Wicket 8 with CGLIB in it, this problem
would still exist, and perhaps Wicket 8 would be a short lived
maintained version if we were forced to remove our dependency on CGLIB
(which is unclear at the moment)
Martijn