[libbluray-devel] BDFileSystem hook incompatibility with JRE 8

[Petri Hintukainen]

Hello,

to, 2018-04-12 kello 17:50 +0200, Hendrik Leppkes kirjoitti:
> Hey,
> 
> I've been debugging an issue with certain discs for a while now, and
> I
> could trace it all back to the hook of the FileSystem in java.io.File
> not working reliably on JRE 8. If I switch to JRE 7, everything
> immediately works fine.
> 
> The behavior is rather inconsistent, the hook manages to take over
> the
> FileSystem for some objects, but not for others - which is probably
> inline with the huge warnings all over the place to not mess with
> private static final fields.
> 
> Is this a known issue?
> Unfortunately I have not had any brilliant ideas how to approach this
> problem otherwise, and get the custom filesystem to work cleanly.

I've seen very similar random issues with relative paths and images in
the past. Those occured only in Windows with Java 8. I never found the
reason, any attempt to debug those made the issue to disappear.

What kind of files are those ? images ?

One possible cause could be if loading is deferred to JDK internal
thread before the path has been resolved. Such thread could have been
created outside of BD-J context. If Xlet somehow escapes BD-J sandbox,
it won't use our class loader anymore.

Another could be some kind of optimizations related to final field.

If it is sandboxing issue it can be fixed. To fix it we need to know
exactly how the file is loaded. Maybe our stack is missing some path,
and Xlet ends up using some incompatible Java RT classes (like nio).
Usually such issues are hard to debug, and require looking at the Xlet
code too.

If it is related to field being final we can't fix it easily. Rewriting
and overriding File class could help. That should allow full control
over filesystem. But it is not the simplest class in RT.
Anyway, it should be easy to test: I think you can simply copy File
class from Java RT you're using (to libbluray tree), and change
filesystem field to non-final and public.
That could also help debugging sandboxing issues, you can easily dump
stack traces from interesting points in File class.


The root of such problems is every new Java version is more
incompatible with J2ME 1.4. At some point we probably need to
fork/rewrite/encapsulate every class in RT libs. There are lot of
similar (and harder) issues with Java 9. I think modifying private /
final fields is not even possible with Java 9 / 10. That makes most of
existing compatibility hacks outdated.

Maybe easiest would be forking and adapting the classes from PhoneME or
JDK 1.4, but that could change libbluray license to GPL.

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