| Issue 33: | The library does not cope with simple java types | |
| 2 people starred this issue and may be notified of changes. | Back to list |
What steps will reproduce the problem?
1. add a class to testdomain:
package com.google.code.liquidform.testdomain;
import javax.persistence.Entity;
@Entity
public class Employee {
private int number;
private String name;
private double salary;
public String getName() {
return name;
}
public int getNumber() {
return number;
}
public double getSalary() {
return salary;
}
public void setName(String name) {
this.name = name;
}
public void setNumber(int number) {
this.number = number;
}
public void setSalary(double salary) {
this.salary = salary;
}
}
2. Add the test:
@Test
public void testWhetherSimpleTypesSupported() {
Employee e = alias(Employee.class, "e");
assertEquals("select e.number, e.name, e.salary", select(e.getNumber(),
e.getName(), e.getSalary()));
}
3. run the test
What is the expected output? What do you see instead?
java.lang.UnsupportedOperationException: Can't create object of type int.
This may happen if you forgot to annotate a persistent class with @Entity
at
com.google.code.liquidform.internal.FrameworkObjectFactory.makeNew(FrameworkObjectFactory.java:81)
at
com.google.code.liquidform.internal.PropertyAccessRecordingInvocationHandler.intercept(PropertyAccessRecordingInvocationHandler.java:66)
at
com.google.code.liquidform.testdomain.Employee$$EnhancerByCGLIB$$5968818f.getNumber(<generated>)
at
com.google.code.liquidform.itest.LiquidFormIntegrationTest.testIfTypesSupported(LiquidFormIntegrationTest.java:66)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
at
org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
at
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at
org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at
org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66)
at
org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
at
org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
What version of the product are you using? On what operating system?
Please provide any additional information below.
Dec 21, 2008
#1
koval...@gmail.com
Dec 22, 2008
Indeed this is a limitation of LIQUidFORM and is currently labeled (in our minds at least) as "won't fix". I need to update the documentation with current limitations, but in the meantime if you can change your model to use big Integers, I recommend you do so. If on the other hand you can't but have an idea of how LIQUidFORM could still be useful in those cases, any idea is welcome.
Status:
Accepted
Labels: -Priority-Medium Priority-Low
Dec 22, 2008
Unfortenately I don't know the way around this limitation. JDK has a trick with caching Integer instances in range -128 .. 127 but it does not help, instead it I spent some time thinking about different approach to wrap 'terminal' properties but then I came to the conclusion that it is not too bad to turn all the properties into objects. What I left in my investigations is creating a class that is replica of entity class but all the properties become of type Object. But it would require to instrument all the places of invocation. It looks like huge overkill. Another approach to generate sequential values in order to distinguish them from each other (instead of reference identity) stuck on boolean type.
Dec 29, 2008
This problem has been encountered early in development and there is no 100% correct workaround for it. The solution you mention may conflict with literal values (how to distinguish between LF generated values and user-provided) while another one which relies on order-of- invocation and using a stack may be defeated by corner cases. This limitation will be documented.
Status:
WontFix
|