[
https://issues.apache.org/jira/browse/LUCENE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448705#comment-17448705
]
Tomoko Uchida edited comment on LUCENE-10255 at 11/24/21, 4:12 PM:
-------------------------------------------------------------------
{quote}There is still time to reiterate the release and modify those scripts to
run Luke in classpath mode. Or fix the module declaration so that it sees what
it needs to see. I'll take a look at this.
{quote}
I would keep it as is - anyway the reflection hack is not good and should be
dropped. I can't take time for now, but I will make a follow-up on 9.1.
I don't think we should reiterate 9.0 release vote for Luke.
was (Author: tomoko uchida):
{quote}There is still time to reiterate the release and modify those scripts to
run Luke in classpath mode. Or fix the module declaration so that it sees what
it needs to see. I'll take a look at this.
{quote}
I would keep it as is - anyway the reflection hack is not good and should be
dropped. I can't take time for now, but I will make a follow-up on 9.1.
> Fully embrace the java module system
> ------------------------------------
>
> Key: LUCENE-10255
> URL: https://issues.apache.org/jira/browse/LUCENE-10255
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Dawid Weiss
> Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> I've experimented a bit trying to move the code to the JMS. It is
> _surprisingly difficult_... A PoC that almost passes all checks is here:
> https://github.com/dweiss/lucene/tree/jms
> Here are my conclusions so far:
> * The JMS and gradle add a lot of complexity (this applies to any
> higher-level tooling, including IDEs, I think). For starters, modules have to
> be JARs. The effect of this is that what was previously a set of directories
> from dependencies now has to be a JAR. What was previously an incremental
> update of a single .class file now ripples throughout the build recreating
> module JARs (ZIPs!)... I didn't realize it at first, but it's a costly thing
> to do. I'm not even sure how IDEs handle this issue.
> * A Java module contains metadata (such as the module version or main class)
> that is completely detached from any source file. These things live in a
> class bytecode of the compiled module-info; interestingly, there is no
> source-level way to specify it - these class attributes are injected by the
> 'jar' tool. Gradle has some fancy on-the-fly asm conversion filter that
> injects it.
> * Dependencies between modules will effectively live in two places: in gradle
> build files and in module-info files. And they can go out of sync, although
> it's probably easy to catch (since javac would complain about missing classes
> during compilation, even if they're in module path).
> * Probably the biggest challenge (not covered in the PoC) are with our custom
> javadoc and ecj linter tasks - they see the module-info.java and can't cope
> with it. At the same time, there is no easy way to exclude that one
> particular file: ecj would have to accept a full set of sources (command
> argument limit will be a problem), javac can accept a full set of java
> sources (external file) but then it doesn't copy doc-files properly anymore
> (this is probably easier to fix).
> * There are differences at runtime that are hard to anticipate - for example
> resource lookups via class loader no longer work (I fixed this in Luke).
> After poking a bit and trying it out I have to say I have mixed feelings
> about moving to the JMS. On the one hand, many things are great - the module
> path, module descriptors and access modes. On the other hand, the tooling
> tricks required to make it all work make you shiver.
> If anybody wants to play/ improve things on that experimental branch (I
> converted Luke to a full module - it works), please be my guest. I have to
> sit on this and think whether it's something I really like or not.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
