I'd also be a bit concerned with ONLY compiling with Java 10. There are some changes to how resources are accessed across module boundaries that could break some existing functionality if folks decided to RUN with > Java 9 using the module system. I covered some of these in my 2016 Apache Con talk[1]. I've got a few of the code changes need based on the old 2.0 branch [2] but there may be more. So that said it might be good to just start with the Automatic Module Name entry in the manifest [3]. Then proceed to add the module-info.java when we've developed some tests that run Tika as a module. Thoughts on this approach?
[1] https://www.slideshare.net/rpaulin1/clipboards/tika-java-9-resource-loading [2] https://github.com/bobpaulin/tika/tree/2.x_java9 [3] http://branchandbound.net/blog/java/2017/12/automatic-module-name/ On 6/19/2018 4:10 PM, Tim Allison wrote: > Doh...sorry, right. > > Ken, > Tongue in cheek answer: so that I become a little less stupid about > modern java...see above. :) > Real answer: _if_ we can pull it off, given that we plan to > modularize our parsers anyways, it would be nice to use the language > support in java >= 9 for actual modularity. I know we have to fix some > split packages and possibly rename some of our packages. > I _might_ find some time soon to focus on merging Bob’s awesome 2.0 > work into master, and I thought it would be a good time to try it. > > Nick, > This is good to know. Thank you! > > Cheers, > Tim > > On Tue, Jun 19, 2018 at 4:59 PM Nick Burch <n...@apache.org> wrote: > >> On 19/06/18 20:46, Tim Allison wrote: >>> What would you think of requiring Java 10 to build Tika 2.0 but still >>> setting 8 as the target? This would allow us to bake modularity in now. >>> Given that I haven't actually tried modularizing/jigsawizing Tika yet, >> this >>> could be a complete disaster, of course. :) >> I'm not sure how well it'd work given that most of our dependencies >> aren't java module-ized? >> >> David North (from POI) has done quite a bit on java modules for existing >> codebases, and hit some snags, and IIRC commons have had problems too. I >> don't mind either way though! >> >> Nick >>
signature.asc
Description: OpenPGP digital signature
