[
https://issues.apache.org/jira/browse/LUCENE-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15748715#comment-15748715
]
Sanne Grinovero commented on LUCENE-6989:
-----------------------------------------
Thanks Uwe for accurately keeping track of all this!
I'm following it all on the OpenJDK mailing list but it's great to keep track
of all details here.
As you know I'm interested in both Hibernate and Lucene - as I integrate them
into Hibernate Search and bundle them into WildFly. WildFly has had strong
modularity since years so we have some experience packaging Lucene for it, and
for OSGi as well.
Jason Greene, the WildFly platform architect just blogged about our open
issues; you might find it interesting too:
http://wildfly.org/news/2016/12/12/Jigsaws-Missing-Pieces/
Definitely looking forward to integrate a compatible Lucene version, at minimal
disruptions for end users, which in our case implies to hopefully be able to
backport any needed patch as far as Lucene version 5.3. We expose Lucene APIs
directly, so upgrading would break app compatibility which is yet another form
of user inconvenience; I guess it might need to come to that, we'll see when
Jigsaw plans will become clearer.
> Implement MMapDirectory unmapping for coming Java 9 changes
> -----------------------------------------------------------
>
> Key: LUCENE-6989
> URL: https://issues.apache.org/jira/browse/LUCENE-6989
> Project: Lucene - Core
> Issue Type: Task
> Components: core/store
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Labels: Java9
> Fix For: 6.0
>
> Attachments: LUCENE-6989-disable5x.patch,
> LUCENE-6989-disable5x.patch, LUCENE-6989-fixbuild148.patch,
> LUCENE-6989-v2.patch, LUCENE-6989.patch, LUCENE-6989.patch,
> LUCENE-6989.patch, LUCENE-6989.patch
>
>
> Originally, the sun.misc.Cleaner interface was declared as "critical API" in
> [JEP 260|http://openjdk.java.net/jeps/260 ]
> Unfortunately the decission was changed in favor of a oficially supported
> {{java.lang.ref.Cleaner}} API. A side effect of this change is to move all
> existing {{sun.misc.Cleaner}} APIs into a non-exported package. This causes
> our forceful unmapping to no longer work, because we can get the cleaner
> instance via reflection, but trying to invoke it will throw one of the new
> Jigsaw RuntimeException because it is completely inaccessible. This will make
> our forceful unmapping fail. There are also no changes in Garbage collector,
> the problem still exists.
> For more information see this [mailing list
> thread|http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/thread.html#38243].
> This commit will likely be done, making our unmapping efforts no longer
> working. Alan Bateman is aware of this issue and will open a new issue at
> OpenJDK to allow forceful unmapping without using the now private
> sun.misc.Cleaner. The idea is to let the internal class sun.misc.Cleaner
> implement the Runable interface, so we can simply cast to runable and call
> the run() method to unmap. The code would then work. This will lead to minor
> changes in our unmapper in MMapDirectory: An instanceof check and casting if
> possible.
> I opened this issue to keep track and implement the changes as soon as
> possible, so people will have working unmapping when java 9 comes out.
> Current Lucene versions will no longer work with Java 9.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
