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

Doesn't work with Java 9 #206

Closed
shwangdev opened this issue Oct 19, 2017 · 26 comments
Closed

Doesn't work with Java 9 #206

shwangdev opened this issue Oct 19, 2017 · 26 comments
Labels
Milestone

Comments

@shwangdev
Copy link

clj-refactor.el and refactor-nrepl version information

cider/cider-nrepl "0.14.0" refactor-nrepl "2.3.1"

CIDER version information

;; CIDER 0.12.0snapshot (package: 20160331.421), nREPL 0.2.12
;; Clojure 1.8.0, Java 1.8.0_31

Leiningen or Boot version

Leiningen 2.8.0 on Java 9.0.1 Java HotSpot(TM) 64-Bit Server VM

Emacs version

Emacs 25.3.1

Operating system

MacOS

Darwin 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64

Error Message:
'''
$ lein repl
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by dynapath.defaults$eval380$fn__381 to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of dynapath.defaults$eval380$fn__381
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Java HotSpot(TM) 64-Bit Server VM warning: Unable to open cgroup memory limit file /sys/fs/cgroup/memory/memory.limit_in_bytes (No such file or directory)
WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: mranderson047.toolsanalyzerjvm.v0v6v9.toolsanalyzer.v0v6v7.clojure.tools.analyzer.utils, being replaced by: #'mranderson047.toolsanalyzerjvm.v0v6v9.toolsanalyzer.v0v6v7.clojure.tools.analyzer.utils/boolean?
WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: mranderson047.toolsanalyzerjvm.v0v6v9.toolsanalyzer.v0v6v7.clojure.tools.analyzer, being replaced by: #'mranderson047.toolsanalyzerjvm.v0v6v9.toolsanalyzer.v0v6v7.clojure.tools.analyzer.utils/boolean?
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by mranderson047.alembic.v0v3v3.dynapath.v0v2v5.dynapath.defaults$eval18085$fn__18086 to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of mranderson047.alembic.v0v3v3.dynapath.v0v2v5.dynapath.defaults$eval18085$fn__18086
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Error loading refactor-nrepl.middleware: clojure.lang.ExceptionInfo: Alembic can not manipulate specified ClassLoader. {:classloader #object[jdk.internal.loader.ClassLoaders$AppClassLoader 0x484b61fc "jdk.internal.loader.ClassLoaders$AppClassLoader@484b61fc"], :reason :not-addable-with-dynapath}, compiling:(mranderson047/alembic/v0v3v3/alembic/still.clj:65:1)
Exception in thread "main" java.lang.RuntimeException: Unable to resolve var: refactor-nrepl.middleware/wrap-refactor in this context, compiling:(/private/var/folders/bg/jpxx1rf134z369y0dmb5zt640000gn/T/form-init6665213846665153788.clj:1:8774)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6953)
at clojure.lang.Compiler.analyze(Compiler.java:6729)
at clojure.lang.Compiler.analyze(Compiler.java:6685)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3855)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6948)
at clojure.lang.Compiler.analyze(Compiler.java:6729)
at clojure.lang.Compiler.analyze(Compiler.java:6685)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3855)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6948)
at clojure.lang.Compiler.analyze(Compiler.java:6729)
at clojure.lang.Compiler.access$300(Compiler.java:38)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6324)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6946)
at clojure.lang.Compiler.analyze(Compiler.java:6729)
at clojure.lang.Compiler.analyze(Compiler.java:6685)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6056)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5428)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3993)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6944)
at clojure.lang.Compiler.analyze(Compiler.java:6729)
at clojure.lang.Compiler.eval(Compiler.java:7002)
at clojure.lang.Compiler.eval(Compiler.java:6995)
at clojure.lang.Compiler.eval(Compiler.java:6995)
at clojure.lang.Compiler.load(Compiler.java:7457)
at clojure.lang.Compiler.loadFile(Compiler.java:7395)
at clojure.main$load_script.invokeStatic(main.clj:277)
at clojure.main$init_opt.invokeStatic(main.clj:279)
at clojure.main$init_opt.invoke(main.clj:279)
at clojure.main$initialize.invokeStatic(main.clj:310)
at clojure.main$null_opt.invokeStatic(main.clj:344)
at clojure.main$null_opt.invoke(main.clj:341)
at clojure.main$main.invokeStatic(main.clj:423)
at clojure.main$main.doInvoke(main.clj:386)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:702)
at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: Unable to resolve var: refactor-nrepl.middleware/wrap-refactor in this context
at clojure.lang.Util.runtimeException(Util.java:221)
at clojure.lang.Compiler$TheVarExpr$Parser.parse(Compiler.java:716)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6946)
... 35 more
'''

