
Clojure & Java Interop - DanielRibeiro
http://blog.jayfields.com/2011/12/clojure-java-interop.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+jayfields%2FmjKQ+%28Jay+Fields%27+Thoughts%29
======
_sh
While modern JVM languages leverage Java to overcome the 'library problem',
the traffic tends to be one-way. So while there are 'clojurely' ways to call
Java libraries, calling Clojure from Java is ugly and non-idiomatic, despite
what the article claims. How does one even call Scala from Clojure?

Presuming that, for the most part, developers migrate from Java to a different
JVM language, then inevitably these languages will fragment code written for
the JVM, devaluing the very foundation used to hoist the languages into
usefulness in the first place. The tower of Babel will rise higher with
competing idiomatic implementations of various libraries. This is not a bad
thing--rather it _has_ to be this way because introducing new language
features (such as STM in Clojure's case) demands it. We're living in a gold
rush on Java to mine it for its libraries. After this will come a period of
settlement as each JVM language builds its own community, with civic
structures that perform the same duties, but look different, in every town
square.

~~~
arohner
Calling Clojure from Java is ugly, but calling Clojure from JRuby is quite
pleasant, and I'm pretty sure a nice Clojure library could be written for
calling JRuby from Clojure.

Calling Clojure from Java is difficult because Java is inflexible more than
some inherent weakness in the "bootstrap on a host VM" strategy.

I've written a library to call Clojure from JRuby. It's about 100 lines, and
took me an afternoon. I assume the situation is similar all high level JVM
languages.

Given all the above, I agree that the JVM languages will fragment somewhat,
but to a lesser degree than you seem to think. If there are any really killer
app libraries in one language, it won't be too hard to integrate them into the
other languages.

------
edsrzf
Clojure and Java interop works and that's great. What's really interesting
about this situation is that there's one guy committing code in a _completely
different language from everyone else_. Not only that, but it's a language
that most would consider "weird". How well is that received by the rest of the
team?

Is anyone else picking up Clojure or is it "that one guy's crazy code that no
one can understand"? I think we've all seen latter situation even when
everyone's coding in the same language and it's a huge red flag.

I'm all for new and different languages seeing business use, but doing it this
way seems potentially harmful. But maybe it was a huge success here; I'd love
to hear more about it.

~~~
JayFields
Since you asked...

There's only 2 of us, and the other guy also wanted to learn Clojure. His
response to my statement was: "That's part of the reason I want you on the
team, we need to advance some of the tech on the project."

Also, Clojure has been in use at DRW for over 3 years, so adding it to another
project wasn't actually that big of a deal.

I know all that context wasn't in the article, so I think your questions are
on point - but, I think that info isn't really on topic for the article, which
is why I left it out.

~~~
edsrzf
Thanks! I'm totally fine with the fact that you left it out of the article.
The little bit of a story you did share just made me curious.

------
lemming
This is interesting, and in general Clojure interop with Java is really nice.
For me the biggest pain point comes when you are working with a Java
framework, where you generally have to extend Java classes (abstract classes,
often), and that gets pretty unwieldy. In general, I think, Clojure often
tries to be too dynamic for what you generally want in this case, or at least
what I did. For programming Android or IntelliJ plugins (which is what I tried
to do) I'd prefer a mechanism to write the code with Clojure but generate
"normal" (i.e. non-dynamic) bytecode AOT, like Kawa does.

~~~
arohner
You can do that, with gen-class:

<http://clojure.org/compilation>

The result is a completely "normal" non-dynamic java class. There's still a
dependency on clojure.jar though.

~~~
lemming
It's not exactly a "normal" class IIRC - I believe each method is actually a
class and method calls from the gen-class'ed class are delegated to them. This
is to maintain the ability to replace these methods dynamically but it would
be nice to be able to state that I don't want that behaviour. gen-class is a
little odd to use, too. Again, it works but is just a little funky compared to
the rest of the interop.

------
ryandvm
Wow, he must be a hell of a developer to overcome the enormous red flag of
saying "I want to do all future development in language X".

~~~
JayFields
While I completely agree that what I said would be a red-flag in the wrong
context, this was more a case of - I believe Clojure is a better tool for the
job and I don't want to join the team if we're going to be stuck with Java. My
statement wasn't about wanting to do future development with a specific
language, it was about wanting to use the best tool for the job. We actually
use Clojure, Java, Bash, Ruby, web (HTML+JS+CSS), and C#...

------
mark_l_watson
Great writeup. I also prefer coding in Clojure and JRuby rather than in Java.
While interop is important, I have just invested in a large effort in
converting some of my existing Java (and bits of Common Lisp) code to Clojure.
I am hoping to build a business around the new codebase and I decided that it
was worth the effort doing a cleanup and standardize on one language so it
will be easier to add new features.

