On Sat, May 16, 2015 at 12:58 PM, Alan Bateman <alan.bate...@oracle.com> wrote: >> > JDK 9 is not planned to ship until 2016 so if there is a new API then I > would hope this is time enough for Lucene to add support. For now then I > think we need to come up with the right API for this. We can see later if we > want to get the undocumented behavior to also work in JDK 9. >
Well we can't really easily and cleanly add support for the new API, until we "require" it. Honestly that is going to happen after JDK 9 is released! This gives us two possible solutions (that we'd have to live with for a few years): * two pages of sync code, with reflection etc to handle the new java 9 method if its present. * two pages of sync code, split across different jars with multi-version jar support or something like that (not sure if it works here, its not really relevant). Code that is responsible for synchronizing data to disk is really important, its the last place you want this kind of complexity :( And until such a new API is finalized, we can't even add code to look for it reflectively. I'm just trying to explain our situation, and as a project, I think lucene is pretty aggressive about making new versions require new JDK versions (I see plenty of open source code sticking with 1.5/6/etc as a minimum requirement still). Again, I don't think we are the only people impacted. A great example of how people interpret the apis is here: http://stackoverflow.com/questions/7694307/using-filechannel-to-fsync-a-directory-with-nio-2 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
