WebTorrent not working due to JRE/JDK version-conflicts

[forenta]

• Windows 11 21H2
• BiglyBT 3.2.00/4
  Java 1.8.0_351 (64 bit) Oracle Corporation
  c:\program files\java\jre1.8.0_351

I apologize for asking the question at Github - however, since the website is not accessible atm (at least from my device?), I don't know how else to approach the community - and I'm not sure wether it's a question or a feature request.

When trying to distribute videos from PeerTube via WebTorrent (ws/wss), the connection fails with the following error message:

Plugin failed java.lang.UnsupportedClassVersionError: dev/onvoid/webrtc/PeerConnectionFactory has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

So, to get it run, I uninstalled Oracle JRE 8 aka 52 and installed OpenJDK 19 aka... eh... 63? Anyway, WebTorrent worked pretty fine with this, but other applications I use did not start anymore, requesting JRE 8 and nothing else. So I re-installed JRE 8, the other applications were working again, but WebTorrent is broken again.

Is there a way to point BiglyBT to the OpenJDK-binaries instead of the Oracle JRE´s?

[ferdnyc]

Posting BiglyBT questions

since the website is not accessible atm (at least from my device?), I don't know how else to approach the community

I'm not aware of any other way, really -- at least, not any official resources.

Though (@parg) maybe it would be worth enabling GitHub Discussions on the repo, to provide an alternative resource more geared to asking/answering questions instead of reporting bugs / requesting features?

The actual Java compatibility issue

So... by default, the Windows installer downloads a Java runtime inside of the BiglyBT install directory (at C:\Program Files\BiglyBT\jre\ unless paths are customized) for its private use, and will then run under that.

I'm guessing your installation is using C:\Program Files\java\... because it was already installed prior to installing BiglyBT.

But BiglyBT's private JRE is Oracle 1.8.0_202, which seems like it would have exactly the same issue with the PeerConnectionFactory class.

If that's the case, then the real issue is that the plugin is mispackaged, since it (apparently) contains compiled classes that aren't compatible with Java 1.8.0. Correcting that is the real fix for this.

But in the meantime, here's one thing you could try, though I'm well aware how annoyingly convoluted it is. You could:

1. Uninstall BiglyBT
2. Uninstall C:\Program Files\java\jre1.8.0_351\
3. Install BiglyBT again, letting it install the private C:\Program Files\BiglyBT\jre\ runtime.
4. Reinstall C:\Program Files\java\jre1.8.0_351\
5. If the compatibility issue doesn't occur with the WebTorrent plugin when running under C:\Program Files\BiglyBT\jre\, great! But if it does, since BiglyBT's Java runtime is now isolated there, you're then free to try upgrading that install to a Java 11, 17, or 19 implementation. That way, you avoid breaking your C:\Program Files\java\jre1.8.0_351\ install those other programs require.

(Upgrading the private JRE would hopefully just be a matter of downloading a newer installer and pointing it to C:\Program Files\BiglyBT\jre\ as the install directory. Though, if the installer skips that option and automatically goes into upgrade mode for the C:\Program Files\java\ path, you may have to launch it from the command line with options that direct it to C:\Program Files\BiglyBT\jre\ instead. (I'm assuming a Java runtime installer takes some sort of flags to that effect, most Windows installers do if you poke around a bit. ...I'd check on that myself, but currently I'm finding java.com unreachable, oddly enough.)

[ferdnyc]

OK, now that java.com is loading for me... never mind that upgrade stuff above, since there don't appear to be any Windows JRE installers for versions newer than Java 8.

But I can confirm that downloading the 64-bit JDK 17 offline installer, installing it to the default C:\Program Files\Java\jdk-17.0.5\ location, and then removing C:\Program Files\BiglyBT\jre\ will cause BiglyBT to automatically switch over to running under Java 17.

That's without having a JRE 8 installed systemwide. If C:\Program Files\java\jre1.8.0_351 is also present the behavior might be different. But the BiglyBT.exe launcher supports an environment variable EXE4J_JAVA_HOME that can be used to explicitly set the java runtime path, if necessary to get it launching under the right version.

Oh, hey, here's a question: What version of the WebTorrent plugin are you having this issue with, @forenta?

I ask because, when I downloaded it from https://plugins.biglybt.com/ I ended up with azwebtorrent-win32_1.3.2.biglybt which installs version 1.3.2. But when BiglyBT launched under Java 17, it automatically started downloading version 1.4.1.

Whatever version you're on, it might be worth trying the other one to see if the same issue is present. (In particular, if 1.4.1 is the one causing you issues, you could try downgrading to 1.3.2 by manual download and install-from-file. Perhaps it's the 1.4.1 build that requires a newer runtime.)

[forenta]

Oh, hey, here's a question: What version of the WebTorrent plugin are you having this issue with, @forenta?

1.4.1

I ask because, when I downloaded it from https://plugins.biglybt.com/ I ended up with azwebtorrent-win32_1.3.2.biglybt which installs version 1.3.2. But when BiglyBT launched under Java 17, it automatically started downloading version 1.4.1.

Whatever version you're on, it might be worth trying the other one to see if the same issue is present. (In particular, if 1.4.1 is the one causing you issues, you could try downgrading to 1.3.2 by manual download and install-from-file. Perhaps it's the 1.4.1 build that requires a newer runtime.)

