The Java libraries ridl, unoil, juh, and jurt all export the package 'com.sun.star'.
This makes them incompatible with the Java 9 module system.
Steps to Reproduce:
1. Add at least two libraries to the module path.
Compilation fails with
error: the unnamed module reads package com.sun.star.security from both unoil and ridl
error: the unnamed module reads package com.sun.star.task from both unoil and ridl
error: the unnamed module reads package com.sun.star.util from both unoil and ridl
error: the unnamed module reads package com.sun.star.script from both unoil and ridl
error: the unnamed module reads package com.sun.star.uno from both jurt and ridl
Compilation completes without errors.
User Profile Reset: No
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
openjdk9 is superseded, can you retest it with the 10.0.1 version off openjdk10.
Thanks for your reply.
Tested again with
openjdk 10.0.1 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10)
OpenJDK 64-Bit Server VM (build 10.0.1+10, mixed mode)
The problem persists.
Pinged devs on IRC and response was cautiously positive, so I will set this to NEW
how does one reproduce this? clearly it doesn't happen during any of the numerous junit tests that run as part of the LO build.
the SDK's jars don't make any claim to be Java Modules, FWIW, and if it's necessary to rearrange the content to make that possible - and thereby break compatibility - then i don't foresee that happening soon.
I'm having the same issue, but it's because I've included JavaFX 11 in my project. JavaFX 11 uses the new Java Modular system that was released in Java version 9. This means that when the project is compiled, any non modular libraries (i.e. LibreOffice Java API) are put into the unnamed module, where each jar file is treated as a module. Since ridl, unoil, juh, and jurt are all separate jar files, they are each treated like their own separate module. This is usually fine, except each jar shares liked named packages (i.e. ridl and jurt both have a package called com.sun.star.lib.util), which in the Java Modular system are called split packages. Before the Modular system, this was allowed to work without a hitch, but it's a non-starter with Java 9 on and causes errors that stops the project from compiling.
I have an example project that creates a JavaFX window with a button in it that would create an the SWriter example doc when clicked, but I'm not sure how to share it with everyone? The project uses NetBeans 11.0, AdoptOpenJDK 11, and JavaFX 11. If I can't share the code, you may be able to setup the project yourself by merging the JavaFX 12 helloworld example and the SWriter example. HelloWorld is here: https://github.com/openjfx/samples. And the Swriter example is here: https://api.libreoffice.org/examples/examples.html#Java_examples.
I think that the best way to solve this issue and still be compatible with older Java versions (Java 8), is to put ridl, unoil, juh, and jurt into a single jar file for Java 9 projects and above, but still have the 4 separate jars for Java 8 projects and below. By doing this, the Modular system would treat the single jar file as a single module. The modular system would then not flag this module as having split packages and the project could compile correctly.
@Rick, so merge the jars yourself and try it out? They're just zip files, it's really easy to do.
(In reply to Noel Grandin from comment #6)
> @Rick, so merge the jars yourself and try it out? They're just zip files,
> it's really easy to do.
...though you need to take care to include a proper combined meta-inf/manifest.mf
Sorry that this took so long, but I was finally able to merge all the required jars into one jar, included it into the program, and the program finally compiled and worked! I believe this is the solution to this problem. Would a merged jar be possible in future updates of LibreOffice?
(In reply to Rick Heckadon from comment #8)
> Sorry that this took so long, but I was finally able to merge all the
> required jars into one jar, included it into the program, and the program
> finally compiled and worked!
Can you share your resulting jar file, or at least the steps how you created it?
Adding the freenode IRC #libreoffice-dev conversation from last December for reference:
> Dec 11 09:20:01 <samuel_m> sberg: I'm trying to fix #117331. looks like we need to keep the current split packages for backwards compatibility, and add a new combined jar which also is a proper java module. any idea how to implement that in the build system? would a postprocess script which creates the combined jar be a good idea?
> Dec 11 09:20:03 <IZBot> LibreOffice-sdk normal/medium ASSIGNED Remove Split Package for Java 9 compatibility https://bugs.documentfoundation.org/show_bug.cgi?id=117331
> Dec 11 09:23:55 <sberg> samuel_m, would there be guarantees that there won't be any interference between the old split jars or the new single jar, in case they can get both used in a single JVM instance?
> Dec 11 09:26:03 <samuel_m> sberg: hm good question, I guess we can only tell that by trying out. but I would think that each java program only uses the jars from its classpath
> Dec 11 09:27:58 <mst___> sberg would it help to put all the class files into one of the existing jars and then ship the other jars basically empty? or is that not possible because it needs something incompatible in the manifest?
> Dec 11 09:29:17 <mikekaganski> I don't know nothing about Java modules, but can't it be possible to create a "module" for "Java modular system" that is just a wrapper that uses those separate JARs, without actually merging those?
> Dec 11 09:30:05 <sberg> mst___, don't think I ever thought about that, might even be the best way out
> Dec 11 09:32:27 <sberg> samuel_m, a first step to solve anyway is that unoil.jar is not part of URE
> Dec 11 09:32:53 <sberg> (if there shall be a combined entity that is part of URE)
> Dec 11 09:34:00 <mst___> i guess we could have an URE module and a office module but i don't see what value a URE provides anyway... nobody uses URE without office
> Dec 11 09:34:16 <tml_> but... but... it is UNIVERSAL!!!
> Dec 11 09:34:16 <samuel_m> sberg: I don't understand this, what exactly needs solving there?
> Dec 11 09:35:08 <sberg> at least some Linux distros still split out a URE package
> Dec 11 09:36:20 <sberg> ...as do the TDF builds
> Dec 11 09:36:39 <noelgrandin> and we can't just tell those linux distros, that such is not really useful?
> Dec 11 09:36:57 <tml_> noelgrandin: no. the distro people are EXPERTS.
> Dec 11 09:37:05 <sberg> at least we would need to do that
> Dec 11 09:37:29 <sberg> ...and rework the TDF builds
> Dec 11 09:45:33 <samuel_m> sberg: the problem is that unoil and ridl have the same package names, and jurt and ridl too. So at least we need to merge those 3
> Dec 11 09:45:46 <samuel_m> error: the unnamed module reads package com.sun.star.security from both unoil and ridl
> Dec 11 09:45:46 <samuel_m> error: the unnamed module reads package com.sun.star.task from both unoil and ridl
> Dec 11 09:45:46 <samuel_m> error: the unnamed module reads package com.sun.star.util from both unoil and ridl
> Dec 11 09:45:46 <samuel_m> error: the unnamed module reads package com.sun.star.script from both unoil and ridl
> Dec 11 09:45:46 <samuel_m> error: the unnamed module reads package com.sun.star.uno from both jurt and ridl
> Dec 11 09:46:03 <sberg> samuel_m, sure, the problem is well understood
> Dec 11 09:52:33 <samuel_m> ok I guess I'll try to do what mst___ suggested and keep those 4 jars, but put all class files in one jar and leave 3 basically empty
> Dec 11 09:59:55 <sberg> samuel_m, maybe there's a chance to keep juh.jar out, if none of its published content (cf. <https://api.libreoffice.org/docs/java/ref/index.html>) is in packages that overlap with the published content of the other three jars
> Dec 11 10:02:48 <samuel_m> sberg: yeah makes sense. although I would consider it an advantage to have all of this stuff in one jar. makes it easier for extension developers
> Dec 11 10:04:09 <sberg> samuel_m, but extensions would still need to reference the original jars, no? (but maybe it could simplify things at extension development time)
> Dec 11 10:07:33 <samuel_m> sberg: they would need to reference only one jar instead of 4
> Dec 11 10:09:05 <tml_> I wonder if it is intentional that the word "jar" means a container
> Dec 11 10:10:48 <sberg> samuel_m, you mean, the manifests of jars contained in the extension could list the new super.jar instead of the original ones? yeah, right, /if/ the plan works to make the original jars empty forwarders to super.jar (and the extension is only meant to work with LO >= has-super.jar)
> Dec 11 10:10:57 <noelgrandin> tml_, in theory it means "java archive", but that coindince was probably too good to pass up :-)
> Dec 11 10:21:35 <mst___> samuel_m, btw theres a ure/source/README file with some documentation but not sure if it's of any help
Samuel Mehrbrodt committed a patch related to this issue.
It has been pushed to "master":
tdf#117331 Merge jurt and unoil into ridl
It will be available in 7.0.0.
The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
documented at <https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/7.0&oldid=245790> "merged ridl.jar"
Created attachment 157668 [details]
Java/Eclipse example project
For reference, a small project to test this.
Import in Eclipse & adjust the LibreOffice jars in the classpath to test it yourself.
Congratulations for fixing this! I see it in the changelog: https://wiki.documentfoundation.org/ReleaseNotes/7.0#API_changes
However, I do not see "ridl.jar" 7.0.0 on maven central: https://mvnrepository.com/artifact/org.libreoffice/ridl
Is there any ETA? Maybe, the maven coordinates changed?
(In reply to Oliver Kopp from comment #14)
> Congratulations for fixing this! I see it in the changelog:
> However, I do not see "ridl.jar" 7.0.0 on maven central:
> Is there any ETA? Maybe, the maven coordinates changed?
7.0 is quite far from being released, so it doesn't make sense to upload release artifacts now.
That sounds promising. So I guess this fixes https://bugs.documentfoundation.org/show_bug.cgi?id=127557 as well?
*** Bug 127557 has been marked as a duplicate of this bug. ***
(In reply to Christoph from comment #16)
> That sounds promising. So I guess this fixes
> https://bugs.documentfoundation.org/show_bug.cgi?id=127557 as well?
Yes, correct; marked that bug as duplicate.