Open Refine opens with logo only when running on Java 16

[P3rCo]

To Reproduce

Steps to reproduce the behavior:

1. Click on open refine Application

Current Results

2. This window appears:

4. This page appears
5.

6.I have installed the embedded Java version:

7.I have run it as adminstrator same results.

8. Tried to run the batch file
9. Same results:
   
10. Tried firefox

Expected Behavior

Open Refine page appears

Screenshots

Versions

• Operating System: Edition Windows 10 Pro
  Version 20H2
  Installed on ‎17/‎03/‎2021
  OS build 19042.1165
  Experience Windows Feature Experience Pack 120.2212.3530.0

• Browser Version:
  

• JRE or JDK Version:

• Using embedded but:

• OpenRefine: 3.4.1

Datasets

Additional context

[P3rCo]

Thanks a lot for any help guys, really stumped.

[ghost]

Do you still have an environment variable in Windows set for JAVA_HOME ?
If so, can you try temporarily removing that and trying to launch OpenRefine again ?

[P3rCo]

Same result

System variables (there was a java home, deleted it)

[thadguidry]

Thanks for reporting this bug.

Right, I suspect that your Java 16 is still somewhere on your PATH.
Right now it seems we have an small issue with OpenRefine launching and not working correctly with Java 16.
Can you update your PATH and JAVA_HOME so that it using a JAVA version lower than 16?
Then OpenRefine should work.

[thadguidry]

Also, I've opened a separate issue #4108 for OpenRefine 3.5.1 where I'm seeing that if started with OpenRefine.exe, it does not respect JAVA_HOME any longer, but it does if refine.bat is used to launch.

[P3rCo]

Right,

Java version changed.
My G.

Right, so Java 16 bad, Java 18 ok?

[thadguidry]

@P3rCo I don't know yet what is going on with our 3.5.1 release and Java 16.
I myself have not compiled OpenRefine against Java 18 yet... so no idea, but you are welcome to try.
16 only reached GA on 2021/03/16
17 is expected on 2021/09/14

[ylan1]

@thadguidry
Thank you so much for all your help. After deleting jdk 16 from the PATH and changing JAVA_HOME to C:\Program Files\Java\jdk-14.0.2, I was able to run OR. However, when I tried to run it with openrefine.exe, it did not work, but with .bat, it worked. But I got the following output:

Is this an expected behavior? Anyway, I am so happy that it is working now.

[thadguidry]

@ylan1 Expected (for now)

[ylan1]

@thadguidry
I see. Thank you!

[VladimirAlexiev]

@thadguidry @wetneb Confirming it doesn't work on Java 16.
Java version:

openjdk version "16.0.2" 2021-07-20
OpenJDK Runtime Environment Temurin-16.0.2+7 (build 16.0.2+7)
OpenJDK 64-Bit Server VM Temurin-16.0.2+7 (build 16.0.2+7, mixed mode, sharing)

Error in browser console:

Uncaught ReferenceError: Refine is not defined
    at (index):68

OpenRefine version: 3.5.1beta.
This also happened on an earlier version.

Console messages:

>refine.bat
Using refine.ini for configuration
Getting Java Version...
openjdk version "16.0.2" 2021-07-20
OpenJDK Runtime Environment Temurin-16.0.2+7 (build 16.0.2+7)
OpenJDK 64-Bit Server VM Temurin-16.0.2+7 (build 16.0.2+7, mixed mode, sharing)
=====================================================
find: ‘version’: No such file or directory
Getting Free Ram...
log4j:WARN No appenders could be found for logger (org.eclipse.jetty.util.log).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/prog/openrefine/webapp/WEB-INF/lib/slf4j-log4j12-1.7.30.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/prog/openrefine/server/target/lib/slf4j-log4j12-1.7.30.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
15:02:08.171 [                   refine] Starting OpenRefine 3.5-beta1 [1b9907e]... (0ms)
15:02:08.178 [                   refine] initializing FileProjectManager with dir (7ms)
15:02:08.181 [                   refine] C:\Users\vladimir.alexiev.000\AppData\Roaming\OpenRefine (3ms)

[VladimirAlexiev]

hi @thadguidry what's the ETA on this issue? Should I downgrade Java?

[thadguidry]

@VladimirAlexiev Don't use >= Java 16 for now. No idea on ETA...maybe next Spring? probably.

[wetneb]

I agree this should be pretty high priority. Hopefully 3.5 should fix this.

[itplainedge]

Same problem. Had installed Minecraft Java which wanted a newer version of JDK which I installed 16.1. I previously only had Java Runtime 1.8. After I uninstalled JDK 16.1 I got it to work (both versions with java embedded and without since I had JRE 1.8 installed already)

[wetneb]

I've had a look at this and it's a significant chunk of work, which could involve upgrading quite a few libraries. In the process we can introduce all sorts of bugs / incompatibilities which will require extensive testing. So I don't think we should do this for 3.5, otherwise this will delay this release even more.

[thadguidry]

Agree, so where do we do the work? In 4.0 branch? Or a 3.6 branch with expectations of 3.6 also including SDC work and other new features? I personally think that 4.0 might be better for all if we focus dev efforts all together into that branch and will make the merge nightmare much more reduced. My thoughts are that 4.0 can be our next target and with the mindset we release maybe 1 year from now with Java 16 compatible, SDC ext builtin, and working PLL and tuning.

[wetneb]

I need to do more research to find out what the problem actually is, so yes, 3.6 or 4.0 depending on the scale of the problem.

[wetneb]

The blocker for this is Java 16 compatibility of the Rhino Javascript engine. We are waiting for 1.7.14 to be released (mozilla/rhino#966).
There might be other blockers though!

[wetneb]

Note that Spark is not compatible with Java 16 either. This should not be a blocker to release the 4.0 branch since we will not be running on Spark by default (but users who want to rely on this functionality will need Java 8 or 11).

[carlosame]

The blocker for this is Java 16 compatibility of the Rhino Javascript engine.

I see that this project is using the rhino-runtime artifact. Unfortunately, that artifact contains packages which are also present in the main Rhino jar, which according to MVNRepository is carried as a direct dependency by at least 58 open source projects and therefore may end being in your modulepath as a transitive dependency. In that case, you'd be experiencing a "split packages" problem.

If that is the case (just guessing), and until the packaging of the Rhino project is modified (as part of a full modularisation that I have suggested, see mozilla/rhino#1075 (comment)), you could switch to the main rhino artifact as a workaround.

[wetneb]

Thanks for chiming in @carlosame.

I am a bit puzzled, I did not realize OpenRefine depended on rhino directly. Our web framework "butterfly" does rely on it (depending on rhino, not rhino-runtime), but OpenRefine does not use it directly as far as I know. So ideally we would delete this dependency altogether! Also, mvn dependency:analyze agrees with me.

And it seems to run fine without it. Really puzzling.

Anyway, I do not understand modular compilation as well as you, but I do not think modular compilation is the source of the problem here: what is blocking is the "illegal reflexive accesses" that we have been warned about for a long time now. Upgrading Butterfly's dependency to Rhino to the latest release candidate does solve the problem.

[wetneb]

I have opened #4314 and #4315 to fix this spurious dependency.

[carlosame]

Upgrading Butterfly's dependency to Rhino to the latest release candidate does solve the problem.

That's good to know :-)

There is a pending PR with reflective access fixes (related to issues with protected fields and methods) which may be included in the final Rhino 1.7.14.

[jkjkjkjkjk]

Seems to be same problem with Java 17 (no surprises)

.

[wetneb]

@nikhilp3 may I ask why you unpinned this?

[nikhilp3]

Sorry @wetneb must've been on accident