I just downgraded to the 1.3.2 x86 and indeed it's working fine. Is there a way to disable auto-update for a single BiglyBT-plugin? And @parg are you aware of the JRE-issue?

[ferdnyc]

@forenta

Not only is @parg aware, but the version history for 1.4.1 reads, I now see:

    1.4.1: Updated WebRTC to 0.6.0.
    1.4.0: Java 11+ Only; Switched to WebRTC local implementation, browser implementation still available via config.

So, version 1.4.0+ are expected to be incompatible with Java 8. And there's actually a field in the plugin properties, plugin.jdk.min_version (for 1.3.2 it's set to 1.7), which I guess explains why, in my own testing, BiglyBT didn't update the plugin to 1.4.1 until the first time I ran it under Java 17.

So I guess the real question is, how did you end up with 1.4.1 if you're running BiglyBT under JRE 1.8.0? It should've been prevented from updating. (And that should prevent it from auto-updating, assuming that check is working correctly. If it's not, then that's the real bug here, I guess.)

It doesn't appear, from a quick skim of the code, that there's any way to freeze a plugin version and prevent it checking for updates. It's possible I missed something, if not then adding a plugin.frozen property that disables update checking for that plugin seems like a reasonable suggestion.

(Though it doesn't change the fact that there's already a JDK version check that's supposed to prevent WebTorrent 1.4.x from being installed under Java 8. If that's broken we should figure out how and why, manual freezing would just be a workaround.)

[ferdnyc]

The other thing, I guess, is that if BiglyBT launches under a JRE version that's lower than the plugin.jdk.min_version for any of its installed plugins, it should probably display a message to that effect and disable the plugin for that run. Currently AFAICT that's only an update-time check, when it should probably be a runtime check. The JDK version can fluctuate in both directions from one run to the next.

Right now an installed plugin that's not compatible with the JRE version of the current BiglyBT instance still attempts to run, leading to breakage like what you originally experienced.

[ferdnyc]

@parg: Hmmm. I think there may be something broken, but on the plugin-server side.

This is the plugin-lookup URL generated by Win32 BiglyBT running under the installer-downloaded private JRE 1.8.0 install, in response to a click on the appropriate "Install" button @ https://plugins.biglybt.com/:

https://plugins.biglybt.com/update/pluginlist3.php?plugin=azwebtorrent&version=3.2.0.0&app=BiglyBT&os=Windows+10&osv=10.0&arch=amd64&ui=az3&java=1.8.0_202&swt_platform=win32&swt_version=4942&epids=aercm%3Aazutp%3Amldht%3A&ver_azwebtorrent=0.0

It produces this plugin listing:

azwebtorrent.name=WebTorrent Support
azwebtorrent.author=Parg
azwebtorrent.version=1.4.1
azwebtorrent.dl_link=https://files.biglybt.com/plugins/azwebtorrent-win64_1.4.1.zip
azwebtorrent.src_link=https://files.biglybt.com/plugins/azwebtorrent-win64_1.4.1.zip
azwebtorrent.description=Provides support for WebTorrent peers within BiglyBT.<br>See <a href="http://wiki.biglybt.com/w/WebTorrent/">http://wiki.biglybt.com/w/WebTorrent</a> for more information.<br>
azwebtorrent.comment=1.4.1: Updated WebRTC to 0.6.0.<br>1.4.0: Java 11+ Only; Switched to WebRTC local implementation, browser implementation still available via config.<br>1.3.2: Update browser to 71.0.3578.98.<br>1.3: Rework.<br>1.1: Seems the tracker protocol has changed.<br>1.0: Minor fixes.<br>0.6: Added tracker; fixes.<br>0.5: Added some proxy recovery.<br>0.3: Fixes and tidy up.<br>0.2: Initial version.<br>

And then proceeds to download WebTorrent 1.4.1 despite it not being compatible with JRE 1.8.0. Should the plugin service be offering 1.4.1 to a client that reports java=1.8.0_202 in the request?

[ferdnyc]

