JDK9 module name for Unit-API?

[Martin Desruisseaux]

Hello all

Do we have a JDK9 branch for Unit API 1.0.1-SNAPSHOT? If not, do we
already know the module name that Unit API will have, so we can start
Jigsaw experimentation?

Martin

[Werner Keil]

Hello Martin,

No, not really. There is a ticket for the UoM-SE build (and at least the RI will not work on Jigsaw at least not until there is a Java ME 9 or similar based on it;-) https://github.com/unitsofmeasurement/uom-se/issues/86 so feel free to refer to that if you want.

It's been deferred due to the Jigsaw issues causing especially Maven and relevant plugins to fail so far (maybe that improved over the past few weeks or months, we probably need a separate ticket and tasks just for that) I know the latest NetBeans builds work well with Jigsaw, that was the only environment I got it to work so far, but the builds also in a CI environment must not rely on an IDE only. 

Also something I doubt we can get running in any CI system before Java SE 9 goes Final or slightly after that.

It would look bad to have a branch that constantly fails except on a local system. So hard to say if we should touch that before Java 9 is stable enough and can be used by CI servers. Every branch, also "gh-pages" for the API (mostly for JavaDoc or Maven site) triggers a build, so if we really went to create a "java9", "jigsaw" or similar branch, please ensure it always creates a stable build and create a profile that must be manually enabled for local experiments with Java 9.

We do have quite a few profiles like "jdk8" in unit-api, so it should not be a problem to add some and keep the default build e.g. on "jdk8" for the time being, until "jdk9" is fully supported by the CI servers.

Regards,

Werner

[Werner Keil]

Oh and let's not forget, JSR 363 has already been far more modular than the JDK before Java SE9 ;-)

So the optional packages and bundles must each be manifested as modules.

Whether we use the groupId as module name foundation, that is a possible thought.

So we could would have 

javax.measure.core

javax.measure.format

javax.measure.quantity

javax.measure.spi

As the 4 modules to make up a "javax.measure" JSR module.

We diluted it by putting the modules or bundles into a "Full Profile" JAR, but with Java 9 and Jigsaw the only way to make sense out of them is by true true modules.  

Werner

[Werner Keil]

Maybe the overall module would actually be "unit-api" because the Automatic Module function in Jigsaw also turns the existing JAR into a module named "unit-api" after the JAR file.

We should soon find many JSRs in a similar situation or having to deal with that. 

[Martin Desruisseaux]

I don't think we should create a module for almost every package.
Creating a module for only one interface of 5 methods + one exception is
exaggeration. It is not going to save any RAM on micro devices; quite
the opposite it may cost more RAM (e.g. with more java.lang.Module
instantiations). I think we should have only one module for the whole
Unit-API; it is only 27 kb.

I created a JDK9 branch locally on my machine (not deployed anywhere)
for testing. I use the "javax.measure" module name for now. But does the
JCP has any guideline about what should be module names of their JSR?

Martin

[Werner Keil]

It's not about RAM in Java SE 9, but about clear and proper module definitions. 

The JavaDoc and Spec are quite clear that everything except the core module is optional.http://unitsofmeasurement.github.io/unit-api/site/apidocs/index.html

 Whether you have 3 or 5 classes in a package or 50 does not really matter.

Jigsaw demands that a package is not split across different modules, so declaring a "javax.measure" module consisting of all packages and another one say "javax.measure.compact" consisting of just 1 or 2 may not work, but we have to see and follow what e.g.the JDK does. 

https://github.com/ceylon/ceylon/issues/5845 shows, e.g. "javax.annotation" was renamed to "java.annotations.common" and most other "javax" references were removed. Yet some of those old JSRs that got factored into the JDK over time contain just a handful of elements,but they got their own separate module, too. 

Ultimately we shall see and go along the lines of e.g. CDI 2. It is getting more modular now, as soon as Java 9 allows that we'll see a modular version for Java SE 9 at some point.

In any case, whether it's JSR 363 or 365, there must be at least an official MR for that, so if you create a branch, something like "java9" or "jdk9" should work.

The only JSR that added something like it is JSON-Processing: https://github.com/json-p/api-ri/blob/master/api/src/main/jdk9/module-info.java

It does not hurt to try something like it in a branch, but taking its pattern, maybe all we need was a similar folder for module definitions. 

If legitimate and working, then something similar to

