My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
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
Status:  WontFix
Owner:  ----
Closed:  Dec 2008


 
Reported by koval...@gmail.com, Dec 21, 2008
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
I'm afraid it is not easy to fix. The AliasFactory relies on innate object identity
which would be broken by autoboxing.
Dec 22, 2008
Project Member #2 eric.bot...@gmail.com
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
#3 koval...@gmail.com
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
Project Member #4 eric.bot...@gmail.com
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

Powered by Google Project Hosting