On Aug 26, 2015, at 11:19 AM, Phillip Lord <phillip.l...@russet.org.uk> wrote:
> Paul Landes <lan...@mailc.net> writes: > >> On Aug 26, 2015, at 9:25 AM, Phillip Lord <phillip.l...@russet.org.uk> wrote: >> >>> Paul Landes <lan...@mailc.net> writes: >>> At the moment, I am concerned about how the build tool should be >>> launched. Maven, for example, is quite tricky to launch from within a >>> running JVM. So, I am not clear where, for example, "compile" >>> functionality should go -- JDEE as is (via an external process) or >>> jdee-live (via direct JVM invocation). >>> >> >> This is where it gets complicated. The compilation (generation of classes) >> can >> be done via maven in the running JVM process, but then using the generated >> .class files become a mess regardless of the language used on top of the JVM >> because it is a JVM class loading issue itself. Class loaders are hung on to >> (technically only as long as the class has a reference count but I've seen >> this not to be the case) and old versions of classes linger. Classes >> referenced across loaders create signature and no class def exceptions etc. > > Indeed, this is a risk. Although I am not entirely convinced that this > is caused by actually compiling the classes, merely that they have been > recompiled which potentially will cause all the issues that you mention. > > At the moment I tend toward thinking that the build tool interaction > should be out-of-band of nREPL and the JVM, simply because maven has no > decent API. But then, for example, how do I get the source paths? I think from maven (see more reasons below). Have you seen maven shell? If used, need not be literally from the command line, but I assume they've done the tricky work and provide an interface that should be easy to find based on what the REPL (maven shell REPL) is using. https://github.com/jdillon/mvnsh > The other possibility is to use lisp to query the JVM, and then the JVM > decide how to answer this question. For a maven based project, it could > invoke maven, to get the effective pom, parse it, extract the data. But > for a leiningen based project (i.e. likely to be a mixed java/clj > project), it could just ask leiningen direct. > >> This is why I wanted to find a way to use the Java source itself (not >> the .class file with reflection/introspection) for all class >> generation, wizard etc code JDEE currently uses beanshell for. Clojure >> seems to do a good job of handling this, but I'm not sure what they do >> with old versions of classes for functions/files that get recompiled. >> That said, they're going directly for Clojure to byte code so it's a >> little different. I started to look at Clojure's dynamic class loader >> but got lost in the weeds and no documentation made it more difficult. > > Ironically, I had a quick peak at the JDEE source and discovered that it > actually includes a DynamicClassLoader that is supposed to reload from > file every time. Yes, the beanshell dynamic class loader, which loads byte codes generated by the ASM library. > Clojure, you are right, has to handle this because every function > compiles to a class and a lisp without the ability to re-eval functions > would be daft. The old versions should hang around while they are > needed, hence insanity like this... > > They are supposed to be accessible for GC as you say. Right, and I'm saying even when nulling out the variable function bindings they'll still hang around because the JVM loaded the class and despite the GC running won't get rid of it. It lives forever in perm space. Maybe this was just a bug on the JVM I was using at the time, but this was fairly recent. > My strategy for dealing with this was to use Vinyasa > (https://github.com/zcaudate/vinyasa) which has a "reimport" > functionality. I've already gone down this route and had no luck with it reloading classes as it should. I emailed the author and said it was a known bug with the current (at the time) version of Clojure but didn't have a lot of time to go back and fix it. That's where I left it after failed attempts to use Clojure's dynamic class loader directly (which is what vinyasa in turn uses). This was about 6 - 8 months ago and things change and my memory has been known to fail. > Use of Java source, I agree, I can see the advantages. But set against > this is dealing with the issues of when the Java source is wrong. When the Java source is wrong the parsing API should know where and why and then point to the issue. This gives us fly compile for "free" if we get it working. > > >>> Incidentally, I was thinking of renaming jdee-live again to "jive" just >>> for shortness. >>> >> >> Not sure that's a great idea. > Even "jve" is fine, but "jive" _could_/_might_ be perceived as less than PC in the United States. > I'm just worried about secondary files "jdee-live.el" is fine. But > "jdee-live-maven". Fun discussion. Regards, Paul ------------------------------------------------------------------------------ _______________________________________________ jdee-devel mailing list jdee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jdee-devel
