The warning printed by the code in Lucene (and the fork of Hadoop in POI)
informs user. Btw, there's still "Hadoop" in your code. 😁
It's interesting that JDK prints the exception to stderr. This was not
happening in Java 9. Looks like a bug.
Uwe
Am August 7, 2020 9:58:04 PM UTC schrieb Andreas
> The problem was only the missing import of the unsupported module which is
> required for unmapping.
I think, I should also add the information about the permissions to a FAQ entry:
https://stackoverflow.com/a/54046774/2066598
> I still wonder where the exception came from.
Have a look at Acces
CleanerUtil dies not need to be multireleased. Just leave as is.
The problem was only the missing import of the unsupported module which is
required for unmapping. If you are in module mode at runtime (module path) and
the unsupported module is not there, the exception handler falls through to t
Thank you Uwe.
The "jdk.unsupported" module hint did the trick - at least the build is now
getting over that error.
So our build uses classpath mode when run under Java 8 and modulepath for Java
9+ - actually everything except of the module-info is compiled in classpath
mode and the module-inf
7, 2020 6:16 PM
> > To: 'POI Developers List' ; 'Andreas Beeker'
> >
> > Subject: RE: Java 9+ modules / cleaner
> >
> > To confirm: If you use POI as a JAR on classpath it will work without
> > modifications: Try it out.
> > For the module system
essage-
> From: Uwe Schindler
> Sent: Friday, August 7, 2020 6:16 PM
> To: 'POI Developers List' ; 'Andreas Beeker'
>
> Subject: RE: Java 9+ modules / cleaner
>
> To confirm: If you use POI as a JAR on classpath it will work without
> modific
er
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
https://lucene.apache.org/
> -Original Message-
> From: Uwe Schindler
> Sent: Friday, August 7, 2020 6:12 PM
> To: 'POI Developers List' ; 'Andreas Beeker'
>
> Subject: RE: Java
--
> From: Uwe Schindler
> Sent: Friday, August 7, 2020 5:20 PM
> To: 'POI Developers List' ; 'Andreas Beeker'
> ; uschind...@apache.org
> Subject: RE: Java 9+ modules / cleaner
>
> Hi,
>
> sorry I did not read all, so you already use my code:
>
> -Original Message-
> From: Uwe Schindler
> Sent: Friday, August 7, 2020 5:06 PM
> To: 'Andreas Beeker' ; uschind...@apache.org
> Cc: dev@poi.apache.org
> Subject: RE: Java 9+ modules / cleaner
>
> Hi,
>
> > I currently try to understan
Hi,
> I currently try to understand, how to call the Cleaner in Java 14 (or 9+)
> without
> adding the --add-opens JVM options.
Yeah, your code won't work correctly with Java 9 at all. You may fix it with
some opens, but still types of internal calsses changed, so its just risky
(everything is
Hi Uwe,
I currently try to understand, how to call the Cleaner in Java 14 (or 9+)
without adding the --add-opens JVM options.
As you've worked on this in LUCENE-6989, you might have a few hints for me.
I've checked the Lucene implementation, but that code is similar to POIs
current implementati
Hi Dominik,
the goal is to have no --add-opens or similar jvm arguments. In this case we
get the following exception:
[junit] java.lang.reflect.InaccessibleObjectException: Unable to make public
jdk.internal.ref.Cleaner java.nio.DirectByteBuffer.cleaner() accessible: module
java.base does n
Hi,
Sorry for replying late here, not sure if you already did these changes,
but the code in CleanerUtil tries to handle this gracefully with not
cleaning on JDKs which do not support this.
There should be no compile-time dependency on any unsafe object, during
runtime we try to get a cleaner and
13 matches
Mail list logo