The plugin does "fail to install" in BiglyBT, with this log in the install window (so I'm still not sure how @forenta ended up with 1.4.1 actually installed under Java 8):

Downloading: [http://version.biglybt.com/biglybt-files/plugins/azwebtorrent-win64_1.4.1.zip.torrent: torrent,https://files.biglybt.com/plugins/azwebtorrent-win64_1.4.1.zip,https://files.biglybt.com/plugins/azwebtorrent-win64_1.4.1.zip]
Downloading: plugins_azwebtorrent-win64_1.4.1.zip
Torrent download complete
Installing plugin 'azwebtorrent/WebTorrent Support', version 1.4.1
Data verification stage complete
Plugin initialising, please wait...
Version 1.4.1 of plugin 'azwebtorrent/WebTorrent Support' failed to install - Plugin azwebtorrent requires Java version 1.11 or higher

But, it seems to me like things should never even get that far. Instead of offering a plugin that fails to install, shouldn't the server respond with a listing for WebTorrent 1.3.2 when the JRE version is lower than 1.11?

[ferdnyc]

Whoa. This is freaky. If I change that plugin lookup URL from this:

https://plugins.biglybt.com/update/pluginlist3.php?plugin=azwebtorrent&version=3.2.0.0&app=BiglyBT&os=Windows+10&osv=10.0&arch=amd64&ui=az3&java=1.8.0_202&swt_platform=win32&swt_version=4942&epids=aercm%3Aazutp%3Amldht%3A&ver_azwebtorrent=0.0

to this:

https://plugins.biglybt.com/update/pluginlist3.php?plugin=azwebtorrent

The service switches to offering me WebTorrent 1.3.2 instead of 1.4.1!

Something's definitely broken there.

[ferdnyc]

Related: #2660

Though the approach taken there was upgrading the JRE. We know that works, @forenta said as much. But it doesn't change the fact that 1.4.1 isn't compatible with the default -- and Oracle-recommended -- JRE version in Windows. JRE 1.8.0 is even the version the BiglyBT Windows installer will auto-download when needed.

So there's a presumptive supermajority of Windows clients running under Java 8. Those clients should probably either stick with the 1.3.2 version, or refuse to even attempt downloading 1.4.1. All the necessary information is available to determine that it's incompatible, without actually having to download it first.

[forenta]

So I guess the real question is, how did you end up with 1.4.1 if you're running BiglyBT under JRE 1.8.0? It should've been prevented from updating. (And that should prevent it from auto-updating, assuming that check is working correctly. If it's not, then that's the real bug here, I guess.)

Obviously. 🤷‍♂️

[ferdnyc]

@forenta

Aye, I saw the same thing in my own testing. Itz b0rkd!

Hopefully @parg will be around soon, and more-hopefully he'll be able to look into the PHP side of things, because the server appears to be doing The Wrong Thing™ in very nearly every case!

[parg]

The plugin update stuff isn't currently able to differentiate plugin versions based on the Java version the client has.

I dropped the ball on the webtorrent plugin somewhat. Initially it used an separate Chromium browser instance to proxy the WebRTC through, that was pretty crap. So I switched to using https://github.com/devopvoid/webrtc-java which was a lot better but I burnt a lot of time arsing around with it and lost momentum.

[ferdnyc]

The plugin update stuff isn't currently able to differentiate plugin versions based on the Java version the client has.

Hmm. Too bad, since the server is even sent that info in the request.

The thing that most confused me, though, was what I discovered about the server responses:

Whoa. This is freaky. If I change that plugin lookup URL from this:

https://plugins.biglybt.com/update/pluginlist3.php?plugin=azwebtorrent&version=3.2.0.0&app=BiglyBT&os=Windows+10&osv=10.0&arch=amd64&ui=az3&java=1.8.0_202&swt_platform=win32&swt_version=4942&epids=aercm%3Aazutp%3Amldht%3A&ver_azwebtorrent=0.0

to this:

https://plugins.biglybt.com/update/pluginlist3.php?plugin=azwebtorrent

The service switches to offering me WebTorrent 1.3.2 instead of 1.4.1!

...What's that all about? I could understand if the page was just always serving 1.4.1, but after a fashion it's apparently smarter than that. But why would removing all of the system configuration parameters cause it to fall back to 1.3.2, when it doesn't do that in cases where the parameters indicate that it should?

[parg]

shit code (PHP...)?

[ferdnyc]

Hmm. That checks out!

[ferdnyc]

@parg (Did you happen to see my #2779, btw? On that topic...)

[parg]

I did, I don't think it will happen as I'm not sure I want that crappy code public (security through obscurity and all that)

[ferdnyc]

I'd feel a little better if you had "security" in air-quotes there, but understood. 😉