Schedulix v2.9 compilation fail using Java 11

54 views
Skip to first unread message

Yauheni Savitski

unread,
Jan 17, 2022, 1:02:26 AM1/17/22
to schedulix
Hello,

I wanted to know if compilation of schedulix sources (version 2.9) could be done using Java 11?

Actually, I tried to use several options and each time I had error like "the package javax.xml.bind does not exist". As I know this package has been removed from the jdk11. To avoid this I have to install jdk 8 and use it only for schedulix compilation Yauheni Savitski, Best regards

Ronald Jeninga

unread,
Jan 17, 2022, 5:59:27 AM1/17/22
to schedulix
Hi Yauheni,

some time ago I've tried the same, with the identical result.
This means that either the networking layer has been removed entirely (unless you pay for it, I guess), or it has been changed in a way that it is backward incompatible.
So far I didn't find the time to investigate the matter.

Compiling the source with Java 8 (you could just as well extract it from an rpm; that would "save" you the hassle of installing Java 8) would give you compiled code.
But this compiled code probably won't run with Java 11, because essential classes are missing. (They weren't found at compile time).

The bottom line is: I'll have to investigate this, but it is possible that Oracle stripped the freely available Java distribution, removing essential elements of the networking library.
In that case, Java 11 is not an option.
If they've just changed the entire networking structure (for whatever reason), we'll have to migrate the code to Java 11.
Needless to say that either possibility is a PITA.

If anyone feels motivated to investigate this more closely, I would greatly appreciate that.

Best regards,

Ronald

Ronald Jeninga

unread,
Feb 22, 2022, 7:03:00 AM2/22/22
to schedulix
Hi Yauheni,

today I've found the time to have a closer look at th issue.
It turns out that Oracle doesn't distribute the EE extensions for free any more.
Unluckily the javax.something classes are part of them.

Hence we'll have to find a replacement for those classes.
Oracle most certainly won't revert the decision, which means that we are currently stuck at Java 8.
But so far I didn't find a good replacement.
The issue is that we at least need  javax.net.ssl in order to support TLS connections.
And we need javax.xml.bind.DatatypeConverter for some (character encoding, I think) conversions.

Everything else isn't that important (I think) and can somehow be eliminated, replaced or discarded.

As soon as I know more, I'll drop another message here.

Best regards,

Ronald

Ronald Jeninga

unread,
May 24, 2022, 6:26:21 AM5/24/22
to schedulix
Hi Yauheni,

today I managed to make real progress on this issue.
It turned out that things aren't as bad as I thought.

After the following few changes, I was able to compile the system:

diff --git a/src/server/parser/SSOConnect.java b/src/server/parser/SSOConnect.java
index 47ddb03..2ac7d05 100644
--- a/src/server/parser/SSOConnect.java
+++ b/src/server/parser/SSOConnect.java
@@ -28,7 +28,8 @@ package de.independit.scheduler.server.parser;
 import java.io.*;
 import java.util.*;
 import java.lang.*;
-import javax.xml.bind.DatatypeConverter;
+import java.util.Base64;
+
 
 import de.independit.scheduler.server.*;
 import de.independit.scheduler.server.util.*;
@@ -89,11 +90,11 @@ public class SSOConnect extends Connect
                        provider = (WindowsAuthProviderImpl)(sysEnv.cEnv.SSOInfo.get(PROVIDER));
                }
                try {
-                       byteToken = DatatypeConverter.parseBase64Binary(token);
+                       byteToken = Base64.getDecoder().decode(token);
                        serverContext = provider.acceptSecurityToken("server-connection", byteToken, "Negotiate");
                        byteToken = serverContext.getToken();
                        if (byteToken != null)
-                               token = DatatypeConverter.printBase64Binary(byteToken);
+                               token = Base64.getEncoder().encodeToString(byteToken);
                        else
                                token = "null";
 
diff --git a/src/shell/SDMSServerConnection.java b/src/shell/SDMSServerConnection.java
index c3848db..11cbc3c 100644
--- a/src/shell/SDMSServerConnection.java
+++ b/src/shell/SDMSServerConnection.java
@@ -32,7 +32,7 @@ import java.lang.*;
 import java.net.*;
 import javax.net.ssl.*;
 import java.security.*;
-import javax.xml.bind.DatatypeConverter;
+import java.util.Base64;
 
 import java.nio.charset.Charset;
 
@@ -256,7 +256,7 @@ public class SDMSServerConnection
                                try {
                                        clientContext = WindowsSecurityContextImpl.getCurrent( "Negotiate", spn );
                                        byteToken = clientContext.getToken();
-                                       strToken = DatatypeConverter.printBase64Binary(byteToken);
+                                       strToken = Base64.getEncoder().encodeToString(byteToken);
                                } catch (Throwable e) {
                                        clientContext.dispose();
                                        result = new SDMSOutput();
@@ -280,12 +280,12 @@ public class SDMSServerConnection
                                int idxToken = result.container.indexForName (null, "TOKEN");
                                Vector v_data = (Vector)(result.container.dataset.get(0));
                                strToken = (String)(v_data.get(idxToken));
-                               byteToken = DatatypeConverter.parseBase64Binary(strToken);
+                               byteToken = Base64.getDecoder().decode(strToken);
                                try {
                                        SecBufferDesc continueToken = new SecBufferDesc(Sspi.SECBUFFER_TOKEN, byteToken);
                                        clientContext.initialize(clientContext.getHandle(), continueToken, spn);
                                        byteToken = clientContext.getToken();
-                                       strToken = DatatypeConverter.printBase64Binary(byteToken);
+                                       strToken = Base64.getEncoder().encodeToString(byteToken);
                                } catch (Throwable e) {
                                        result = new SDMSOutput();
                                        result.setError(new SDMSOutputError("Desktop-0006", "Exception getting clientToken:" + e.toString() + " !"));


Now it compiles, we can start testing. And obviously the only thing that could cause problems is the single sign-on functionality, at least in theory.
It is, of course, always possible that something else has changed between Java 8 and Java 11 (which is the Java release I've been using here).

But at least we've made a big step into the right direction.

Best regards,

Ronald
Reply all
Reply to author
Forward
0 new messages