Notes form the breakout meeting, and a few email conversations (around things like release schedule).
GeoServer ASM Java 8 Incompatibility
Action:
-
Jody turn this into a technical debt document
-
All: communicate early and often (seeking a prompt decision/discussion while we are in position to act)
problem
ASM incompatible with Java 8 Byte Code
Q: Like what?
Internet research indicates ASM used to recreate dynamic proxies, so this should only happen if classes uses Java 8 byte code. Andrea researches shows the surefire way to cause this try to proxy a bean that uses Java 8 default method.
Q: Where is this happening? A: Kevin working on a GWC feature branch that causes this issue
The feature branch introduces this problem by writing a method using java 8 syntax, no change to GeoServer interfaces, no introduction of default methods etc…
Kevin has found the problem here (https://github.com/smithkm/geowebcache/commits/wmscap-refresh) in a feature branch of GWC. It actually looks like ASM will die when creating a proxy for any bean that uses Java 8 byte code. Unit tests for GWC do not use spring, so this was only found late in the game during manual testing.
a) Options use Java 8 very very carefully - run with Java 8 and test a lot?
Andrea strongly advocated for this solution, it would be a risk but possibly an acceptable risk.
The approach would be to avoid the use of any Java 8 features … in any bean that will be instaciated by spring.
that is not created by spring (implementation or interface).
Pros:
- This would keep our current release schedule, opening master up to spring 4 migration in march for a GeoServer 2.10 timeframe.
- No change to bi-annual release schedule
- Users could run with “some” confidence (safety in numbers) on Java 8, would really reply on build box and user list testing
Cons:
- Developers would be unwise to use Java 8 features (since they are risky and may accidentally break things)
- Risk from GeoTools 15 beans or those working on custom extensions built with Java 8
- We would still need to migrate to Spring 4 pretty much now, but would have “more time” to get it right
- Less “pressure” means less chance to get this issue funded and resolved
b) Option Fallback to target=1.7 - don’t use Java 8 byte code anywhere
Is set compile target=1.7 byte code.
How much work? this would be a 2-3 days. Is this worth it?
update: checking now by changing jre and target=1.7 in eclipse shows:
- 35 errors (mostly lambda and function use)
Pros:
- This would keep our current release schedule, opening master up to spring 4 migration in march for a GeoServer 2.10 timeframe.
- No change to bi-annual release schedule
- Users could run with confidence on Java 8? Meeting security policies without licensing Java 7 from oracle.
Cons:
- Developers would be unable to use Java 8 features (at least casual use would be caught)
- Risk from GeoTools 15 beans or those working on custom extensions built with Java 8
- We would still need to migrate to Spring 4 pretty much now, but would have “more time” to get it right
- Less “pressure” means less chance to get this issue funded and resolved
c) Option Delay Release / Update now - to update to Spring 4.03 or greater
Migrate to Spring 4 now, delaying the GeoServer 2.9 release.
This requires us to Extend GeoServer 2.8 time line:
- We will need to backport some work need to backport (UTF-GRID for geosolutions customer commitments, wps remote, etc…)
Checking with key stakeholders:
- Boundless - in favour of this, willing to commit resources to see this happen
- GeoSolutions - require a release delay of three months, in favour but will need to scramble to meet customer contracts (example backporting work).
Justin has done some checks in October:
- servlet api upgrade (at least 3.0)
- mock runner library does not go that high (spring has its own mock runner)
- mechanical change, but not dropin replacing- security
- cas, ldap, security modules in general:
- Andrea emphasis manual testing
- Especially manual testing for CAS (it is a rewrite, not just an update)
Want to hear back from christian
- CAS is a risk identified above
Andrea has some experience running GeoServer 2.9 in production:
- Building on Java 8 for 2 months, a couple 2.9 systems in preproduction testing
Jody feels this is a bit of a time bomb - but can now understand the geosolutions 3 month delay expectation.
What would a timeframe look like?
- Two or three weeks to get something working at all
- Migrate/Test problem areas (such as security cas)
- Go through careful release and test plan
- Q: could we make a test plan over the next couple of days?
What will be affected?
- Note jdbconfig / jdbcconfig disk quota are hit by this upgrade
- How much will geofence rest be affected? due to use of spring rest api
Pros:
- We would update spring now … and avoid what happened to wicket
- Developers able to use Java 8 features
- less project risk
- Users could run with confidence on Java 8 (Meeting security policies without licensing Java 7 from oracle).
Cons:
- Delay to release schedule (2-3 months), would need to restore schedule or use 9 month schedule
- can we do this quickly and safely?