@expez expez changed the title Unable to resolve var: refactor-nrepl.middleware/wrap-refactor in this context Doesn't work with Java 9 Oct 19, 2017
@expez
Copy link
Member

expez commented Oct 19, 2017

Hi,

most likely this is java 9 that's causing problems.

It's probably going to require some digging to find out what's wrong, but it looks like a problem with class-loader manipulation by Alembic.

If you have time, we'd love the help :)

@expez expez added the bug label Oct 19, 2017
@metacritical
Copy link

Uninstall Java 9, install java 8 version with minor version upwards of 121. i.e 152.
You can use brew cask to install java 8

brew cask install caskroom/versions/java8

@neverfox
Copy link

neverfox commented Dec 31, 2017

Any update here?

@bbatsov
Copy link
Member

bbatsov commented Jan 1, 2018

I see most deps were recently updated on 2.4-snapshot, so I guess you should try it out and see if it works with Java 9 (my guess is that it will work).

@benedekfazekas
Copy link
Member

should be fixed on latest snapshot from clojars. give it a try pls

@bitti
Copy link

bitti commented Jan 2, 2018

I'm using the latest snapshot from clojars (which seems to be 2.4.0-20171124.220250 as far as I can see: https://repo.clojars.org/refactor-nrepl/refactor-nrepl/2.4.0-SNAPSHOT) and the repl just starts fine for me. But if I try cljr-add-project-dependency I get this exception:

cljr--get-error-value: Error in nrepl-refactor: clojure.lang.Compiler$CompilerException: java.lang.ClassNotFoundException: sun.misc.Launcher, compiling:(mranderson048/alembic/v0v3v2/dynapath/v0v2v3/dynapath/defaults.clj:29:3)
 at clojure.lang.Compiler.analyzeSeq (Compiler.java:6875)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
[...skipped incredible long stacktrace...]

I see alembic was updated to 0.3.3 on 2.3.1 apparently because of Java 9 compatibility issues, even though the repl isn't even starting up for me on 2.3.1. I wonder why the older alembic version was kept on 2.4.0-SNAPSHOT. Is it an oversight? Might an update fix my problem?

I'm on Ubuntu Linux 16.04.03 LTS with GNU Emacs 25.1.1.

@benedekfazekas
Copy link
Member

hm... this seems to be an accidental downgrade in this commit 401f4f8

Ironacially part of a PR about upgrading dependencies :)

@dotemacs
Copy link
Contributor

dotemacs commented Jan 2, 2018

This commit was added by me.

What needs to be done to resolve this issue?

Use the vendored alembic: https://clojars.org/clojure-emacs/alembic at
[clojure-emacs/alembic "0.3.3"] ?

@benedekfazekas
Copy link
Member

benedekfazekas commented Jan 2, 2018

don't worry about that @dotemacs i was also reviewing that PR and did not spot this. I created a branch this afternoon, added java9 to travis and tried the forked 0.3.3 alembic. it fails unfortunately (see the latest travis build failure for jdk9 branch).

@bitti
Copy link

bitti commented Jan 3, 2018

So should I open a separate ticket for my issue, or wait and see what happens when you successfully integrated alembic 0.3.3? I guess the situation of working mit a forked alembic is also not ideal and you might want to merge its changes back into the original?

@benedekfazekas
Copy link
Member

I get the same error (as in the original report) on travis with java9 with the alembic update unfortunately. so I am either missing something here or there is still a compatibility issue with java9. working with the forked alembic is ok I guess I might need to work on it a bit more or ditch it actually

@benedekfazekas
Copy link
Member

@bitti hm.. I think my commits on jdk9 fixes the exception you are seeing but it still would not work with java9 so I guess this issue is fine for tracking java9 compatibility

