[ https://issues.apache.org/jira/browse/LUCENE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17449455#comment-17449455 ]
Uwe Schindler commented on LUCENE-10255: ---------------------------------------- Hi, About compatibility with the to-be-released Lucene/Luke 9.0 and auto-modules: I opened a Lucene 8.8 index yesterday (I chose a random ZIP from the backwards tests of branch 9.0) in Luke 9.0.0 (non RC, fresh built) yesterday. So discovery with auto-modules worked. That's good. Of course with module-info files we need to declare the "uses" (in lucene-core) and "provides" clauses (all modules that export) clauses. Uwe > 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 > Attachments: screenshot-1.png, screenshot-2.png > > Time Spent: 2h 20m > 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: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org