4 ms·
The biggest issue I've met with the ABI issue is frameworks (Spring etc.) that emit bytecode at runtime. I tried upgrading our project to Java 10 and Spring 4
by EdwardDiego 8y ago
The biggest issue I've met with the ABI issue is frameworks (Spring etc.) that emit bytecode at runtime.
I tried upgrading our project to Java 10 and Spring 4 and Camel (I can't remember the version) were the main issues because of their runtime generated proxies. The fix is to upgrade Spring to Spring 5, but that's a whole bunch of other work, and I'm unsure of the scope of work to upgrade Camel.
All that said, Java ABI is far more forgiving than Scala ABI. Every Scala artifact is appended with an "underscore Scala version" and SBT uses the '%%' operator to handle this implicitly, and it causes me no end of grief.
Last time I looked at upgrading our Spark code to use JRE 10, Scala broke because JRE 10 support only came in at Scala 2.12 (but was backported to Scala 2.11 recently) and Spark only supports Scala 2.10 and 2.11 at the moment, apparently the work to support 2.12 is still ongoing.
- MBCook 8y agoI remember running into an issue sort of like that with Struts (IIRC). I could use Java 8 anywhere in the codebase except on JSP files because Struts would choke on the new bytecodes it didn’t know were now valid.
- jerven 8y agoActually it works if you use a recent eclipse ejc for compiling the JSPs. i.e. tomcat 8+ will be ok with such feature use like default methods.