4 ms·

"We haven’t even finished migrating all our components to compile with JDK8 yet" Interested to hear which Java API you use which requires special modification

"We haven’t even finished migrating all our components to compile with JDK8 yet" Interested to hear which Java API you use which requires special modification in order to be compilable on Java 8? Usually most of this breakage is caused by the com.sun stuff which isnt public API.

mrighele 9y ago
If you have written your regular enterprise web service you will probably not have very complex code (I'm not talking about business logic, but language features). But then you are using a 1 year old framework (if you're lucky) that depends on a version of library X that is 2 years old that depends on a 3 years old library etc. At the end of the chain you have a library that does low level stuff (bytecode instrumentation for example) and is a few years old. That is what may give you problems, and often the only practical solution is to update to a newer version of the framework, which can be quite expensive.
cesarb 9y ago
For instance, if you depend on an old version of the Spring framework, using some Java 8 features (like lambdas) will break, since it generates bytecode Spring doesn't understand. Compiling as Java 7 prevents inadvertent use of these features.
delecti 9y ago
I'm curious, how large of a company did you work for such that you were able to easily upgrade your JDK version? Because I worked at a fairly large tech company and every one of our applications required some amount of manual intervention beyond figuratively switching all the "7"s to "8"s. That's despite the fact that hardly any of them were doing anything particularly complicated, and absolutely none of them were doing anything involving hidden com.sun APIs. I think it's just a consequence of such a large build system.
- shell_oil_101 9y ago
  Yeah the reality of the situation is that it's never as straight-forward as just recompiling with the latest JDK. From my experience it wasn't generally code written in-house that'd cause problems (but sometimes it was), it was dependencies and transitive deps that required the older JDK (sometimes they relied on old bugs or old tooling, sometimes they just couldn't be recompiled on the new JDK for whatever reason). Build tools that relied heavily on JVM internals often couldn't upgrade for some time. Third parties integrating with your software and the new JDK brings a slight change in it's SOAP/XML/ser-deser stuff etc. That said, Java has been the best at backwards compatibility that I've tried, given it's popularity, and most of the pain was in the early days (like anything I suppose, see the Javascript world atm). Microsoft's offerings probably do backwards compatibility well, but then you get all the rest of the technical- and wallet-pain that that environment brings with it.
BonesJustice 9y ago
Java 8 made some changes to type inference that can, in certain edge cases, cause generic method calls to bind differently. While it’s _mostly_ backwards compatible, it’s not entirely.

mrighele 9y ago

If you have written your regular enterprise web service you will probably not have very complex code (I'm not talking about business logic, but language features). But then you are using a 1 year old framework (if you're lucky) that depends on a version of library X that is 2 years old that depends on a 3 years old library etc. At the end of the chain you have a library that does low level stuff (bytecode instrumentation for example) and is a few years old. That is what may give you problems, and often the only practical solution is to update to a newer version of the framework, which can be quite expensive.

cesarb 9y ago

For instance, if you depend on an old version of the Spring framework, using some Java 8 features (like lambdas) will break, since it generates bytecode Spring doesn't understand. Compiling as Java 7 prevents inadvertent use of these features.

delecti 9y ago

I'm curious, how large of a company did you work for such that you were able to easily upgrade your JDK version? Because I worked at a fairly large tech company and every one of our applications required some amount of manual intervention beyond figuratively switching all the "7"s to "8"s. That's despite the fact that hardly any of them were doing anything particularly complicated, and absolutely none of them were doing anything involving hidden com.sun APIs. I think it's just a consequence of such a large build system.

shell_oil_101 9y ago
Yeah the reality of the situation is that it's never as straight-forward as just recompiling with the latest JDK. From my experience it wasn't generally code written in-house that'd cause problems (but sometimes it was), it was dependencies and transitive deps that required the older JDK (sometimes they relied on old bugs or old tooling, sometimes they just couldn't be recompiled on the new JDK for whatever reason). Build tools that relied heavily on JVM internals often couldn't upgrade for some time. Third parties integrating with your software and the new JDK brings a slight change in it's SOAP/XML/ser-deser stuff etc. That said, Java has been the best at backwards compatibility that I've tried, given it's popularity, and most of the pain was in the early days (like anything I suppose, see the Javascript world atm). Microsoft's offerings probably do backwards compatibility well, but then you get all the rest of the technical- and wallet-pain that that environment brings with it.

BonesJustice 9y ago

Java 8 made some changes to type inference that can, in certain edge cases, cause generic method calls to bind differently. While it’s _mostly_ backwards compatible, it’s not entirely.