m: clojure@googlegroups.com on behalf of Alex
Miller
Sent: Friday, June 21, 2019 1:53:43 PM
To: clojure@googlegroups.com
Subject: Re: Calling Java from Clojure
I just don’t understand why you would introduce aot or gen-class at all if you
didn’t have to, which is one of the benefits of using the Cl
In that case, I would try to isolate those gen-classes into as small a box
as possible and make an artifact for just those.
On Fri, Jun 21, 2019 at 4:58 PM Didier wrote:
> Oh, not when you don't have too. I mean, you can always hand write a class
> in Java and have it call into Clojure. That's
Oh, not when you don't have too. I mean, you can always hand write a class in
Java and have it call into Clojure. That's effectively gen-class but done
manually. Otherwise, I favour the Clojure Java API.
But some code base are already using gen-class, and some people do use
gen-class.
t of AOT, IMO.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
> From: clojure@googlegroups.com on behalf of Didier
>
> Se
: Thursday, June 20, 2019 9:13:40 PM
To: Clojure
Subject: Re: Calling Java from Clojure
Option #1 and #3 are very much the same, just that Option #3 creates a Java
layer on top, instead of having everything coupled to the Clojure Java APIs
directly.
When you go with Option #2, you do not h
Interesting about impl-ns, I'll have to look into that. If so, it would greatly
simplify it all.
In my experience, if you only keep the gen-class .class, and delete everything
else, it all works without issues. If you are actually doing AOT, not for the
purpose of gen-class, I wouldn't
With AOT, you generally shouldn't ever exclude part of the AOT'ed code.
Most problems with AOT'ed code stem from having AOT'ed code call into
non-AOT'ed code, so anything "downstream" should also be AOT'ed.
On Fri, Jun 21, 2019 at 10:01 AM eglue wrote:
> This is a good clarification.
>
> I
This is a good clarification.
I found that when I tried to exclude some AOT stuff from the jar you can
get into a situation where Clojure will dynamically produce a class that is
already statically-produced at the root classloader and then you'll hit
ClassPathExceptions when you try to pass
Instead of deleting class files from a jar, you can use the :impl-ns option
on gen-class to stop transitive AOT. (gen-class makes a class file, but
AOT does not reach the impl-ns.) I don't remember seeing this in the
manual, but I don't know why else impl-ns would exist...
On Friday, June
Option #1 and #3 are very much the same, just that Option #3 creates a Java
layer on top, instead of having everything coupled to the Clojure Java APIs
directly.
When you go with Option #2, you do not have to AOT everything, but AOT is
transitive. So as you AOT the gen class, all code it
Depends on what you seek an example of. The cfj interop example provides
1-line Clojure implementations of the features the Java program consumes,
and 1 line is plenty to demonstrate the interop. On the other hand, those
1-liners are not an example of significant work you'd much rather do in
I understand it. And the approach seems promising and powerful. But the
example seems to me not too successful. And I drew your attention to this
fact in the hope of seeing a more convincing example. Thank you.
вторник, 18 июня 2019 г., 0:33:23 UTC+3 пользователь Alex Miller написал:
>
> Yes,
Yes, the whole point of this approach is to define the interface in Java and
the implementation in Clojure.
> On Jun 17, 2019, at 5:07 PM, ru wrote:
>
> core.clj defines only names "getTimestamp" and "getName", but meaning of
> these names defined in Support.java. For example, that
core.clj defines only names "getTimestamp" and "getName", but meaning of
these names defined in Support.java. For example, that "getTimestamp" means
result of a new java.util.Date.
понедельник, 17 июня 2019 г., 23:35:30 UTC+3 пользователь Alex Miller
написал:
>
> No, there is a bit of Java
No, there is a bit of Java code just to load the Clojure
code, but then it’s Clojure after that (the entity record impl).
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts
Excuse me, please, may be this is a naive question. As I understand, we
want to call Clojure from Java when we want to use advantages of
implementation of some functionality in Clojure. But, in this example I see
implementation of the functionallity in Java. Am I right?
понедельник, 10 июня
Nice, this looks very handy. Thanks!
Alan
On Wednesday, June 12, 2019 at 12:12:01 AM UTC-7, henrik42 wrote:
>
> I hacked just that a few days ago to support Java development at work:
> https://github.com/henrik42/deeto Not released yet but could be a starter
> in that direction.
> Henrik
>
--
I hacked just that a few days ago to support Java development at work:
https://github.com/henrik42/deeto Not released yet but could be a starter
in that direction.
Henrik
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send
Maybe this is too old school but wouldn’t a dynamic proxy help here? E.g.
java.lang.reflect.InvocationHandler & java.lang.reflect.Proxy.
Clearly you’d be relying on reflection but if your interface usage is large
grained enough the overhead wouldn’t be too bad.
--
You received this message
If you're willing to use Spring you can create Clojure-based Spring Beans
[1] and let Spring inject (autowire) them into your Java-based
Spring-Beans. And if you like you could use Spring just as a factory that
you invoke. I would still define interfaces (that you want to use from
Java) in
> I find the glue code is actually small in practice (I've done a couple of
real systems this way). This particular example is a little weird because
it's just making a domain object, but generally you're writing the glue to
provide a factory method for a facade. Below the facade, the Clojure
On Mon, Jun 10, 2019 at 12:04 AM eglue wrote:
> This is great, Alex, thanks. (Sorry, I deleted from underneath you and
> reposted to fix the title before I saw your reply...)
>
> The latter option, writing interfaces and classes in Java and calling w/
> the glue code is a great option.
>
>
This is great, Alex, thanks. (Sorry, I deleted from underneath you and
reposted to fix the title before I saw your reply...)
The latter option, writing interfaces and classes in Java and calling w/
the glue code is a great option.
However one big motivator for people moving from Java to langs
Oops, this should have be titled "Calling Clojure from Java" ... the
interop with Clojure calling Java is obviously well-worn and solid.
On Sunday, June 9, 2019 at 9:53:56 PM UTC-5, eglue wrote:
>
> I've been stalking Clojure for a while but now doing it professionally
> full-time (woo hoo!).
>
Looks like the title for this is backwards if I understand the intent,
should be calling Clojure from Java, right?
Java code is going to invoke methods on classes (that's all it knows how to
do). You have several options:
1) Use the Clojure Java API to invoke the Clojure runtime - here you're
Thanks for the help! I found and corrected a few more errors. You can
see the final result with documentation, at http://gist.github.com/354147
.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
Hi-- I'm trying to write a GUI-based Java program from within Clojure,
and I'm using an interesting library called Piccolo2D (http://
www.piccolo2d.org). The worldwide intersection of Clojure and
Piccolo2D is probably *me*, but I'm hoping that someone here can point
me in the right direction.
I'm
Here's my best attempt so far:
--
(ns piccoloHello
(:gen-class)
(:import (edu.umd.cs.piccolo PCanvas PNode PLayer)
(edu.umd.cs.piccolo.nodes PText)
(edu.umd.cs.piccolox PFrame)))
(defn create-frame
Creates the main PFrame
On 2 April 2010 15:00, Kevin ke...@kelleysoft.com wrote:
Here's my best attempt so far:
--
(ns piccoloHello
(:gen-class)
(:import (edu.umd.cs.piccolo PCanvas PNode PLayer)
(edu.umd.cs.piccolo.nodes PText)
(edu.umd.cs.piccolox
29 matches
Mail list logo
