-
Notifications
You must be signed in to change notification settings - Fork 69
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
Comments
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 :) |
Uninstall Java 9, install java 8 version with minor version upwards of 121. i.e 152. brew cask install caskroom/versions/java8 |
Any update here? |
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). |
should be fixed on latest snapshot from clojars. give it a try pls |
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
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. |
hm... this seems to be an accidental downgrade in this commit 401f4f8 Ironacially part of a PR about upgrading dependencies :) |
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 |
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 |
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? |
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 |
@bitti hm.. I think my commits on |
after digging into this a bit I see several problems with java9 compatibility
|
@benedekfazekas If piggieback and http-kit require java.xml.bind, then the dependency should be added explicitly, e .g.
|
thx @jumarko bigger blunder is the first one tho I am afraid |
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 |
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 |
What's the current state of this? I still cannot invoke
|
@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 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. |
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 but as @expez rightly said we have very little time to invest here nowadays unfortunately. wish it was otherwise... |
I'll just mention here for completeness that the necessary changes were made in nrepl/nrepl#35 |
I have the same issue while running refactor-nrepl 2.3.1 on Java 8, Clojure 1.9 and cider-nrepl 0.18.0.
UPD
|
I don't know the details but it seems that you report |
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 |
@mikebohdan Only 2.4.0-SNAPSHOT is compatible with the latest |
new link for the hotload workaround: https://nrepl.org/nrepl/0.6.0/usage/misc.html#_hot_loading_dependencies |
clj-refactor.el and refactor-nrepl version information
cider/cider-nrepl "0.14.0" refactor-nrepl "2.3.1"
CIDER version information
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
'''
The text was updated successfully, but these errors were encountered: