-
Notifications
You must be signed in to change notification settings - Fork 13
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
fatal error #2
Comments
Looks like this is due to leiningen's compilation of java classes on my On Saturday, March 30, 2013, Karsten Schmidt wrote:
|
Should be fixed in 0.1.1, released just a second ago. |
++thanks for looking into this, alas even though the original error has gone, it's still defunkt when attempting to use it (with 0.1.1): user=> (use 'no.disassemble) Does this all depend on Java 7 or the Oracle JVM by any chance? (only wondering because of the ClassFormatException...) Sorry, Gary! |
Ha, I don't think it's anything specific to your jvm version. I appreciate you checking it out, though. The library itself is very simple. There's a HashMap returned by the getter (no.disassemble.NoDisassemble/getClasses) in the java class.
|
right here: https://github.com/gtrak/no.disassemble/blob/master/lein-nodisassemble/src/lein_nodisassemble/plugin.clj#L20 this is automatically adding the nodissasemble dependency, then grabbing the path to the maven jar and throwing it into the -javaagent commmand line parameter. This can be done manually, but it's a pain. |
I originally developed it on Ubuntu on jdk7, I just tried it on a macos machine with java 1.6.0_43 and it's working fine. |
I think I've figured it out. Leiningen does only spawn a second VM (with |
Ah, interesting. Since there's no project map, this isn't really a bug? On Mon, May 5, 2014 at 6:01 PM, Christoffer Sawicki <
|
Even project-less Leiningen invocations have a project map, but without the I don't know if this is how Leiningen should work. I'll try to reach @technomancy. |
Probably best to provide a default value for |
Burden on lein or me? Not sure I understand. On Monday, May 5, 2014, Phil Hagelberg [email protected] wrote:
|
I don't think it's necessarily reasonable to require all Leiningen |
@technomancy: I wonder about this: When I run
@gtrak meant that the plugin relies on |
@qerub Oh right; sure. Yes, we shouldn't spawn a new JVM when running outside a project; that would be very slow. The |
I should mention you could construct a profile that could act as a dummy app and let you spin up repls in any directory without a project if you didn't mind the slowdown. In :fakeproject {:root "/tmp"
:eval-in :subprocess
:dependencies [[org.clojure/clojure "1.6.0"]
[org.clojure/tools.nrepl "0.2.3"]]} Then run |
Hi Gary, just tried giving this a spin, added
[lein-nodisassemble "0.1.0"]
dependency to :plugins in profiles.clj, then doinglein repl
:Retrieving nodisassemble/nodisassemble/0.1.0/nodisassemble-0.1.0.jar from clojars
Exception in thread "main" java.lang.UnsupportedClassVersionError: no/disassemble/NoDisassemble : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:280)
at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:338)
FATAL ERROR in native method: processing of -javaagent failed
Exception in thread "Thread-3" clojure.lang.ExceptionInfo: Subprocess failed {:exit-code 134}
at clojure.core$ex_info.invoke(core.clj:4327)
at leiningen.core.eval$fn__2648.invoke(eval.clj:214)
at clojure.lang.MultiFn.invoke(MultiFn.java:231)
at leiningen.core.eval$eval_in_project.invoke(eval.clj:283)
at leiningen.repl$start_server.invoke(repl.clj:104)
at leiningen.repl$server$fn__6100.invoke(repl.clj:172)
at clojure.lang.AFn.applyToHelper(AFn.java:159)
at clojure.lang.AFn.applyTo(AFn.java:151)
at clojure.core$apply.invoke(core.clj:617)
at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1788)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
at clojure.core$apply.invoke(core.clj:621)
at clojure.core$bound_fn_STAR_$fn__4102.doInvoke(core.clj:1810)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:680)
OSX 10.7.4
java version "1.6.0_43"
Java(TM) SE Runtime Environment (build 1.6.0_43-b01-447-11M4203)
Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01-447, mixed mode)
The text was updated successfully, but these errors were encountered: