[Cryptofacilities] CryptoFacilitiesDigest - Java 11 code fails in Java 8 environment

Seems like Java 11 code was introduced in CryptoFacilitiesDigest: https://github.com/knowm/XChange/blob/e28c9b066768dbb2a4800d7b8a067b503d73ae4f/xchange-cryptofacilities/src/main/java/org/knowm/xchange/cryptofacilities/service/CryptoFacilitiesDigest.java#L52

https://github.com/knowm/XChange/commit/6ddd2e3bd568fbf64bb80dc8c39a5c5c17a80ad7#diff-6ec4afdd46cac2fa3bfee1282876504ced1c0c5fd6258a7fc778786568c4e8db

It fails in Java 8 env.

XChange v5.0.8

error: java.net.URLDecoder.decode(Ljava/lang/String;Ljava/nio/charset/Charset;)Ljava/lang/String; 
java.lang.NoSuchMethodError: java.net.URLDecoder.decode(Ljava/lang/String;Ljava/nio/charset/Charset;)Ljava/lang/String;
	at org.knowm.xchange.cryptofacilities.service.CryptoFacilitiesDigest.digestParams(CryptoFacilitiesDigest.java:50)
	at si.mazi.rescu.Params.digestAll(Params.java:203)
	at si.mazi.rescu.RestInvocation.lambda$new$1(RestInvocation.java:93)
	at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
	at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1556)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
	at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
	at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
	at si.mazi.rescu.RestInvocation.<init>(RestInvocation.java:93)
	at si.mazi.rescu.RestInvocation.create(RestInvocation.java:139)
	at si.mazi.rescu.RestInvocationHandler.createInvocation(RestInvocationHandler.java:182)
	at si.mazi.rescu.RestInvocationHandler.invoke(RestInvocationHandler.java:110)
	at com.sun.proxy.$Proxy15.accounts(unknown)
	at org.knowm.xchange.cryptofacilities.service.CryptoFacilitiesAccountServiceRaw.getCryptoFacilitiesAccounts(CryptoFacilitiesAccountServiceRaw.java:24)

@andre77

[walec51]

As this issue illustrated at the moment we only ensure Java 8 bytecode compatibility - which means:

• you can import this library to a Java 8 project
• but it will always break in runtime when a method from Java 9 API or above is used and the underneath JRE does not support them

@timmolter as I understand your response Android despite requiring Java 8 bytecode provides many APIs from Java 9 an higher, yes?

If so then I’m sorry @sizmestiev but if your stuck with using Java 8 on the server then you must be already used to running old versions of unsupported libraries and components on it. There are many option available to you to remedy your situation like for example using containers and microservices if you want to use the latest version of Xchange. Android to me is the only valid reason for such extreme backward compatibility as Java 8 and as @timmolter stated this library in its current form can run on Android while leveraging newer APIs.

[walec51]

Because this library is used in Android, it needs to be Java 8 compatible. I recently ran into Android issues from a developer’s point of view with noncompliant Java code, and it was a pain in the butt.

if so then the Java 8 CI build must be restored - without it we wont detect which PRs use APIs that are from Java 9 and above

the Java versions mentioned in pom does not check for that - they only ensure bytecode compatibility