module java.measure {
	exports javax.measure;
	exports javax.measure.format;
	exports javax.measure.quantity; exports javax.measure.spi;
	uses javax.measure.spi.ServiceProvider;
	}

could be enough. As long as other modules like

module java.measure.minimal {
	exports javax.measure;
	}

work the same way without problems. 

374 seems one of the few JSRs outside the JDK itself where they thought about modules. If dropping the "javax" part in favor of "java.*" for the module is a pattern to follow, then maybe we should consider that as long as there is no common JCP practice that says different. At the moment I doubt one exists, but at least JSON-P is led by Oracle.

We must define multiple modules more or less one per profile in https://github.com/unitsofmeasurement/unit-tck#profiles. 

If Jigsaw allows to do this by exporting different numbers of the same package like above, then we may not need a module for each package. If that does not work for some Jigsaw limitation, we may have to solve that by declaring multiple modules and combining them via "umbrella modules" similar to the JDK "java.compact1" or similar.

As we aim for 1.1 as a possible MR1, please for everything that you or others share on GitHub, let's use 1.1-SNAPSHOT for such experiments. 

If adding several module-info files is enough together with some new Maven profiles, maybe it'll work without a special branch, but if we do,  either a "1.1" branch or something with "java9" or "jdk9" in the name might work best. See https://github.com/cdi-spec/cdi the repository has many branches, even for EDRs of CDI 2, but we may not have to go as far ;-)

Werner

[Martin Desruisseaux]

I don't think that we need "compact" profile. For me, optional parts in the specification only means that implementors do not need to implement the optional interfaces. The interfaces can be present in the JAR file but ignored.

Splitting JSR-363 API in many modules would pollute the module path with tiny modules (~5 kb) for no benefit I can see:

• It does not save RAM (it may even be the opposite)
• It does not save space on the disk (it may even be the opposite)
• It is not needed for declaring that some interfaces are optional (implementors can just ignore that interfaces that they do not implement).
  

Le 16/04/2017 à 22:59, Werner Keil a écrit :

As we aim for 1.1 as a possible MR1, please for everything that you or others share on GitHub, let's use 1.1-SNAPSHOT for such experiments. 

Sure, I will stay on SNAPSHOT and not use anything that looks like a release.

    Martin

[Leonardo de Moura Rocha Lima]

I agree with Martin that we can have all interfaces in a single "API" module, and/or all interfaces + the required implementation as a single "required" module, and optional interfaces can come as the implementer wants (single or multiple modules).

Regards,

Leo.

--
You received this message because you are subscribed to the Google Groups "Units Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to units-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Werner Keil]

But the only required interfaces ARE those in the root package javax.measure:

http://unitsofmeasurement.github.io/unit-api/site/apidocs/index.html

It would be rather sad and undermine the whole idea of compatibility if we left defining modules that match the 6 Profiles up to implementations.

Having to create

module my.uom.minimal {
	exports javax.measure;
	}

instead of doing so as Spec Leads and EG ;-/

The difference in Java 9 is, the packages that you don't need are not "ignored" (but still usable because they are publicly visible) they are INVISIBLE in profiles and downstream apps that don't want to use them.

I may not have the time to experiment with JLink or JPackager (http://openjdk.java.net/jeps/275) but we should make proper modules available to match what the Final JSR already declared as Profiles.

If we don't bother doing that, then there's no need for any module definitions, "unit-api" will be the module containing everything that is in the current (full) unit-api.jar, there is absolutely no need to declare it just for the sake of it because Jigsaw Auto-Module will turn the JAR into a module ;-)

Regards,

Werner

Am Montag, 17. April 2017 15:45:14 UTC+2 schrieb llima:

I agree with Martin that we can have all interfaces in a single "API" module, and/or all interfaces + the required implementation as a single "required" module, and optional interfaces can come as the implementer wants (single or multiple modules).

Regards,

Leo.

[Martin Desruisseaux]

Le 17/04/2017 à 22:27, Werner Keil a écrit:

> But the only required interfaces ARE those in the root package
> javax.measure:
>

Yes, but it does not means that the other interfaces can not be in the
same JAR file and just ignored by implementers.

> It would be rather sad and undermine the whole idea of compatibility
> if we left defining modules that match the 6 Profiles up to
> implementations.
>

This is only one aspect of compatibility. It is TCK role to verify if an
implementation is compliant with a profile, together with many other
requirements that can not be enforced by modularization.

