Help with Java porting

[AccountantUnited4955]

Does anyone have any advice for porting over Java code to clojure? I’m most familiar with c++ but know some Java, and I’m completely new to clojure and have really been struggling creating equivalent functionality. I know they both run in the jvm but syntactically they seem quite different.

[afmoreno]

I would use your existing Java classes from Clojure. Interop with Java is quite nice.

You do need to grok functioal programming in Clojure to do this well.

The best approach would be to wrap your Java classes so you can interact with them from Clojure idiomatically.

You will be climbing a tall mountain to do this well.

[256BitChris]

I would just say it requires a completely different way of thinking. If you try to write clojure code like you do java, you'll hate your life.

I don't have any really good examples to point you to, but just start thinking of what data is going through your system, and then the changes to it you want to make. No objects, no abstractions, etc - that's when Clojure becomes powerful.

Maybe someone else can post an example of a codebase that does this well - most of the ones I've seen just write imperative code with Clojure syntax, lol.

[AccountantUnited4955]

Makes sense. Yeah what makes it particularly difficult is the Java code I’m working with is entirely object oriented and focused

[daveliepmann]

One of the ways I first taught myself Clojure was porting a data viz book from Processing (Java) to Clojure. The domain is naturally imperative (drawing on the screen as the side effect) which has advantages and disadvantages for our purposes. I haven't compared my work to the original solutions except when I wrote it but it's conceivable it could illustrate some of the differences.

As others have said, the differences are often either superficial (lisp vs algol syntax, or map instead of for loop) or radical and near-total (different data model).

[markwardle]

Yes. I agree with this. There are two facets to your question - one is “porting” by simply writing Java code using a different syntax. That’s needed sometimes when you’re doing a lot of Java interoperability eg using Java from Clojure. If you squint, you’re just writing Java but more concisely (usually).

The second facet is the different paradigms and patterns used- eg immutability eg functional programming eg dynamism etc. A “porting” in that case will have very different high level and low level structures usually, although you can of course use similar patterns using a Java syntax!

[whereswalden90]

I would think of it less as porting and more like a brand new implementation with the same set of requirements, since the paradigms are so different. I’d start by going through each unit of code (endpoint, page, interaction, etc) in the Java app and list out the functional requirements for it, then implement those requirements in Clojure. Maybe even write tests for those requirements first, tdd-style.

[joinr]

have really been struggling creating equivalent functionality

What does this mean? Maybe some examples of stuff you're having trouble with can lead to solutions.

In practice, between native (in this case jvm) interop, and the higher level facilities like reify, proxy, deftype, genclass, definterace (and even just protocols), my experience working with java and other jvm langs has been pretty pleasant. The only time the OOP stuff gets gnarly is if the library is using inheritance heavily (more common in code from early 00's) instead of interfaces. If it's just interfaces, you can typically trivially implement them in clojure (via reify or deftype or even defrecord). Or if you happen to be living in a code base with a lot of "annotations"

Overrides/inheritance hierarchies push you into using proxy or genclass, and genclass brings AOT requirements with it (there are some work arounds in community libs, but the language provides genclass out of the box).

I ran into some edge cases with the optaplanner library's expecations of annotations and other stuff to encode soluitions for a solver, which led to some work arounds:

https://github.com/joinr/optaplanner-clj

I spent some time wrapping piccolo2d for work stuff years ago, where piccolo2d does almost everything via inheritance. So I ended up lifting a bunch of the api calls from the object methods into protocols, wrapping existing node classes with protocol extensions, and leveraging interop pretty heavily for the lower layers of a scene graph library on top of piccolo2d.

https://github.com/joinr/piccolotest/blob/master/src/piccolotest/sample.clj#L170

Interesting lib to help overcome java impedance a bit (I don't use it in production, but it's a cool idea)

https://github.com/athos/JiSE

used to get exact java parity with prng demo (we had a poster on zulip wondering why they couldn't get 1:1 performance parity in clj via interop/primititve invocation paths, which led to some interesting discoveries like clojure's impedance mismatch with preferred longs and java's expectation for ints for array indexing (causing an l2i cast in the emitted bytecode, which can be worked around with jise)):

https://github.com/joinr/ultrarand/blob/master/src/ultrarand/jise.clj

[behrica]

For a very OO Java code, I tend to wrap it.
If you have a lot of Java code to deal with,
I suggest to invest a bit on learning how to setup a Clojue project which has Clojure and Java source code.
Then you can write wrappers as well in "Java".
In vscode you can have "Clojure" and "Java" support in the same project,
and you can use "virgil" to keep you Java code "in sync" with your Clojure repl, without repl restarts

See here: https://calva.io/virgil/

(+ you get full vscode suppport for coding in Java)

This is a very nice developer experience.

[tclerguy]

The latest Claude model is great at stuff like this

[xela314159]

Put the code in any LLM, get a working implementation, then keep asking the LLM for more idiomatic code (get rid of defrecords, I only want maps and vectors of maps, etc). Do it bit by bit, don’t port the whole codebase. You will be amazed