Update bundles to also be JPMS modules for java versions 9 and above

[axiopisty]

Each artifact published to maven central, in addition to being valid OSGI bundles, should also be valid java modules. In other words, each bundle should also include a valid module-info.class.

[pdudits]

PRs for that are welcome!

[axiopisty]

I'm working on this, slowly. But I just wanted to call out here, before submitting a pull request, that doing this will require more work than simply moving files into a modular structure and adding the module-info files.

Specifically, soundlibs currently uses sun.misc.Perf, a JDK internal that was supposed to not be used by anything except the JVM. This class has been removed in Java 9.

The only reason soundlibs uses this JDK internal class is to calculate the number of elapsed microseconds since the JVM started. So, I'm going to have to make a change to the SunMiscPerfClock class to accomplish this some other way. My thought is to use java.time.Instant as a replacement, which has nanosecond precision. I don't know yet if this will introduce any bugs or other problems.

Source code for sun.misc.Perf can be reviewed here: https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/classes/sun/misc/Perf.java#L521. Notice that the current implementation of SunMiscPerfClock is based on the highResCounter method which, according to the java docs:

The High Resolution Counter returns the number of ticks since the start of the Java virtual machine. The resolution of the counter is machine dependent and can be determined from the value return by the {@link #highResFrequency} method.

My takeaway from this is that the getMicroseconds method in the SunMiscPerfClock currently returns the number of elapsed microseconds since the JVM starts. It probably doesn't matter so much that this counter starts when the JVM starts as the library appears to use this as a timer or clock for the audio sequencer.

Here is the implementation I'm contemplating:

public class SunMiscPerfClock
implements JavaSequencer.Clock
{

	private static final Instant start = Instant.now();


	/**	Retrieve system time in microseconds.

		@return the system time in microseconds
	*/
	public long getMicroseconds()
	{
		Duration elapsed = Duration.between(start, Instant.now());
		return TimeUnit.MICROSECONDS.convert(elapsed.toNanos(), TimeUnit.NANOSECONDS);
	}
}

The only testing I will be able to do, prior to submitting a pull request, will be to use the jar files I produce locally in a different application I am working on that uses the soundlibs to see if my application works appropriately with the new version of this library, with these changes in it.

Please provide any feedback or suggestions if you have any.

Thanks.

[axiopisty]

Actually, I discovered the Perf class is still available in the java.base module in the jdk.internal package. So we don't need to make this change right now. But, I'm still curious what people think of this. Maybe we can test to see if this approach would work in order to remove the dependency on the jdk.internal implementation.

[pdudits]

I really cannot give much input here, my experience with JPMS is very limited.

However I'd like to point out method System.nanotime, which will cause less allocation overhead, and I think it's also monotonic -- value of Instant can return lower value than before, e. g. after time synchronization over network.

[JCWasmx86]

I tried it today to make those jars modules.

My observations:
-SunMiscPerfClock class is using sun.** package => Solved as seen above
-mp3spi.jar and vorbisspi.jar both contain the package javazoom.spi with the class PropertiesContainer
-tritonus-share.jar and tritonus-all.jar contain the package org.tritonus.share.** and org.tritonus.sampled.file.** (This is quite obvious, but would make the start of the JVM fail, as each package may only be in one module)

I'm now trying to package mp3spi,vorbisspi,jlayer,tritonus-share and jorbis as JPMS-modules in my repo jpms_sound