Hello list, I'm working on getting ABCL + the Jetty <http://www.eclipse.org/jetty> web server + SLIME working together as a development environment for Google App Engine web apps[1]. This seems to be what the Clojure people have done <http://www.hackers-with-attitude.com/2009/08/intertactive-programming-with-clojure.html>: run your own Jetty server & SWANK server, then load the GAE JARs to provide the same emulated services as the GAE SDK's development server. I've been working through the "Embedding Jetty" tutorials[2] and making reasonable progress (with help from Mark Evenson and others on #abcl - thanks Mark!). I've been doing it all in Lisp (so far), making my own servlet classes using JNEW-RUNTIME-CLASS. Ideally I'd like to make an ABCL library equivalent to (a subset of) Compojure <https://github.com/weavejester/compojure> (and appengine-magic <https://github.com/gcv/appengine-magic>). Some of the tutorials have code like: context.addServlet(HelloServlet.class, "/"); Is it possible to get Class objects for Java classes I've made with JNEW-RUNTIME-CLASS (or indeed for any other Java class)? I've been using "raw" JCLASS & JMETHOD etc. calls to experience just how painful that really is, but I'm apprehensive about using JSS <http://abcl.org/trac/browser/trunk/abcl/contrib/jss/README.markdown> and paying the runtime dynamic dispatch penalty, given that on GAE time is money. Something more like a SLIME plug-in that looked up & cached classes, methods & fields at editing time (perhaps also parsing Java expressions) and generated "statically typed" code would be nice (possibly using code from e.g. JDEE <http://emacswiki.org/emacs/JavaDevelopmentEnvironment> and/or CEDET <http://cedet.sourceforge.net/>) - has anyone else thought about this? Cheers, John :^P (hoping HTML email to the list isn't a social faux pas) [1] I have a page of initial notes and links at https://johnp.net/jpkb/wiki/AbclOnGae [2] https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty, http://www.eclipse.org/jetty/documentation/current/embedding-jetty.html -- John Pallister john@johnp.net john@synchromesh.com
On 07 Jul 2015, at 22:24, John Pallister <john@synchromesh.com> wrote:
[…]
Some of the tutorials have code like:
context.addServlet(HelloServlet.class, "/");
Is it possible to get Class objects for Java classes I've made with JNEW-RUNTIME-CLASS (or indeed for any other Java class)?
Since all Java references to non-primitive types descend from java.lang.Object, one may always get a reference to the class object by [calling the “getClass()” method][1]. [1]: http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#getClass--
I've been using "raw" JCLASS & JMETHOD etc. calls to experience just how painful that really is, but I'm apprehensive about using JSS and paying the runtime dynamic dispatch penalty, given that on GAE time is money. Something more like a SLIME plug-in that looked up & cached classes, methods & fields at editing time (perhaps also parsing Java expressions) and generated "statically typed" code would be nice (possibly using code from e.g. JDEE and/or CEDET) - has anyone else thought about this?
I wouldn’t necessarily be afraid of the “penalty" for using JSS, or at least, I might benchmark the difference in performance before shying away from JSS at the outset. JSS [already creates a cache of all classes that on the classpath][2]. JSS:JAVA-CLASS-METHOD-NAMES provides a listing of all methods of a class, which is not currently cached, but could be. Extending this to java fields would be useful. I would welcome patches to JSS which extends these introspection facilities as the basis for the tooling you wish to build. [2]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/invoke.lisp#L299 [3]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/invoke.lisp#L469
Hi Mark, Thanks for pointing out getClass(), I should've thought of that myself... And thanks for the JSS information, I'll have a look into that. On 8 July 2015 at 08:27, Mark Evenson <evenson@panix.com> wrote:
On 07 Jul 2015, at 22:24, John Pallister <john@synchromesh.com> wrote:
[…]
Some of the tutorials have code like:
context.addServlet(HelloServlet.class, "/");
Is it possible to get Class objects for Java classes I've made with JNEW-RUNTIME-CLASS (or indeed for any other Java class)?
Since all Java references to non-primitive types descend from java.lang.Object, one may always get a reference to the class object by [calling the “getClass()” method][1].
[1]: http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#getClass--
I've been using "raw" JCLASS & JMETHOD etc. calls to experience just how painful that really is, but I'm apprehensive about using JSS and paying the runtime dynamic dispatch penalty, given that on GAE time is money. Something more like a SLIME plug-in that looked up & cached classes, methods & fields at editing time (perhaps also parsing Java expressions) and generated "statically typed" code would be nice (possibly using code from e.g. JDEE and/or CEDET) - has anyone else thought about this?
I wouldn’t necessarily be afraid of the “penalty" for using JSS, or at least, I might benchmark the difference in performance before shying away from JSS at the outset.
JSS [already creates a cache of all classes that on the classpath][2]. JSS:JAVA-CLASS-METHOD-NAMES provides a listing of all methods of a class, which is not currently cached, but could be. Extending this to java fields would be useful. I would welcome patches to JSS which extends these introspection facilities as the basis for the tooling you wish to build.
[2]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/invoke.lisp#L299 [3]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/invoke.lisp#L469
There are also specific forms for certain kinds of optimization. An examples is with-constant-signature In the following, the method lookup for #"Foo" and #"Bar" are looked up based on the signature of the arguments for the first call of the function in the body. Thereafter the methods are called directly. Doesn't work if you might have different types returned, but in many cases of optimization one doesn't. (let ((baz something)) (with-constant-signature ((foo "Foo") (bar "Bar")) (dotimes (i 1000) (foo (bar baz))))) I haven't looked at dynamic dispatch in recent Java but it is possible that the implementation might move to that if it performs better. Alan On Wed, Jul 8, 2015 at 7:42 AM John Pallister <john@synchromesh.com> wrote:
Hi Mark,
Thanks for pointing out getClass(), I should've thought of that myself...
And thanks for the JSS information, I'll have a look into that.
On 8 July 2015 at 08:27, Mark Evenson <evenson@panix.com> wrote:
On 07 Jul 2015, at 22:24, John Pallister <john@synchromesh.com> wrote:
[…]
Some of the tutorials have code like:
context.addServlet(HelloServlet.class, "/");
Is it possible to get Class objects for Java classes I've made with JNEW-RUNTIME-CLASS (or indeed for any other Java class)?
Since all Java references to non-primitive types descend from java.lang.Object, one may always get a reference to the class object by [calling the “getClass()” method][1].
[1]: http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#getClass--
I've been using "raw" JCLASS & JMETHOD etc. calls to experience just how painful that really is, but I'm apprehensive about using JSS and paying the runtime dynamic dispatch penalty, given that on GAE time is money. Something more like a SLIME plug-in that looked up & cached classes, methods & fields at editing time (perhaps also parsing Java expressions) and generated "statically typed" code would be nice (possibly using code from e.g. JDEE and/or CEDET) - has anyone else thought about this?
I wouldn’t necessarily be afraid of the “penalty" for using JSS, or at least, I might benchmark the difference in performance before shying away from JSS at the outset.
JSS [already creates a cache of all classes that on the classpath][2]. JSS:JAVA-CLASS-METHOD-NAMES provides a listing of all methods of a class, which is not currently cached, but could be. Extending this to java fields would be useful. I would welcome patches to JSS which extends these introspection facilities as the basis for the tooling you wish to build.
[2]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/invoke.lisp#L299 [3]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/invoke.lisp#L469
participants (3)
-
Alan Ruttenberg -
John Pallister -
Mark Evenson