> The difference in Java 9 is, the packages that you don't need are not
> "ignored" (but still usable because they are publicly visible) they
> are INVISIBLE in profiles and downstream apps that don't want to use them.
>

It is not sure that we will need to split in different modules for that
(it was not necessary at least in early proposal of Jigsaw). But even if
we lost the possibility to hide non-implemented interfaces, I think that
having visible interfaces has less inconvenient than
over-modularisation. I would agree about creating a module for each
profile if they were relatively large, but in JSR-363 case the modules
would be so tiny (e.g. 2.8 kb for javax.measure.format), I think that if
everyone was doing that we would replace the "classpath hell" situation
by a "module path hell". I don't think it would be in the interest of
Java ecosystem.

> If we don't bother doing that, then there's no need for any module
> definitions, "unit-api" will be the module containing everything that
> is in the current (full) unit-api.jar, there is absolutely no need to
> declare it just for the sake of it because Jigsaw Auto-Module will
> turn the JAR into a module ;-)
>

The module name would be different. That would be indeed the means
difference, but this is an important one. An other difference would be
the declaration of javax.measure.spi.ServiceProvider as a service.

Martin

[Werner Keil]

On Tuesday, April 18, 2017 at 12:27:33 AM UTC+2, Martin Desruisseaux wrote:

Le 17/04/2017 à 22:27, Werner Keil a écrit:

> But the only required interfaces ARE those in the root package
> javax.measure:
>
Yes, but it does not means that the other interfaces can not be in the
same JAR file and just ignored by implementers.

That was the case with all those "sun.misc.unsafe" packages they were supposed to be ignored by implementors, yet they were used by a large portion causing this "unsafe hell" which forced Oracle to even make it available though its JDK team originally intended to hide it:

https://adtmag.com/blogs/watersworks/2015/08/java-9-hack.aspx

 

> It would be rather sad and undermine the whole idea of compatibility
> if we left defining modules that match the 6 Profiles up to
> implementations.
>
This is only one aspect of compatibility. It is TCK role to verify if an
implementation is compliant with a profile, together with many other
requirements that can not be enforced by modularization.


> The difference in Java 9 is, the packages that you don't need are not
> "ignored" (but still usable because they are publicly visible) they
> are INVISIBLE in profiles and downstream apps that don't want to use them.
>
It is not sure that we will need to split in different modules for that
(it was not necessary at least in early proposal of Jigsaw). But even if
we lost the possibility to hide non-implemented interfaces, I think that
having visible interfaces has less inconvenient than
over-modularisation. I would agree about creating a module for each
profile if they were relatively large, but in JSR-363 case the modules
would be so tiny (e.g. 2.8 kb for javax.measure.format), I think that if
everyone was doing that we would replace the "classpath hell" situation
by a "module path hell". I don't think it would be in the interest of
Java ecosystem.

Again, unless Jigsaw was made available on a future Java ME, it is not about size

It's about defining proper modules for developers who want to add only what they need.

We defined those profiles in the Spec https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg_QlANT92_lhxUWO2gCY/edit#heading=h.svdarijrxn98

They are not just for the TCK, so whatever Jigsaw allows us to do, if we can define at least 6 of those 7 profiles ("SI Quantities" could be hard, I am not aware, that Jisaw allows to export just 7 distinct classes, but maybe it does?) via appropriate modules.

Not sure, if I have enough time before the F2F, but Heather asked if I wanted to do a presentation on JSR 363 with Leo in Texas next month.

Everyone keeps asking us, "When will JSR 363 be part of the JDK". With Java 9 while it will have some drawbacks and limitations, one of the advantages will be to create a custom Java package via JLink, JPackage, etc.

E.g. the JMod Files are mainly during build time, not the faintest clue, how Maven, etc. will handle those or if there needs to be some kind of "Module Repository" just for those, but we should provide a JMod per distinct Module so applications can be tailor-made for the exact need of each application: http://openjdk.java.net/jeps/261#Packaging:-JMOD-files

Werner

[Martin Desruisseaux]

Le 18/04/2017 à 15:22, Werner Keil a écrit :

> But the only required interfaces ARE those in the root package
> javax.measure:
>
Yes, but it does not means that the other interfaces can not be in the
same JAR file and just ignored by implementers.

That was the case with all those "sun.misc.unsafe" packages they were supposed to be ignored by implementors, yet they were used by a large portion causing this "unsafe hell" which forced Oracle to even make it available though its JDK team originally intended to hide it:

