Hi and welcome to my talk, LibreOffice Extensions with Java Module Support. I'm Samuel Mierbrot and I'm working for CIB Software as a LibreOffice developer. Today we will see how the new Java module system is now available to Java extension authors.

At the end of the talk we also have a small demo where we will see how to change an existing extension to make use of the new Java module system. So, let's get started. What's new in Java? Relatively new Java 9 introduced a new module system named Jigsaw.

It solved a number of problems with dependencies that existed in larger Java applications. I won't get into detail here, but if you're interested you'll find a lot of online resources about this topic. Just a quick introduction.

You can add a module-info.java to your Java project and there you can declare a module with a module name. In this case it's org.codevx.foo. It can require other modules. In this case it requires a module named org.codevx.bar and it can export a series of packages.

In this case it exports the package org.codevx.foo.api. This is the basics of the Java module system. It replaces the use of classpath which could get very long and complex for larger applications.

Each module can then just export a set of packages and every package which is not exported is also not visible to the outside. In LibreOffice the bug report we got was in 2018.

It was reported that when you use the LibreOffice JAR files from a Java application which uses the Java module system, it just did not work. Everything is loaded as a module even if the JAR files are still the old classic JAR files without any module information.

They will get loaded as the unnamed module and then they need to fulfill the requirements of the Java module system. One part of it is that each package can only appear in one module.

For example, com.sanstar.security is a package we export and it was in both UNOIL and RIDL JAR files. This did not work anymore with the new module system.

This is called split packages. What we did earlier was no problem until now. What did we do in LibreOffice? The first step was merge those JAR files which had shared packages or split packages.

In this case it was JURT.JAR, UNOIL.JAR. Those two were merged into RIDL.JAR. One can ask what is with backwards compatibility. The answer is backwards compatibility is given because the old JAR files are still there.

They are empty. They don't contain any class files. The only thing they do contain is a manifest with a class path set to the new JAR file or the other JAR file, RIDL.

If you load the JURT and the UNOIL.JAR in an old project, it will still work because it has all the class files you need in the classpath. The second challenge was that we are now changing the packages and we thought this naming is a bit confusing for some users.

RIDL.JUH.JURT.UNOIL. Almost nobody can tell what those names mean.

Even probably most LibreOffice developers can't tell what exactly those names mean. By merging already two packages into RIDL, those names did not make any more sense.

We thought what if we merge all public JAR files into one and give it a distinct name so that external developers can recognize it easily. We got the LibreOffice.JAR. That's a new JAR file.

Still the same as I said before. Backwards compatibility is given. You can still load the old JAR files and have the LibreOffice.JAR on the classpath.

The next thing to do was add the module info. Up to now you could use the LibreOffice.JAR files in a Java application which uses the Java module system.

But it was still named the unnamed module. So we wanted to give it a proper name. Thus we created the module info for LibreOffice.JAR. It looks like this. It has the module name ORG.LibreOffice.UNO. And it requires another module, the UNO loader.

That is the class loader for the UNO classes. And it exports a set of packages. You probably know these names if you've ever worked with UNO API.

So this is the module info we added to the LibreOffice.JAR and all those packages listed there you can then use in the client code. All of this has been available since the release of LibreOffice 7.0 which has been released earlier this year.

And the question is now how do I use it? And I'm going to demonstrate it by using the LibreOffice starter extension and then modify it to use the Java module system. First we need to download the LibreOffice starter extension. You find it on GitHub and just go and download the zip file.

No need to clone the repository. There it is. Then we open up Eclipse and here you need to make sure that you have the LO Eclipse plugin installed.

That's an Eclipse plugin for LibreOffice which helps developing extensions and components in Java or even Python. Yeah, it makes it quite a bit easier. So this is the plugin. Make sure you have that installed if you want to use this starter project.

Okay, now I will import this file I just downloaded. You can just select a zip file here and it finds the project.

Okay, there we go. Now we need to tell this where our LibreOffice installation is. We go to project properties. Then we have LibreOffice properties. This comes from the LO Eclipse plugin. Configure LibreOffice. We need to find the path.

I have it in opt. Just the installation folder and you also need the SDK. That's usually a separate download.

So make sure you have it downloaded and installed and it is usually in the same folder, the SDK subfolder. But it can be anywhere so it needs to be specified separately. Yeah, we have we set this. Okay, the errors are gone. Now we want to deploy it to our LibreOffice installation.

We go to run configurations and then we have a type LibreOffice application. This also comes from the LO Eclipse plugin. We choose the starter project, set the name and I take this option to use clean user profile.

That means when running it from Eclipse, a separate user profile is used and it does not interfere with your existing user profile.

Sometimes we need to run it twice. I don't know why. Okay, there we go. So this is LibreOffice 7.0. And if you go to tools extension manager, you find the starter project here.

Then we go to writer. Yes, I did know. Then you find a new menu entry starter project. Action one. And if you see this dialogue, the extension works probably. If you don't, if it

doesn't work, go to the options and make sure you have a proper Java runtime environment configured here. It needs to be at least version nine for this module system to be supported.

Okay, we close this, go back to Eclipse and now we want to convert this into, yeah, to use the Java module system. Currently, if you check the build path, you see it has the class path set and it has the LibreOffice libraries on the class path.

Now we want them to go into the module path. And for that, Eclipse helps us. You can right click on the project, go to configure and then create module info.java. So we give it some proper name. Usually you use reverse domain notation. There it is.

So it already detected the packages which we have in our project and it already detected that we use another module, namely the module from the LibreOffice.jar.

So we don't want to export those packages. There is no use for other extensions or other projects to use them. They are just internal. We just have this requires inside save and then we check again the build path and there we see the class path is now empty.

Instead, the module path, you find the LibreOffice libraries, which also contains the LibreOffice.jar.

We could now remove all the other ones, but for now I will leave them just there. Doesn't hurt. And now if we check, for example, this LibreOffice.jar, you can see all the packages which are exported, the class files. And you can see this has a module info.class and if it's decompiled,

you see the module name, the requirements and also the packages which are exported. OK, yeah, that's all to convert an existing class path based project to a module path based one or module based one.

And now we want to run it and make sure it still works. We go again to the run config and run this. Yeah, there is our LibreOffice. We go to writer and check this still works.

It does work. And now let's check the generated extension. We open this project in the system explorer. There we have the folder dist, which contains the starter project .oxt OpenOffice extension, if I remember correctly.

There we have the jar file. And if we open that one, we see the module info.class, which is a compiled version of our module info we added here.

Yeah, that's all you need to do to convert your existing LibreOffice extension project to work with Java modules. Just beware that when you do this, you need Java 9 at least. And you also need LibreOffice 7.0 at least.

Yeah, thanks a lot for listening. This was Samuel Meerbrot from CIB. Check out our website and our products on libreoffice.cib.de