Any existing reusable & thread-safe JavaFileManager implementation for PlatformDescriptor?
Mickael Istria
mistria at redhat.com
Thu Dec 19 09:51:04 UTC 2024
Hi all,
In our work using Javac inside Eclipse IDE in place of ECJ, I'm facing a
difficulty for which I have found ugly workarounds (described later) and
for which I wonder whether there are already good solutions in place I
could reuse instead.
The problem is that in the IDE, we do want the dependencies (jars, system
libraries) to be persisted in memory and reused across resolutions,
possibly by various threads and so on.
Sharing some file managers is not too hard, but making their underlying
jars or ct.sym reliably readable across usage is trickier.
The main issue we face is that all the ZipPath are interruptible by
default, which means that whenever a thread aborts (and that's relatively
frequent in the IDE), the underlying FileChannel in the ZipPath are closed,
making the zip path and then the JavaFileObjects unusable... crashing all
its further consumers.
The workaround we have in place is to use reflection to access the
FileChannel in the ZipPath and mark it as non-interruptible, but that code
is a bad smell and even the way we've used it remains fragile in term of
sequencing (there is still room for an interruption).
So I'm wondering whether someone has a better solution about such a
"JavaFileManagerSharingLibraries" (maybe some good implementation already
exists), or if someone has had similar concerns with interrupted
JavaFileObject and could recommend a better strategy than our workaround
based on reflection?
Thanks in advance
Mickael
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
<https://developers.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241219/5398f93e/attachment.htm>
More information about the compiler-dev
mailing list