Werner, this has nothing to do with our case!!!! sun.misc.unsafe has never been part of any public specification and was not supposed to be used by anyone outside JDK, under any circumstance. This example has nothing to do with optional API!

Again, unless Jigsaw was made available on a future Java ME, it is not about size

It's about defining proper modules for developers who want to add only what they need.

We don't need to split unit API in many modules for that. It changes nothing to the fact that developers can implement only what they need.

They are not just for the TCK, so whatever Jigsaw allows us to do, if we can define at least 6 of those 7 profiles ("SI Quantities" could be hard, I am not aware, that Jisaw allows to export just 7 distinct classes, but maybe it does?) via appropriate modules.

Fine for defining different profiles, but why those profiles would need to be defined as different Jigsaw modules? I don't think that visibility of one interface is a sufficient reason. Many modules in the JDK have optional operations (e.g. JDBC is full of optional features, with java.sql.DatabaseMetaData describing what is supported); they do not split each of them in separated modules for that reason, otherwise we would get an explosion of modules amount.

    Martin

[Werner Keil]

We already extend the core with the "quantity" package. Which is optional for a good reason, so in a "base", "minimal" or "compact" profile/module it shouldn't be there. 

As for the java.sql example just look at the JDK sources:

http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/46e1898b6c6e/src/java.sql.rowset/share/classes/module-info.java

shows, java.sql.rowset got its own module definition different from java.sql

http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/46e1898b6c6e/src/java.sql/share/classes/module-info.java

So every package or small group of packages that are self-contained define their own module. So should we, unless defining modules with different names holding together packages (that are not modules themselves) works, then modules for the profiles are also OK. 

JDK does the same for sub-packages like java.util.logging

http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/46e1898b6c6e/src/java.logging/share/classes/module-info.java

Or java.util.prefs

http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/46e1898b6c6e/src/java.prefs/share/classes/module-info.java

Werner

 

[Werner Keil]

I think this can be helpful to get an idea of Jigsaw:

https://github.com/AdoptOpenJDK/jdk9-jigsaw

And apply it with packages containing just a single element each;-)

[Martin Desruisseaux]

Le 18/04/2017 à 22:21, Werner Keil a écrit :

We already extend the core with the "quantity" package. Which is optional for a good reason, so in a "base", "minimal" or "compact" profile/module it shouldn't be there.

I do not question the fact that some interfaces are optional. But being optional does not necessarily require being a separated module.

As for the java.sql example just look at the JDK sources (...snip...):

"java.sql.rowset" is a 207 kb module compared to 76 kb for the core "java.sql" module, so this separation makes a lot of sense for the common case when we need only the core JDBC interfaces. Such separation does not make sense for JSR-363, where for example "javax.measure.format" is only 2 kb.

I disagree about saying that modularization is not a matter of size. We do not split in different modules just because we can. We split in different modules when it is possible and it can save a significant amount of dependencies in common use cases.

So every package or small group of packages that are self-contained define their own module.

This is not my reading of JDK practice. The "javax.transaction.xa" package is included in "java.sql" module even if it could have been separated. The "javax.sql.rowset.serial" package is included in "java.sql.rowset" module even if it could have been separated. The "javax.naming.ldap" package is included in "java.naming" module even if it could have been separated. Etc. etc. etc. Many JDK modules have packages that could have been in a separated module.

JDK does the same for sub-packages like java.util.logging

