[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16547191#comment-16547191
]
Uwe Schindler commented on LUCENE-2562:
---------------------------------------
Hi,
the forbiddenapis problems are caused by the way how javafx was exposed in
previous versions of the JDK. With JDK8 it was shipped inside rt.jar, but on
other versions it is not included at all and in Java 10 it's now part of module
system.
The portable runtime stuff only allows classes from the well known java
packages, which does not yet include {{javafx.**}}:
https://github.com/policeman-tools/forbidden-apis/blob/master/src/main/java/de/thetaphi/forbiddenapis/AsmUtils.java#L39-L40
The problem JavaFX is still not an official part of the Java SE platform, it's
still optional! In addition this needs to be some special exceptional check, as
javafx is only valid as runtime class in Java 8, in Java 7 it's not indluded.
If You run forbiddenapis with Java 10, it should pass. The reason is: Although
it's shipped with the JDK and the class name is not in the above pattern, but
because it's an external module - it works as expected (I have not verified
this, maybe you can do it). The reason is the module name, it's external. With
Java 8 we have no module names, so the check can only use the above whitelist
of package names.
In short: That's a limitation of forbiddenapis and my ignorance for JavaFX. I'd
suggest to redefine the forbiddenapis target in the luke module to not use the
"jdk-non-portable" signature and instead the more static "jdk-internal"
signature (maybe thorugh an ANT property). Nevertheless, as described above,
JavaFX is a "non-portable" part of the JDK as it's not part of the spec. Not
sure what the best way to solve this. I'd go for the workaround now and use
"jdk-internal" instead of "jdk-non-portable" for the luke module (not for
others, please).
> Make Luke a Lucene/Solr Module
> ------------------------------
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Mark Miller
> Priority: Major
> Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch,
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch,
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png,
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png,
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer":
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked
> with trunk - and it would also be great if it was easier to match Luke jars
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest
> starting point is to straight port Luke to another UI toolkit before
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I
> haven't/don't have a lot of time for this at the moment, but I've plugged
> away here and there over the past work or two. There is still a *lot* to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