@benedekfazekas
Copy link
Member

after digging into this a bit I see several problems with java9 compatibility

@jumarko
Copy link

jumarko commented Mar 22, 2018

@benedekfazekas If piggieback and http-kit require java.xml.bind, then the dependency should be added explicitly, e .g.

[javax.xml.bind/jaxb-api "2.3.0"]

@benedekfazekas
Copy link
Member

thx @jumarko bigger blunder is the first one tho I am afraid

@tirkarthi
Copy link

To add to this I can see 1.9 profile for testing using an older version of Clojurescript that causes issues with JDK 9 and can cause test case failure. The latest stable release Clojurescript 1.10 fixes this. Relevant JIRA issue : CLJS-2377

@tirkarthi
Copy link

With respect to http-kit the JDK 9 issue was resolved with the latest beta release . I have raised a PR to piggieback with the latest Clojurescript version but the tests fail due to some reason in the repl based tests. Piggieback PR : nrepl/piggieback#84

@SamirHafez
Copy link

What's the current state of this? I still cannot invoke cljr-add-project-dependency:

cljr--get-error-value: Error in nrepl-refactor:
clojure.lang.Compiler$CompilerException: java.lang.ClassNotFoundException:
sun.misc.Launcher, compiling:(mranderson048/alembic/v0v3v2/dynapath/v0v2v3/dynapath/defaults.clj:29:3)
[...]

@expez
Copy link
Member

expez commented Jun 7, 2018

@SamirHafez We need to replace alembic, with something else, to get hotloading to work in java9.

If you mostly care about adding dependencies you can do (setq cljr-hotload-dependencies nil) (in your .emacs) and just restart your repl when needed.

If you feel up to it @SamirHafez we'd love the help; none of us has as much time to work on this as we'd like.

@benedekfazekas
Copy link
Member

had a chat about this with some cider people lately, specially @SevereOverfl0w and it seems we need a classloader in the hierarchy which is modifiable. that is most likely outside of cljr concerns, so a fix could be to check if there is such a classloader available in the hierarchy and just disable the feature if not.

adding this classloader is perhaps cider but most likely nrepl's concern (nrepl is now a clojure-emacs project so there is hope)

but as @expez rightly said we have very little time to invest here nowadays unfortunately. wish it was otherwise...

@bbatsov
Copy link
Member

bbatsov commented Jul 23, 2018

I'll just mention here for completeness that the necessary changes were made in nrepl/nrepl#35

@mikebohdan
Copy link

mikebohdan commented Aug 6, 2018

I have the same issue while running refactor-nrepl 2.3.1 on Java 8, Clojure 1.9 and cider-nrepl 0.18.0.

java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

UPD
On latest 2.4.0-snapshot situation is the same

Error loading cider.nrepl.middleware.test: java.lang.RuntimeException: Invalid token: ::clojure.test/once-fixtures, compiling:(cider/nrepl/middleware/test.clj:129:57)
Exception in thread "main" java.lang.RuntimeException: Unable to resolve var: cider.nrepl.middleware.test/wrap-test in this context, compiling:(/private/var/folders/cf/7sy6jyxs5z3d_m3d9c_blsk40000gn/T/form-init2124100859504429900.clj:1:9693)

@jumarko
Copy link

jumarko commented Aug 7, 2018

@mikebohdan

I have the same issue

I don't know the details but it seems that you report Unable to resolve var: cider.nrepl.middleware.test/wrap-test issue but the original one was Unable to resolve var: refactor-nrepl.middleware/wrap-refactor

@bbatsov
Copy link
Member

bbatsov commented Aug 7, 2018

We've dropped alembic and deps hot-loading in f75441e, so this one is fixed.

For now, users can do this as a workaround http://nrepl.readthedocs.io/en/latest/usage/#hot-loading-dependencies

@bbatsov bbatsov closed this as completed Aug 7, 2018
@bbatsov
Copy link
Member

bbatsov commented Aug 7, 2018

@mikebohdan Only 2.4.0-SNAPSHOT is compatible with the latest cider-nrepl.

@benedekfazekas
Copy link
Member

new link for the hotload workaround: https://nrepl.org/nrepl/0.6.0/usage/misc.html#_hot_loading_dependencies

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.