jOOQ is a very backwards compatible product. This doesn't only mean that we keep our own API backwards compatible as well as possible, but we also still support Java 6 in our commercial distributions. In a previous blog post, I've shown how we manage to support Java 6 while at the same time not missing … Continue reading How to Ensure Your Code Works With Older JDKs
Tag: backwards compatibility
What the sun.misc.Unsafe Misery Teaches Us
Oracle will remove the internal sun.misc.Unsafe class in Java 9. While most people are probably rather indifferent regarding this change, some other people - mostly library developers - are not. There had been a couple of recent articles in the blogosphere painting a dark picture of what this change will imply: Dripstat's Removal of sun.misc.Unsafe … Continue reading What the sun.misc.Unsafe Misery Teaches Us
Don’t be Fooled by Generics and Backwards-Compatibility. Use Generic Generic Types
I've recently had a very interesting discussion with Sebastian Gruber from Ergon, a very early jOOQ customer, whom we're in close touch with. Talking to Sebastian has lead our engineering team to the conclusion that we should completely rewrite the jOOQ API. Right now, we already have lots of generics for various purposes, e.g. Generics … Continue reading Don’t be Fooled by Generics and Backwards-Compatibility. Use Generic Generic Types
The Java Legacy is Constantly Growing
I've recently stumbled upon a very interesting caveat of the JDK APIs, the Class.getConstructors() method. Its method signature is this: Constructor<?>[] getConstructors() The interesting thing here is that Class.getConstructor(Class...) returns a Constructor<T>, with <T> being maintained: Constructor<T> getConstructor(Class<?>... parameterTypes) Why is there a difference, i.e. why doesn't the first method return Constructor<T>[]? Let's consider the … Continue reading The Java Legacy is Constantly Growing
How Nashorn Impacts API Evolution on a New Level
Following our previous article about how to use jOOQ with Java 8 and Nashorn, one of our users discovered a flaw in using the jOOQ API as discussed here on the user group. In essence, the flaw can be summarised like so: Java code package org.jooq.nashorn.test; public class API { public static void test(String string) … Continue reading How Nashorn Impacts API Evolution on a New Level
Java 8 Friday: Language Design is Subtle
At Data Geekery, we love Java. And as we're really into jOOQ's fluent API and query DSL, we're absolutely thrilled about what Java 8 will bring to our ecosystem. Java 8 Friday Every Friday, we're showing you a couple of nice new tutorial-style Java 8 features, which take advantage of lambda expressions, extension methods, and … Continue reading Java 8 Friday: Language Design is Subtle
Java Rocks More Than Ever
On the TIOBE index, Java and C have been sharing the #1 and #2 rank for a long time now, and with the recent GA release of the JDK 8, things are not going to get any worse for our community. Java simply rocks! And it's the best platform to build almost any of your … Continue reading Java Rocks More Than Ever
The Lame Side of Java’s Backwards-Compatibility
Java is a very backwards-compatible language. Very as in very very very. It is so backwards compatible, we still have tons of deprecated code that was deprecated in the JDK 1.1. For example, most of the java.util.Date and java.util.Calendar API. Some may argue that it would've been easier to deprecate the classes altogether... But things … Continue reading The Lame Side of Java’s Backwards-Compatibility
Defensive API evolution with Java interfaces
API evolution is something absolutely non-trivial. Something that only few have to deal with. Most of us work on internal, proprietary APIs every day. Modern IDEs ship with awesome tooling to factor out, rename, pull up, push down, indirect, delegate, infer, generalise our code artefacts. These tools make refactoring our internal APIs a piece of … Continue reading Defensive API evolution with Java interfaces