What steps will reproduce the problem?
1. try this code:
import com.rits.cloning.Cloner;
import java.util.Map.Entry;
import java.util.logging.Logger;
import org.junit.Test;
/**
*
* @author Marek Bukowy
*/
public class CloneInnerAnonTest {
private Logger logger = Logger.getAnonymousLogger();
@Test
public void helloTest() {
Cloner cl = new Cloner();
cl.setDumpClonedClasses(true);
Entry<Object, String> a = new Entry<Object, String>() {
public Object getKey() {
return null;
}
public String getValue() {
return "";
}
public String setValue(String value) {
return "";
}
};
cl.deepClone(a);
}
}
This test case can be extended to have a mock interceptor as a private field in
the CloneInnerAnonTest class, and an assert on number of invocations (should be
0 if cloner does not touch those private fields).
* What is the expected output? What do you see instead?
I think it is wrong that the cloner goes into the parent class. It should
recognize that it is an implementation of Map.Entry and stop there. Even if
formally correct as a Java concept, I believe there should be a switch that
controls this behaviour.
What version of the product are you using? On what operating system?
cloning 1.8.1
objenesis 1.2
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.6) (6b22-1.10.6-0ubuntu1)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
Please provide any additional information below.
When run inside a tomcat app, with the "parent" class having a few key system
elements as fields - for example as innocent as a Mockito mock, it goes very
quickly into cloning almost every conceivable object in the application,
usually ending up with a JVM crash like this:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f97c18874c3, pid=7677, tid=140289463260928
#
# JRE version: 6.0_26-b03
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# C [libzip.so+0xb4c3] ZIP_GetEntry+0x33
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Original issue reported on code.google.com by m...@pakla.pl on 22 Aug 2012 at 9:59
Original issue reported on code.google.com by
m...@pakla.pl
on 22 Aug 2012 at 9:59