Logging is challenged by competitors (Log4J, SLF4J, etc.) and have been abstracted by the new System.Logger interface. Do you expect JSR-363 to be challenged by competitor API? (I'm not talking about implementations).

To summarize again: well though modularisation is nice, but over-modularisation has inconvenient: it pollute the module path, increase the risk of version mismatch and requires extra attention from the developers. Those inconvenient have to be compensated by advantages. In the case of JSR-363, there is none except hiding non-implemented interfaces. This hiding is not a sufficient reason in my opinion; the JDK has many interfaces that are unconditionally provided and documented as optional.

    Martin

[Werner Keil]

On Tuesday, April 18, 2017 at 11:38:13 PM UTC+2, Martin Desruisseaux wrote:

Le 18/04/2017 à 22:21, Werner Keil a écrit :

We already extend the core with the "quantity" package. Which is optional for a good reason, so in a "base", "minimal" or "compact" profile/module it shouldn't be there.

I do not question the fact that some interfaces are optional. But being optional does not necessarily require being a separated module.

As for the java.sql example just look at the JDK sources (...snip...):

"java.sql.rowset" is a 207 kb module compared to 76 kb for the core "java.sql" module, so this separation makes a lot of sense for the common case when we need only the core JDBC interfaces. Such separation does not make sense for JSR-363, where for example "javax.measure.format" is only 2 kb.

I disagree about saying that modularization is not a matter of size. We do not split in different modules just because we can. We split in different modules when it is possible and it can save a significant amount of dependencies in common use cases.

So every package or small group of packages that are self-contained define their own module.

This is not my reading of JDK practice. The "javax.transaction.xa" package is included in "java.sql" module even if it could have been separated. The "javax.sql.rowset.serial" package is included in "java.sql.rowset" module even if it could have been separated. The "javax.naming.ldap" package is included in "java.naming" module even if it could have been separated. Etc. etc. etc. Many JDK modules have packages that could have been in a separated module.

JDK does the same for sub-packages like java.util.logging

Logging is challenged by competitors (Log4J, SLF4J, etc.) and have been abstracted by the new System.Logger interface. Do you expect JSR-363 to be challenged by competitor API? (I'm not talking about implementations).

I certainly question the need to force it onto people with the "quantity" package. It is based on a subset of SI already, so if people in a certain industry have no use for them, why force it onto them. Format is relatively small, but not everyone needs UnitFormat, e.g. in a totally "headless" environment. So it is not only about size of the JAR, it is mainly about "do I need it in my device or environment?" 

Werner

[Jean-Marie Dautelle]

Hello Werner,

I kind of agree with Martin. 

Architecture-wise a plugin approach is far superior to profiles. In others words there should be a core unit API to which we could add optional packages. These plugins can be in separate modules or not :)

Cheers

Jean-Marie

[Werner Keil]

We won't get the answer here for all questions, but I asked Dmitry, the Spec Lead of JSR 374 if there was a guideline or decision at Oracle to use a "java.*" module namespace for all things Java related, whether it's the JDK or a JSR.

JSR 374 makes heavy use of that model-info in a set of profiles I have not tried out myself (I build the JSR for Java 8 in regular intervals) 

https://github.com/json-p/api-ri/blob/master/pom.xml

JSR 363 API also contains multiple profiles to build either against a different JDK (from 6 to 8) or only produce a module JAR like unit-api-core.jar. There similar to 374 we must define a module-info that matches the content. And the module must have a different name, e.g. java.measure.core similar to the JAR name that would already tell Jigsaw based on the JAR file without interference.

Werner

[Werner Keil]

Jean-Marie,

I guess like with Javolution, you are a bit ahead of your time (or at least that of Java ;-)

The plugin mechanism in http://openjdk.java.net/jeps/282 is said to be "strictly experimental" unlike e.g. OSGi. That is one issue people in and outside the EC argue about Jigsaw's usefulness alltogether (they may not stop it but you might see some "No" votes if the JDK team does not improve things;-)

Mostly for Java ME or other small embedded systems we already have "profiles" in Maven that create smaller JARs. It works now, they are not on MavenCentral at this point, but can be built and are fully in sync with the Spec or TCK and concept of "profiles" defined there.

Whenever something like that is used with Java 9, we must also ensure the module is declared and has a proper name, e.g. 

module java.measure.core {
	exports javax.measure;
	}

or similar based on JSR 374's module info.

Cheers,

Werner

[Martin Desruisseaux]

Le 19/04/2017 à 10:23, Werner Keil a écrit :

> I certainly question the need to force it onto people with the
> "quantity" package. It is based on a subset of SI already, so if
> people in a certain industry have no use for them, why force it onto
> them. Format is relatively small, but not everyone needs UnitFormat,
> e.g. in a totally "headless" environment. So it is not only about size
> of the JAR, it is mainly about "do I need it in my device or environment?"
>

But you do not need to put interfaces in a separated module for making
them optional. If you don't need UnitFormat, don't implement it; thats
all! The JDK has many optional interfaces that are not in separated modules.

I disagree that this is not about JAR size. The decision to split in
many modules or not is a mix of many factors. JAR file size is one of
them (but not the only one).

Martin

[Werner Keil]

I did not have the time to run it even with JSON-P, but if what was done there in https://github.com/json-p/api-ri/tree/master/api/src/main/jdk9

can be done with more than one module-info file consisting of different number of packages, then we would not have to introduce a module-info directly into a particular package (which is possible and done, see the JDK) 

GeoAPI is a good example, e.g. does it really use a SystemOfUnits implementation or any of the SPI elements?

Or does it implement UnitFormat? I know you mentioned some Format, but is it really required?

Otherwise the QUANTITY profile seems enough for its case (I remember more than just the 7 SI Base units are used), if you really need formatting based on JSR 363 then at most QUANTITY_FORMAT but not the SPI or FULL profile.

Werner

[Martin Desruisseaux]

Le 19/04/2017 à 13:44, Werner Keil a écrit :

I did not have the time to run it even with JSON-P, but if what was done there in https://github.com/json-p/api-ri/tree/master/api/src/main/jdk9 can be done with more than one module-info file consisting of different number of packages, then we would not have to introduce a module-info directly into a particular package (which is possible and done, see the JDK)

module-info.java are not on a per-package basis. There is only one module-info.java per module. The one that I use for JSR-363 API is (the module name may need to be changed):

module javax.measure {
    requires java.logging;

    exports javax.measure;
    exports javax.measure.quantity;
    exports javax.measure.format;
    exports javax.measure.spi;

    uses javax.measure.spi.ServiceProvider;
}

GeoAPI is a good example, e.g. does it really use a SystemOfUnits implementation or any of the SPI elements? Or does it implement UnitFormat? I know you mentioned some Format, but is it really required?

GeoAPI does not use SystemOfUnits or UnitFormat itself, but it doesn't matter; having those interfaces in the JAR file is not a problem at all even if GeoAPI does not use them. I see no benefit in providing them in separated modules. Furthermore while GeoAPI does not use SystemOfUnits or UnitFormat itself, GeoAPI implementers can choose to use them (Apache SIS implements all of them). Since the choice is left to implementers, the various JSR-363 profiles are nothing but complications for GeoAPI. We use only the full JAR file; doing otherwise would increase the developer workload just for saving (maybe!) a tiny amount of kilobytes on disk.

    Martin

[Martin Desruisseaux]

We are repeating ourselves in last emails. Can we agree on the following?

1. Optional interfaces may be provided in separated module, but don't have to. The JDK has lot of examples of optional interfaces that are not in separated modules.
2. Decision to create a separated module or not is based on a mix of reasons, including:
• Many applications do not need the optional functionality.
• Omitting the unneeded functionality can save a significant amount of space.
  
3. Modularising JSR-363 saves a negligible amount - if any - of space (e.g. 2 kilobytes for javax.measure.format).
4. Modularisation has costs: longer module path, slightly more memory consumption, risk of version conflict, developers need to care about more things.

My opinion is that JSR-363 modularisation benefits are too small compared to inconvenient.

    Martin

[Werner Keil]

Martin,

Let's make available what is already available now. Anybody can download and build "unit-api-*" from the public repo that was also published as part of the JSR

(https://github.com/unitsofmeasurement/unit-api/releases/tag/1.0 pointed from the Spec)

We are not obliged to ship or deploy smaller JARs to MavenCentral ourselves, but we should make a distinction between "java.measure" and e.g. "java.measure.core" like the profile goals do now for the JAR names. Anything else would cripple what's there in the 1.0 release and we must not do that regardless of how many or how few people use them.

I highly doubt we need a separate branch for that, so based on existing Maven profiles like

<profile>
	<id>jdk8</id>
	<properties>
	<jdkVersion>1.8</jdkVersion>
	</properties>
	</profile>

and what was done for JSR 374 in https://github.com/json-p/api-ri/blob/master/pom.xml

we should be able to create one or more "jdk9" profiles for JSR 363, too.

Unless the PMO or some "architects" at Oracle tell every JSR and Spec Lead to use "javax" let us follow the pattern of JSR 374 ("java.*" for the module name), it is the only one I know having started Java 9 and Jigsaw support even in the Java EE 8 release train.

Do you want to work on that?

I'm happy to do what's necessary in the Profile JAR profiles, so don't worry about that. 

Thanks,

Werner

[Werner Keil]

I created 2 tasks https://github.com/unitsofmeasurement/unit-api/issues/41 and https://github.com/unitsofmeasurement/unit-api/issues/42 

At the moment since the way JSR 374 did this was also via nearly identical Maven profiles (like "jdk9") this does not look like a separate branch was really necessary. 

We are not talking about an API change at this point, only a module-info.java file or a few of them in a separate folder (at last JSON-P does, should be easy to follow their example)

Regards,

Werner