<< Back to previous view

[JDATA-1] Handle primitive types and arrays Created: 01/Oct/11  Updated: 04/Oct/11

Status: Open
Project: java.data
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Herwig Hochleitner Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File java.data-primitive-array-support.patch    
Patch: Code and Test

 Description   

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.


 Comments   
Comment by Cosmin Stejerean [ 04/Oct/11 7:35 AM ]

Committed in https://github.com/clojure/java.data/commit/487db7420ae07ca4b527b38c39064d3b139ce78d





[JDATA-3] Simplify use cases / split up to-java Created: 03/Sep/13  Updated: 03/Sep/13

Status: Open
Project: java.data
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Herwig Hochleitner Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Issues with a single compound to-java method

The common to-java implementation for [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





[JDATA-4] to-java not working on some setters Created: 09/Oct/13  Updated: 09/Oct/13

Status: Open
Project: java.data
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Peter Gillard-Moss Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

clojure 1.5.1
org.clojure/java.data 0.1.1



 Description   

In this example the last test fails.

I have used org.codehause.mojo.rpm.Mapping[1] as the example as this is where I discovered the bug.

[1] http://mojo.codehaus.org/rpm-maven-plugin/apidocs/org/codehaus/mojo/rpm/Mapping.html

Tests:

(do
(use 'clojure.java.data
'clojure.test)
(import '[org.codehaus.mojo.rpm Mapping])

(testing "setting normally"

(let [mapping (Mapping.)]
(.setConfiguration mapping "a value")
(.setDirectory mapping "/tmp")

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

(testing "setting via java-data"
(let [mapping (to-java Mapping {:configuration "a value" :directory "/tmp"})]
(is (= (.getDirectory mapping) "/tmp"))
(is (= (.getConfiguration mapping) "a value")))))






[JDATA-5] Translate - into camel casing in to-java Created: 17/Oct/14  Updated: 17/Oct/14

Status: Open
Project: java.data
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: David Dossot Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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.






[JDATA-6] to-java not working when setter takes Map as parameter Created: 14/Oct/15  Updated: 14/Oct/15

Status: Open
Project: java.data
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Roy Truelove Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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)





[JDATA-8] incorrect org.clojure/java.data convert java.util.Date use getter and setter Created: 25/May/17  Updated: 25/May/17

Status: Open
Project: java.data
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: chenyunxing Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-add-java.util.Date-to-do-not-convert.patch    
Patch: Code and Test

 Description   

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.






[JDATA-9] from-java does not convert Boolean to clojure keyword Created: 02/Jan/18  Updated: 02/Jan/18

Status: Open
Project: java.data
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Nishitha Ningegowda Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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}





Generated at Thu Jan 18 02:29:17 CST 2018 using JIRA 4.4#649-r158309.