Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

java9 support #77

Closed
souenzzo opened this issue Oct 22, 2017 · 4 comments
Closed

java9 support #77

souenzzo opened this issue Oct 22, 2017 · 4 comments

Comments

@souenzzo
Copy link

souenzzo commented Oct 22, 2017

I'm trying to run my project with java9 and I'm getting

Error loading cemerick.piggieback: java.lang.ClassNotFoundException: javax.xml.bind.DatatypeConverter, compiling:(cljs/util.cljc:1:1)

Exception in thread "main" java.lang.RuntimeException: Unable to resolve var: cemerick.piggieback/wrap-cljs-repl in this context, compiling:(/tmp/form-init219680406953741838.clj:1:2325)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6875)
	at clojure.lang.Compiler.analyze(Compiler.java:6669)
	at clojure.lang.Compiler.analyze(Compiler.java:6625)
	at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3834)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6870)
	at clojure.lang.Compiler.analyze(Compiler.java:6669)
	at clojure.lang.Compiler.analyze(Compiler.java:6625)
	at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3834)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6870)
	at clojure.lang.Compiler.analyze(Compiler.java:6669)
	at clojure.lang.Compiler.access$300(Compiler.java:38)
	at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6269)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
	at clojure.lang.Compiler.analyze(Compiler.java:6669)
	at clojure.lang.Compiler.analyze(Compiler.java:6625)
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6001)
	at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5380)
	at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3972)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6866)
	at clojure.lang.Compiler.analyze(Compiler.java:6669)
	at clojure.lang.Compiler.eval(Compiler.java:6924)
	at clojure.lang.Compiler.eval(Compiler.java:6917)
	at clojure.lang.Compiler.load(Compiler.java:7379)
	at clojure.lang.Compiler.loadFile(Compiler.java:7317)
	at clojure.main$load_script.invokeStatic(main.clj:275)
	at clojure.main$init_opt.invokeStatic(main.clj:277)
	at clojure.main$init_opt.invoke(main.clj:277)
	at clojure.main$initialize.invokeStatic(main.clj:308)
	at clojure.main$null_opt.invokeStatic(main.clj:342)
	at clojure.main$null_opt.invoke(main.clj:339)
	at clojure.main$main.invokeStatic(main.clj:421)
	at clojure.main$main.doInvoke(main.clj:384)
	at clojure.lang.RestFn.invoke(RestFn.java:421)
	at clojure.lang.Var.invoke(Var.java:383)
	at clojure.lang.AFn.applyToHelper(AFn.java:156)
	at clojure.lang.Var.applyTo(Var.java:700)
	at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: Unable to resolve var: cemerick.piggieback/wrap-cljs-repl in this context
	at clojure.lang.Util.runtimeException(Util.java:221)
	at clojure.lang.Compiler$TheVarExpr$Parser.parse(Compiler.java:710)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
	... 36 more
No nREPL ack received

Some info:

  • Same error both 2.2.0 and 2.2.0-SNAPSHOT
  • Using :repl-options {:nrepl-middleware [cemerick.piggieback/wrap-cljs-repl]}
  • Clojure 1.8.0 + Clojurescript 1.9.908
  • Trying to get a REPL with lein.
    [edit]
  • JVM Arg: --add-modules java.xml.bind solves.
@tirkarthi
Copy link

Latest Clojurescript release 1.10 fixes JDK 9 compatibility issue caused by xml-bind. Relevant JIRA issue : https://dev.clojure.org/jira/browse/CLJS-2377 . Upgrading it might resolve the issue.

I don't know if it's different than #78

@plexus
Copy link
Contributor

plexus commented Nov 23, 2018

To summarize:

  • ClojureScript prior to r1.10.63 uses java.xml.bind.DataTypeConverter (removed here)
  • Since r.1.10.63 this has been replaced with java.util.Base64 CLJS-2377
  • On Java 9 java.xml.bind.* are deprecated, and you need to add --add-modules java.xml.bind to get access to them
  • On Java 11 java.xml.bind.* has been removed, and you need to add a dependency on java.xml.bind/jaxb-api 1
  • Piggieback pulls in ClojureScript 1.9, because we don't want to force people to use 1.10 (?) Bump Clojurescript for JDK 9 compatibility #84 (comment)
  • This means piggieback is currently broken on OpenJDK 11 because of this missing dependency
  • cider-nrepl runs its CI on Java 8 and Java 11, and the latter currently fails because of this missing dependency (e.g. travis log)

That last bit is my main concern at this point, I'd like to see the cider-nrepl tests go green again. Note that both piggieback and cider-nrepl check for Java 9 in their Makefile, and add the --add-modules option, but this will no longer work on Java 11. Piggieback currently tests Java 8 and 9, which is why the piggieback build is still green.

I'm not sure what the best way out of this is. I think any of these would do the trick.

  • explicitly require ClojureScript 1.10 in the cider-nrepl :test-cljs profile
  • require java.xml.bind/jaxb-api in the cider-nrepl :test-cljs profile
  • add java.xml.bind/jaxb-api as a dependency to piggieback
  • bump piggieback's ClojureScript version to 1.10 (as was suggested in Bump Clojurescript for JDK 9 compatibility #84)

Also note that pulling in java.xml.bind/jaxb-api would fix compatibility with Java 9 and upwards, so the --add-modules java.xml.bind would be able to go.

@shen-tian
Copy link
Contributor

There's two Java 9 issues and one PR around. But based on what I understand:

  • An official line is emerging that only the LTS Java versions are supported now. i.e. 8 and 11.
  • In 8, we don't have java.xml issues.
  • In 11, whatever is using piggiepack (which no longer has an explicit cljs dep) should either depend on Cljs 1.10+ OR have the jaxb-api dep. The problem is for downstream code to solve.
  • This issue is widely known beyond piggiepack, so not really this lib's cross to bear.

The CI is now down with the extra deps to ensure everything works as expected.

So can this (plus #78 #84) be closed?

@bbatsov
Copy link
Contributor

bbatsov commented Mar 31, 2019

Yeah, we can close this.

@bbatsov bbatsov closed this as completed Mar 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants