How to Ensure Backward Competibility In Java

Hi Guys, In this blog, I discussed working of code with older JDKs and how it is working internally.

Here I am trying to fetch objects with Optional and Stream APIs which are a great feature of Java 8. Let's see how we fetch first-

// Fetching 0 or 1 employee
Optional> employee =
ctx.select(EMPLOYEE.FIRST_NAME, EMPLOYEE.LAST_NAME)
   .from(EMPLOYEE)
   .where(EMPLOYEE.ID.eq(1))
   .fetchOptional();
 
// Fetching a stream of employee
try (Stream> employee = ctx
       .select(EMPLOYEE.FIRST_NAME, EMPLOYEE.LAST_NAME)
       .from(EMPLOYEE)
       .fetchStream()) {
    ...
}

But what means the JDK’s more related APIs?

It is generally simple to recollect not to utilize Streams, Optionals, lambdas, strategy references, default strategies cheerfully in your library's code. All things considered, those were all real changes to Java 8 and we can without much of a stretch include our API expulsion markers around those parts. Furthermore, regardless of whether we overlooked, fabricating the Java 6 conveyance would most likely come up short since Streams are frequently utilized with lambdas, if there should arise an occurrence of which a compiler that is designed for Java rendition 1.6 won't arrange the code.

Be that as it may, as of late, we've had a more unpretentious bug, #6860. jOOQ API was calling java.lang.reflect.Method.getParameterCount(). Since we gather jOOQ's Java 6 dissemination with Java 8, this didn't come up short. The sources were kept Java 6 dialect perfect, however not JDK 6 API good, and tragically, there's no choice in javac, nor in the Maven compiler module to do such a check.

Can we utilize Java 6 to compile the code of Java 6 circulation?

The motivation behind why we're utilizing Java 8 to manufacture jOOQ's Java 6 dissemination is the way that Java 8 "settled" a great deal (and I mean a considerable measure) of extremely old and irregular edge cases identified with generics,

Fortunately, the JDK doesn't change much between discharges, so a great deal of stuff from JDK 8 was at that point there in JDK 6. Additionally, our joining tests would fizzle, on the off chance that we did incidentally utilize a strategy like the above. Lamentably, that specific technique call basically snuck past the incorporation tests (there will never be sufficient tests for each situation).

The solution for JDKs version:

There is some code which is needed to add in our Java 6 code distribution profile.

  org.com.example
  test-sniff-maven-plugin
  1.16
  
    
      demo
      
        check
      
      
        
          org.com.example.signature
          java16
          1.1
        
      
    
  

--After that will produce this type of validation error showing below:

[INFO] --- test-sniff-maven-plugin:1.16:check (default) @ jooq-codegen ---
[INFO] Checking unresolved references to org.com.example.signature:java16:1.0
[ERROR] C:\..\JavaGenerator.java:232: Undefined reference: int java.lang.reflect.Method.getParameterCount()
[ERROR] C:\..\JavaGenerator.java:239: Undefined reference: int java.lang.reflect.Method.getParameterCount()

---Thanks---