Bug 117331 - Remove Split Package for Java 9 compatibility
Summary: Remove Split Package for Java 9 compatibility
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: sdk (show other bugs)
Version:
(earliest affected)
5.4.2.2 release
Hardware: All All
: medium normal
Assignee: Samuel Mehrbrodt (allotropia)
URL:
Whiteboard: target:7.0.0
Keywords:
: 127557 (view as bug list)
Depends on:
Blocks: Java-Runtime-JRE
  Show dependency treegraph
 
Reported: 2018-04-29 13:52 UTC by Florian Beetz
Modified: 2020-06-05 05:27 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Java/Eclipse example project (4.39 KB, application/zip)
2020-02-05 10:46 UTC, Samuel Mehrbrodt (allotropia)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Beetz 2018-04-29 13:52:05 UTC
Description:
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.
2. Compile.

Actual Results:  
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

Expected Results:
Compilation completes without errors.


Reproducible: Always


User Profile Reset: No



Additional Info:


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
Comment 1 Xavier Van Wijmeersch 2018-04-30 14:56:48 UTC
openjdk9 is superseded, can you retest it with the 10.0.1 version off openjdk10.

regards
Comment 2 Florian Beetz 2018-04-30 15:16:11 UTC
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.
Comment 3 Buovjaga 2018-06-07 17:12:52 UTC
Pinged devs on IRC and response was cautiously positive, so I will set this to NEW
Comment 4 Michael Stahl (allotropia) 2019-05-02 08:42:31 UTC
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.
Comment 5 Rick Heckadon 2019-06-03 16:46:12 UTC
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.
Comment 6 Noel Grandin 2019-06-03 18:32:57 UTC
@Rick, so merge the jars yourself and try it out?  They're just zip files, it's really easy to do.
Comment 7 Stephan Bergmann 2019-06-04 06:31:11 UTC
(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
Comment 8 Rick Heckadon 2019-06-13 21:25:36 UTC
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?
Comment 9 Samuel Mehrbrodt (allotropia) 2019-11-25 16:14:45 UTC
(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?
Comment 10 Stephan Bergmann 2020-01-30 08:19:10 UTC
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
Comment 11 Commit Notification 2020-02-04 21:05:50 UTC
Samuel Mehrbrodt committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ae855bf48163ff64d94cfc34aff8e37abdb5518d

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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Stephan Bergmann 2020-02-05 07:59:00 UTC
documented at <https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/7.0&oldid=245790> "merged ridl.jar"
Comment 13 Samuel Mehrbrodt (allotropia) 2020-02-05 10:46:45 UTC
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.
Comment 14 Oliver Kopp 2020-04-06 17:54:21 UTC
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?
Comment 15 Michael Stahl (allotropia) 2020-04-07 09:36:20 UTC
(In reply to Oliver Kopp from comment #14)
> 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?

7.0 is quite far from being released, so it doesn't make sense to upload release artifacts now.

see: https://wiki.documentfoundation.org/ReleasePlan/7.0
Comment 16 Christoph 2020-06-01 16:33:09 UTC
That sounds promising. So I guess this fixes https://bugs.documentfoundation.org/show_bug.cgi?id=127557 as well?
Comment 17 Samuel Mehrbrodt (allotropia) 2020-06-05 05:25:59 UTC
*** Bug 127557 has been marked as a duplicate of this bug. ***
Comment 18 Samuel Mehrbrodt (allotropia) 2020-06-05 05:27:29 UTC
(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.