[libbluray-devel] libbluray on Windows 10 with JRE 9

[Petri Hintukainen]

ti, 2017-12-19 kello 08:36 +0100, Fridrich Strba kirjoitti:
> Hello,
> 
> On 10/12/17 16:15, epirat07 at gmail.com (Marvin Scholz) wrote:
> > Does it need to compile with JDK 9 to run with JRE 9?
> 
> For this case, it actually does :(
> For instance, the BDFileSystem does not implement one virtual
> function,
> so on runtime, there is a potential problem.
> Also, sun.awt.CausedFocusEvent.Cause was removed and replaced by
> FocusEvent.Cause which is new in jdk9. So that is another symbol that
> will not be resolved on runtime.
> 
> I am attaching a patch that allows here building on Linux, but the
> resulting library cannot be run any more with jdk < 9, since the
> FocusEvent.Cause does not exist in jdk8. 

We need to maintain backwars compatibility. One possible solution is to
rewrite both classes so that those work in both < 9 and 9+. Those are
simple event clsses so it shouldn't be much work.

> Also the patch resolves the
> implementing of the missing function of FileSystem by extending
> UnixFileSystem. Which is bound to work here on Linux, but a fix for
> Windows has to be different.

This should be already fixed in git. BDFileSystem is kind of proxy
class, adding this new function fixes the issue.

> > It seems it already fails at initializing the JVM, maybe API
> > changed for that?
> 
> In src/libbluray/bdj/bdj.c there is:
> 
> static const char * const jvm_dir[]  = {"jre/lib/" JAVA_ARCH
> "/server"};
> 
> which is wrong for jdk9 and higher, since it should be "lib/server"
> simply. Most likely that is why you cannot initialize the JVM.

This is also fixed in git.

The problem in Windows was similar; In windows registry is used to
locate JVM, and they changed the registry key name.

The next issue will be this:

  -Xbootclasspath/p is no longer a supported option.
  bdj.c:811: Failed to create new Java VM. JNI_CreateJavaVM result: -6

This is critical feature and needs to be fixed somehow. Pretty much all
of our compat code depends on this (overriding classes from RT libs).

> But there are some more bad news. When you try to build the whole
> thing
> with jdk10, which is due to be released in March, you get:
> [javac]
> /home/abuild/rpmbuild/BUILD/libbluray-
> 1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:81:
> error: cannot find symbol
> [javac]                 if
> (classDepth("javax.crypto.JceSecurityManager") < 3) {
> [javac]                     ^
> [javac]   symbol:   method classDepth(String)
> [javac]   location: class BDJSecurityManager
> [javac]
> /home/abuild/rpmbuild/BUILD/libbluray-
> 1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:88:
> error: cannot find symbol
> [javac]                 if (classDepth("org.videolan.Libbluray") ==
> 3) {
> [javac]                     ^
> [javac]   symbol:   method classDepth(String)
> [javac]   location: class BDJSecurityManager
> [javac]
> /home/abuild/rpmbuild/BUILD/libbluray-
> 1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:97:
> error: cannot find symbol
> [javac]             if (classDepth("sun.awt.AWTAutoShutdown") > 0) {
> [javac]                 ^
> [javac]   symbol:   method classDepth(String)
> [javac]   location: class BDJSecurityManager
> [javac]
> /home/abuild/rpmbuild/BUILD/libbluray-
> 1.0.2/src/libbluray/bdj/java/org/videolan/BDJSecurityManager.java:222
> :
> warning: [removal] checkSystemClipboardAccess() in SecurityManager
> has
> been deprecated and marked for removal
> [javac]     public void checkSystemClipboardAccess() {
> [javac]                 ^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] Note: Some input files use unchecked or unsafe operations.
> [javac] Note: Recompile with -Xlint:unchecked for details.
> [javac] 3 errors
> [javac] 7 warnings

There's very similar function in org.videolan.Logger, we can probably
use it.

Build time issues are just a tip of iceberg. Those are easy to detect
and fix. I'm more worried about Xlet compatibility, we need to run BD-J 
Xlets compiled over a decade ago.

> > This is due to the fact that some of the SecurityManager methods,
> deprecated since java 1.2, were finally removed. So, libbluray, as it
> is
> right now, will not work with jdk10 either, if built with whatever
> lower
> version that will allow it to be built. This will need a rethinking
> of
> the BDJSecurityManager.java all together and when one looks at the
> deprectation warnings, some other problems are just waiting for their
> own time.

Yes, there are always issues with new Java versions.

We need to hook to some Java "internal" interfaces to inject input,
redirect i/o and grab graphics output. We also need to be Java 1.4
compatible at Xlet side. If something important is removed, we need to
work around / re-implement it in libbluray.

> Cheers
> 
> Fridrich
> _______________________________________________
> libbluray-devel mailing list
> libbluray-devel at videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel