Clojure Q&A - Recent questions in java.data

clojure.java.data/from-java throws stack overflow

Mon, 10 Feb 2025 10:39:57 +0000

I use the following function to get scrollpoints from a client io.qdrant.client.QdrantClient

(def client ...) => io.qdrant.client.QdrantClient

(defn make-scroll-points [collection-name k v]
  (builder/to-java Points$ScrollPoints
                   Points$ScrollPoints$Builder
                   (Points$ScrollPoints/newBuilder)
                   {:collectionName collection-name
                    :filter (builder/to-java Points$Filter
                                             Points$Filter$Builder
                                             (Points$Filter/newBuilder)
                                             {:addMust (ConditionFactory/matchKeyword (name k) (str v))}
                                             {})
                    :limit 1
                    :withPayload (WithPayloadSelectorFactory/enable true)}
                   {}))

(def scroll-points (qdrant/make-scroll-points  <collection-name> :user "user-1"))

(def scrolled (.get (.scrollAsync client scroll-points)))

(bean scrolled)

works, but when i do

(clojure.java.data/from-java scrolled)

I get a stackoverflow error

clojure.java.data.builder fails with overloaded setter

Wed, 22 Jan 2025 20:27:39 +0000

Trying to run make-chat-model

(ns problem.problem
  (:require [clojure.java.data.builder :as builder])
  (:import (dev.langchain4j.model.openai OpenAiChatModel)
           (dev.langchain4j.model.openai OpenAiChatModel$OpenAiChatModelBuilder)))

(defn make-chat-model []
  (builder/to-java
    OpenAiChatModel 
    OpenAiChatModel$OpenAiChatModelBuilder
    (OpenAiChatModel/builder)
    {:baseUrl  "localhost"
     :apiKey (System/getenv "OPENAI_API_KEY")} {}))

fails with the following error

:#error {}
 :cause Duplicate setter found for :modelName in dev.langchain4j.model.openai.OpenAiChatModel$OpenAiChatModelBuilder class
 :via
 [{:type java.lang.IllegalArgumentException
   :message Duplicate setter found for :modelName in dev.langchain4j.model.openai.OpenAiChatModel$OpenAiChatModelBuilder class
   :at [clojure.java.data.builder$find_setters$fn__9041 invoke builder.clj 66]}]

The code is in the following repo: https://github.com/gavlooth/problem

Should `(clojure.java.data/from-java-deep Class {})` work?

Sun, 31 Dec 2023 11:17:16 +0000

(clojure.java.data/from-java-deep Class {}) throws StackOverflowError.

The docs don't say anything about this, but I'd like to see this case covered by java.data.

You can find a tiny example in https://github.com/henrik42/java.data-with-Class/tree/master

This shows the error.

clj -X main/this-call-throws
Execution error (StackOverflowError) at clojure.java.data/add-deep-getter-fn (data.clj:121).

As a workaround I'm using (defmethod j/from-java-deep Class [clazz _] {:class clazz}) -- but this is not really a solution since it does not even give you what (from-java-shallow Class {}) would give you.

clj -X main/this-call-works
(j/from-java-deep Class) ;=>  {:class java.lang.Class}

Using

(defmethod j/from-java-deep Class [clazz _] (j/from-java-shallow Class {}))

instead isn't much better because it's not a deep-copy either.

Please update log4j

Sun, 12 Dec 2021 23:28:11 +0000

I see you've upgraded the log4j dependency in the clojure/tools.logging.
Would do the same also for the clojure/java.data please? So that (among others) the seancorfield/next-jdbc which plenty of projects depend on can be upgraded too?
Thank you in advance

java.data should support creating Properties from a map

Wed, 13 Oct 2021 14:22:46 +0000

Some Java classes expect arguments of the type java.util.Properties, for example HikariCP. Currently I need to construct these manually:

{:dataSourceProperties
     (doto (java.util.Properties.)
       (.putAll {"socketTimeout" "30" }))}

it would be nice if I could instead just provide a map and it got converted to Properties automatically:

{:dataSourceProperties {"socketTimeout" "30" }}

Properties is a built-in JVM class used regularly to it seems fitting to have built-in support for it.

Adding something like this would suffice:

(defmethod j/to-java [java.util.Properties clojure.lang.APersistentMap] [_ props]
  (doto (java.util.Properties.) (.putAll props)))

java.util.Date should not be converted

Tue, 22 Jan 2019 11:24:56 +0000

(from-java (java.util.Date.)) returns

{:day 2, :date 22, :time 1548156165905, :month 0, :seconds 45, :year 119, :timezoneOffset 0, :hours 11, :minutes 22}

but it makes more sense not to convert date objects as they are effectively primitives within Clojure. Can submit PR for this if approved.

from-java on an object with Boolean attribute = false returns "bad" Booleans

Sun, 25 Feb 2018 15:50:29 +0000

Calling from-java on an object that as a Boolean attribute that is false can return boxed Booleans that are not Boolean/FALSE.
This results in a boolean that is equal to false, but results in the true path of if.

`
(def bool (:absolute (from-java (URI. ""))))

bool
=> false
(= bool false)
=> true
(if bool true false)
=> false
`

This leads to really confusing behavior.
As clojure won't change the behavior of if (https://dev.clojure.org/jira/browse/CLJ-1718) and we don't control the construction of the boolean, I think from-java should be aware of this problem and fix it.

This could be fixed by adding an extra method for Boolean that reconstructs the Boolean in the right way, though I'm not sure what the best way would look like.

from-java does not convert Boolean to clojure keyword

Tue, 02 Jan 2018 12:39:36 +0000

Given a class:

public class BoolTest {
    private Boolean aBoolean;
    private String aString;

    public Boolean isABoolean() {
        return aBoolean;
    }

    public void setABoolean(Boolean value) {
        this.aBoolean = value;
    }

    public String getAString() {
        return aString;
    }

    public void setAString(String aString) {
        this.aString = aString;
    }
}

Test:

(def example (BoolTest.))

(defn run-test []
  (do
    (-> example
      (.setABoolean true))
    (-> example
      (.setAString "something"))
    (from-java example)))

***** Actual:
(test/run-test) => {:AString "something"}

**** Expected:
(test/run-test) => {:AString "something" :ABoolean true}

incorrect org.clojure/java.data convert java.util.Date use getter and setter

Fri, 26 May 2017 03:15:29 +0000

in package org.clojure/java.data

(cjd/from-java (java.util.Date.)) will use setter and getter method of java.util.Date, which produce incorrect clojure object,

because java.util.Date is a basic class of java language, it's better keep "::do-not-convert".

so i add this class to ::do-not-convert classify.

to-java not working when setter takes Map as parameter

Wed, 14 Oct 2015 14:23:44 +0000

If I have the following class:

`
public class ClojureTestBean {

private java.util.Map foo;

public void setFoo(Map foo) {
    this.foo = foo;
}

public Map getFoo() {
    return foo;
}

}
`

And I run the following clojure:

`
(def bean-instance (ClojureTestBean.))
(. bean-instance setFoo {"bar" "baz"})

(def bean-instance-as-map (from-java bean-instance))

(def new-bean-instance (to-java ClojureTestBean bean-instance-as-map))
`

The final line throws a {{java.lang.InstantiationException: java.util.Map}} exception (full stack trace found below). It looks like there's a {{to-java}} method that, when it gets a {{APersistentMap}}, tries to create an instance of the type of the parameter which in this case is a {{Map}} interface, which of course cannot be instantiated.

I'm wondering why the {{APersistentMap}} wouldn't be passed in directly, as it implements the {{Map}} interface?

`
CompilerException java.lang.InstantiationException: java.util.Map, compiling:(scratchpad.clj:13:24)
java.lang.InstantiationException: java.util.Map, compiling:(scratchpad.clj:13:24)

at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3628)
at clojure.lang.Compiler$DefExpr.eval(Compiler.java:439)
at clojure.lang.Compiler.eval(Compiler.java:6787)
at clojure.lang.Compiler.load(Compiler.java:7227)
at user$eval1676.invoke(form-init2280240325964091253.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6782)
at clojure.lang.Compiler.eval(Compiler.java:6745)
at clojure.core$eval.invoke(core.clj:3081)
at clojure.main$repl$read_eval_print__7099$fn__7102.invoke(main.clj:240)
at clojure.main$repl$read_eval_print__7099.invoke(main.clj:240)
at clojure.main$repl$fn__7108.invoke(main.clj:258)
at clojure.main$repl.doInvoke(main.clj:258)
at clojure.lang.RestFn.invoke(RestFn.java:1523)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__609.invoke(interruptible_eval.clj:53)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invoke(core.clj:630)
at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1868)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke(interruptible_eval.clj:51)
at clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__651$fn__654.invoke(interruptible_eval.clj:183)
at clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__644.invoke(interruptible_eval.clj:152)
at clojure.lang.AFn.run(AFn.java:22)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

Caused by: java.lang.InstantiationException: java.util.Map

at java.lang.Class.newInstance(Class.java:359)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
at clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:313)
at clojure.java.data$fn__247.invoke(data.clj:95)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.java.data$make_setter_fn$fn__232.invoke(data.clj:55)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invoke(core.clj:630)
at clojure.java.data$fn__247.invoke(data.clj:101)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3623)

Translate - into camel casing in to-java

Fri, 17 Oct 2014 20:14:16 +0000

Currently, if a class has a setter like {{setMyThing}}, the hash must contain {{:myThing}} for {{to-java}} to call it.

It would be great is {{:my-thing}} could be used instead as it would look less Java-ish.

to-java not working on some setters

Wed, 09 Oct 2013 12:08:56 +0000

In this example the last test fails.

I have used org.codehause.mojo.rpm.Mapping(link: 1) as the example as this is where I discovered the bug.

(link: 1) http://mojo.codehaus.org/rpm-maven-plugin/apidocs/org/codehaus/mojo/rpm/Mapping.html

Tests:

(do
(use 'clojure.java.data

       'clojure.test)

(import '(link: org.codehaus.mojo.rpm Mapping))

(testing "setting normally"

(let (link: mapping (Mapping.))

	(.setConfiguration mapping "a value")
	(.setDirectory mapping "/tmp")

	(is (= (.getDirectory mapping) "/tmp"))
	(is (= (.getConfiguration mapping) "a value"))))

(testing "setting via java-data"

(let (link: mapping (to-java Mapping {:configuration "a value" :directory "/tmp"}))
  (is (= (.getDirectory mapping) "/tmp"))
  (is (= (.getConfiguration mapping) "a value")))))

Simplify use cases / split up to-java

Tue, 03 Sep 2013 16:56:11 +0000

Issues with a single compound to-java method

The common to-java implementation for (link: Object Map), hard codes:
- no constructor args
- setters with java bean convention
Often times, classes need special treatment during construction. E.g. if the constructor(s) take parameters, or the setters are non-standard.
The to-java method can be specialized to achive that, however, at this point one is bound to reimplementing (or pasting) parts from java.data source, since all the helpers in java.data are private.

Proposed Enhancements

API to call a bunch of setters a la carte
a well known keyword :java.data/constructor to pass constructor args
other functionality might be made public, if it's useful in its own right

Handle primitive types and arrays

Sat, 01 Oct 2011 18:05:12 +0000

Right now, there is no special handling for methods with primitive or array parameters.
This results in errors, when trying to use bean classes, that have such methods, with to-java and from-java.

The attached patch implements handling of primitives and arrays in the following manner:
- When the :default methods of from-java and to-java see an array type, they extend the multimethods for that array type.
Issue: Is Iterable the right interface to extend the multimethod to? Sequential also came to mind, but Iterable was used elsewhere.

Values that hit a numeric primitive slot (in to-java) are manually boxed, so they aren't passed as longs.