search

mangstadt / ez-vcard

A vCard parser library for Java
Other
398 stars 92 forks source link

Jigsaw modules support without dropping support for Java 8 #131

Open Auties00 opened 1 year ago

Auties00 commented 1 year ago

Hello, I've added support for Java 9+ modules using the moditect plugin. This doesn't require dropping support for Java 8. I've done some testing and everything looks to be working. The second commit probably changed the line breaks in the pom so it looks like a lot of code has changed, but I practically just added the moditect plugin and changed nothing else.

mangstadt commented 1 year ago

I assume that most people are not building ez-vcard themselves and are just downloading the JAR file from the central repository using a build system like Maven. Does this moditect plugin benefit those people in any way, or is it just useful for people who want to build the project themselves?

Auties00 commented 1 year ago

I assume that most people are not building ez-vcard themselves and are just downloading the JAR file from the central repository using a build system like Maven. Does this moditect plugin benefit those people in any way, or is it just useful for people who want to build the project themselves?

What this plugin does is compile a module-info to bundle into the main jar(you check that it's there using for example 7zip). When importing the library using Java ≤ 8, the module info will just get ignored as Java has no idea what do with it, but on newer versions it will detect the module info and treat the library as a named module. The alternative to this approach is to use the Automatic Module Name property in the manifest, but imo this is better as you have a real module info. I exported every package to preserve backwards compatibility, but you could theoretically only expose public APIs now for example, which is very useful imo.

Auties00 commented 1 year ago

Btw I would recommend not exporting any of the io implementation(ezvcard.io and all of its sub-packages), ezvcard.util.org.apache.commons.codec, ezvcard.util.org.apache.commons.codec.binary and perhaps the util class. This could break backward compatibility if someone on Java >= 9 using the module system(aka they have a module-info in their project) is also using a class from those packages. The call is up to you, but imo it's always better to keep it as encapsulated as possible by exporting only the packages that provide APIs that should be publicly available

Auties00 commented 1 year ago

Any updates @mangstadt ?

mangstadt commented 1 year ago

Thank you for your work on this, but I don't think it adds enough utility to make the extra complexity worthwhile.