New informational JEP: 14: The Tip & Tail Model of Library Development

[Alan Snyder]

I don’t agree with your characterization of the situation.

You are probably in a better position than I am to know why people still use JDK 8, but my assumption is many or most of them stick with JDK 8 because they use code that has never been ported to JDK 9 or later and it would be risky and/or expensive to port it.

That does not imply that they don’t want bug fixes and new features from libraries that are being actively maintained, in which case forking the library and only backporting critical/security problems would not be well received.

My libraries run on JDK 8 and all later JDKs. I use reflection to cover the API differences between JDK 8 and JDK 9+. Fortunately, or perhaps not surprisingly, I have not yet run into a situation where I need to change my code to run on later JDKs (except for that command line argument that will be needed for my libraries to use JNI, and you already know what I think about that.)

If at some point using features of more recent JDKs internally would make a big performance difference, I still have the option to extend my reflection solution. If the changes impact the API then I would have a big decision to make.

  Alan


> On Oct 22, 2024, at 1:44 PM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> 
> 
>> On 19 Oct 2024, at 02:59, Alan Snyder <javalists at cbfiddle.com> wrote:
>> 
>> I appreciate the emphasis in this JEP on minimizing the burden of backporting changes.
>> 
>> However, for me, maintaining multiple releases is also burdensome. For that reason, I target library development to JDK 8 and probably will continue to do so as long as JDK 8 is relevant. I understand that there are disadvantages to not being able to use newer language features, but so far, the disadvantages of maintaining multiple releases outweigh the advantages of the new language features.
> 
> “Maintaining multiple releases” in T&T effectively means backporting security patches and fixes to the most critical bugs, and unless your library keeps having many of those discovered in *old code*, there isn’t much maintaining to do. 
> 
> But say that you do have lots of security problems or lots of criticial bugs and it is a burden to backport solutions to so many problems. There are still two things to consider:
> 
> 1. T&T delivers to your users more of what they want. If your library has lots of major bugs, it stands to reason that new features would only add more. “Legacy" users don’t want these new bugs (and potentially other regressions/breaking changes that come with new features).
> 
> 2. Even if new language features in your API aren’t a win for your users, maintaining a single release train can mean more work (given that the tail releases don’t require much maintenance). For example, if a library uses Unsafe on 8, it will simply stop working soon on newer JDK. Picking dynamically between Unsafe and VarHandles/FFM is more work than letting the Unsafe version be, only backporting security patches. The same happens if you want to offer better performance on new JDKs by using new features internally.
> 
> Anyone is, of course, free to use OSFA, but claiming that it’s less work and/or delivers more value is something I would very much doubt unless the library is swarming with yet-to-be-discovered major bugs or security vulnerabilities.
> 
>> 
>> I have a suggestion that might be helpful to me and others in the same boat. Are there language features that do not impact the byte code and do not require runtime support? If so, would it be possible to support those features (using a compiler flag) when targeting older releases like JDK 8?
> 
> It is probably true that if we also picked the path that requires more effort and more likely to destabalise those who want stability it could mean that those who choose to do things the hard way may need to work a little less hard, but why do that if in most situations (maybe not all) the easy way is available? How big is that boat of maintainers of libraries with so many critical problems that backporting them becomes such a big burden that it offsets both the extra effort of dynamic feature detection and the risk of destabalising legacy users?
> 
> — Ron