esotericsoftware / kryo Goto Github PK
View Code? Open in Web Editor NEWJava binary serialization and cloning: fast, efficient, automatic
License: BSD 3-Clause "New" or "Revised" License
Java binary serialization and cloning: fast, efficient, automatic
License: BSD 3-Clause "New" or "Revised" License
From chaschev on November 17, 2010 15:37:44
What steps will reproduce the problem?
Original issue: http://code.google.com/p/kryo/issues/detail?id=31
From [email protected] on May 03, 2011 08:45:55
What steps will reproduce the problem?
Original issue: http://code.google.com/p/kryo/issues/detail?id=44
From [email protected] on December 31, 2010 02:14:15
It is convention to zip a directory so that on expansion you get a directory. Instead I got the contents of the kryo directory sprayed across my working area which I then had to go an clean up manually.
What steps will reproduce the problem?
1.unzip kryo.zip
What version of the Kryo are you using?
kryo-1.0.3
Please provide any additional information below.
Original issue: http://code.google.com/p/kryo/issues/detail?id=36
From [email protected] on January 28, 2011 03:42:12
What steps will reproduce the problem?
Original issue: http://code.google.com/p/kryo/issues/detail?id=37
From [email protected] on October 07, 2010 11:04:20
No happens-before relationship between updates to listeners
addListener/removeListener and calls to removeRemoteEntity
Original issue: http://code.google.com/p/kryo/issues/detail?id=29
From [email protected] on March 06, 2011 14:34:02
What steps will reproduce the problem?
Original issue: http://code.google.com/p/kryo/issues/detail?id=40
From [email protected] on May 11, 2010 08:44:42
What steps will reproduce the problem?
Original issue: http://code.google.com/p/kryo/issues/detail?id=19
From [email protected] on April 22, 2010 09:45:02
In Kryo 1.0, when ByteArrayCompressor.compress() is passed an inputBuffer
that contains more than 2048 bytes to be compressed, it throws an
IndexOutOfBoundsException.
Here's the code.
public void compress (ByteBuffer inputBuffer, Object object, ByteBuffer
outputBuffer) {
Context context = Kryo.getContext(); // 1
byte[] inputBytes = context.getBuffer(bufferSize).array(); // 2
int inputLength = inputBuffer.remaining(); // 3
inputBuffer.get(inputBytes, 0, inputLength); // 4
compress(inputBytes, inputLength, outputBuffer); // 5
}
The problem is that line 2 will normally return a byte array that is only
2048 bytes long and line 4 will throw an exception if the 'inputBytes'
array is shorter than 'inputLength'.
Original issue: http://code.google.com/p/kryo/issues/detail?id=18
From [email protected] on March 25, 2010 02:11:19
Current Kryo object graph serializers (eg, FieldSerializer) use the Java
class definition as a schema. This reduces serialized size because the data
for an object's fields is written in a known order; there is no need to
write field identifiers. The drawback is that any change to the class
definition invalidates serialized bytes made with the old class definition.
Both scenarios should be supported. Some uses of Kryo have short-lived
serialized bytes (eg, IPC or a networked game) and gladly sacrifice
forward/backward compatibility for smaller serialized size. Other uses keep
serialized bytes around for a long time (eg, storing them on disk or in a
database) and it would be unacceptable to invalidate all existing data when
a class is modified.
To support forward/backward compatibility, during serialization, the first
time an object type is encountered the field names would be written. This
defines the order the field values will appear in the serialized bytes for
that type. If a field no longer exists, it is ignored. Fields not in the
serialized bytes are left unchanged.
It isn't terribly efficient to write the field name as Strings. Possibly an
annotation could be provided that would allow fields to be given an
ordinal, allowing the field to be referenced with just 1 byte rather than 1
byte per character in its name.
Original issue: http://code.google.com/p/kryo/issues/detail?id=12
From [email protected] on November 09, 2010 08:49:33
What steps will reproduce the problem?
Original issue: http://code.google.com/p/kryo/issues/detail?id=30
From martin.grotzke on May 26, 2010 16:48:25
Right now, when there's an error during deserialization somewhere below
FieldSerializer.readObjectData it's hard to tell what's the reason for the
issue.
For debugging I deployed patched the FieldSerializer so that I was able to
locate the issue.
The attached patch is a suggestion for an improvement.
Attachment: FieldSerializer.java.patch
Original issue: http://code.google.com/p/kryo/issues/detail?id=21
From [email protected] on March 23, 2010 21:18:20
Detailed Problem Description:
The issue appears when the ObjectBuffer is created with an initial capacity
that is lower than the object data to read. (If the initial capacity is
greater than the size of the object to read, the issue does not appear).
The source of the problem seems to reside in the resizeBuffer method in the
following statement:
if (preserveContents) newBuffer.put(buffer);
newBuffer.put only transfers the REMAINING bytes of buffer (the source
buffer). I think the statement should be corrected to:
if (preserveContents) {
buffer.position(0);
newBuffer.put(buffer);
}
What is the expected output? What do you see instead?
Without the fix above I get a wrong sequence of bytes due to copying only
remaining bytes when resizing the buffer.
What version of the Kryo are you using?
Version 1.0
Original issue: http://code.google.com/p/kryo/issues/detail?id=11
From [email protected] on May 04, 2011 09:33:48
What steps will reproduce the problem?
Attachment: NewKryoTest.java
Original issue: http://code.google.com/p/kryo/issues/detail?id=45
From martin.grotzke on May 26, 2010 00:44:30
The attached ArraySerializerTest fails with
java.lang.IllegalArgumentException: array element type mismatch
at java.lang.reflect.Array.set(Native Method)
at
com.esotericsoftware.kryo.serialize.ArraySerializer.readArray(ArraySerializ
er.java)
Just place the ArraySerializerTest in
test/com/esotericsoftware/kryo/serialize and execute.
I ran it against the kryo trunk (rev 108).
We have such a combination of an interface-array and enum implementations,
so this is a real issue for us.
Attachment: ArraySerializerTest.java
Original issue: http://code.google.com/p/kryo/issues/detail?id=20
From [email protected] on April 20, 2011 18:24:37
What steps will reproduce the problem?
1.create a string array which contains the same String reference
2.serialize the array with kryo and java built-in
3.you will see the size of kryo is much more than java
What is the expected output? What do you see instead?
I think the same String should only be serialized once.
And the size of the array should be smaller than java built-in.
What version of the Kryo are you using?
1.04
Please provide any additional information below.
the code is here:
@test
public void testStringSer() throws IOException{
char[] chars = new char[1500];
Arrays.fill(chars, 'a');
String str = new String(chars);
testStringSer(str);
String[] strArray = new String[]{str, str, str};
testStringArraySer(strArray);
}
private void testStringSer(String str) throws IOException{
Kryo kryo = new Kryo();
kryo.setRegistrationOptional(true);
ObjectBuffer ob = new ObjectBuffer(kryo, 5 * 1024);
byte[] bytesKryo = ob.writeObjectData(str);
System.out.println("kryo byte length of string:"+ bytesKryo.length);
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(str);
byte[] bytesJava = bos.toByteArray();
bos.close();
oos.close();
System.out.println("java byte length of string:"+bytesJava.length);
}
private void testStringArraySer(String[] strArray) throws IOException{
Kryo kryo = new Kryo();
kryo.setRegistrationOptional(true);
ObjectBuffer ob = new ObjectBuffer(kryo, 5 * 1024);
byte[] bytesKryo = ob.writeObjectData(strArray);
System.out.println("kryo byte length of string array:"+ bytesKryo.length);
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(strArray);
byte[] bytesJava = bos.toByteArray();
bos.close();
oos.close();
System.out.println("java byte length of string array:"+bytesJava.length);
}
and the result is:
kryo byte length of string:1502
java byte length of string:1507
kryo byte length of string array:4511
java byte length of string array:1557
Original issue: http://code.google.com/p/kryo/issues/detail?id=43
From martin.grotzke on August 11, 2010 11:02:52
When serialization fails it would be really helpfull to get the object graph printed to get an idea of potential issues.
Original issue: http://code.google.com/p/kryo/issues/detail?id=24
From [email protected] on December 20, 2010 18:23:03
What steps will reproduce the problem?
Original issue: http://code.google.com/p/kryo/issues/detail?id=33
From [email protected] on November 30, 2009 04:04:19
What steps will reproduce the problem?
Attachment: createObject.java
Original issue: http://code.google.com/p/kryo/issues/detail?id=5
From [email protected] on December 22, 2010 19:16:15
What steps will reproduce the problem?
No problems in serializing / deserializing using a default FieldSerializer. Uisng the CompatibleFieldSerializer serializing / deserializing round-trips work for shallow graphs but for deeply nested collections the round-trip fails by throwing an IllegalArgumentException ( usually during deserialization and when passing a null value to a primitive value field ). Cant tell if its the deserialization thats broken or the serialized stream is incomplete / wrong.
Registering the classes to use the CompatibleFieldSerializer remedies the problem in some cases ( such as the example attached ) but in others it has no effect ( not attached ).
What is the expected output? What do you see instead?
Expected round trip serializing / deserializing to produce equivalent objects - instead the test case attached errors out when using CompatibleFieldSerializer
What version of the Kryo are you using?
1.03
Please provide any additional information below.
Attached test case and MultiMap / aggregate object to reproduce the error
Attachment: KryoTest.java Finger.java MultiMap.java
Original issue: http://code.google.com/p/kryo/issues/detail?id=34
From [email protected] on December 22, 2010 22:51:25
What steps will reproduce the problem?
Serializing large objects extends the Context.getByteArray() indefinitely ( and it seems it is not reset under any conditions ). On subsequent calls to serialize ( another or the same object ) the temp byte array is still very large and may exceed the length of available bytes in the buffer on buffer.get()
What is the expected output? What do you see instead?
BufferUnderflowException thrown at line 189 of CompatibleFieldSerializer
What version of the Kryo are you using?
1.03
Please provide any additional information below.
Original issue: http://code.google.com/p/kryo/issues/detail?id=35
From [email protected] on October 28, 2009 20:03:52
It looks like kryo cannot serialize objects with cyclic reference :
class Parent {
List children;
}
class Child {
Parent parent;
}
Do you think kryo can support those objects some day ?
Thanx
Original issue: http://code.google.com/p/kryo/issues/detail?id=2
From [email protected] on March 09, 2011 01:28:44
Hi -
One suggestion to improve performance of ObjectBuffer on large objects (when at runtime its unknown that they're large, so the buffer's initial capacity is low) -- Is it possible for the buffer to determine by how much its underallocated when it finds that its max capacity is insufficient? E.g. in our case we're Kryoing an object that contains a byte[], and the byte[] is very large, but it should be possible for Kryo to know how much extra room it needs, and rather than just double the capacity, it could keep doubling until it the new allocated amount meets the new allocation requirement.
Hope that makes sense
Thanks!
Original issue: http://code.google.com/p/kryo/issues/detail?id=42
From [email protected] on September 28, 2010 00:07:45
What steps will reproduce the problem?
Original issue: http://code.google.com/p/kryo/issues/detail?id=27
From [email protected] on October 28, 2009 05:06:45
When you serialise a large amount of data the ByteBuffer has not enought
available space and throw an exception.
Attachment: TestKryo.java
Original issue: http://code.google.com/p/kryo/issues/detail?id=1
From [email protected] on March 03, 2011 08:18:52
What steps will reproduce the problem?
Original issue: http://code.google.com/p/kryo/issues/detail?id=39
From anightl on March 25, 2010 14:25:14
plz provide kryo as maven artifacts
Original issue: http://code.google.com/p/kryo/issues/detail?id=13
From [email protected] on November 25, 2011 04:02:57
Using Kryonet we're having a bit of trouble when moving large-ish objects over a network connection. The error does not happen when connecting to localhost, only when connecting to a remote computer.
The error itself comes from the depths of Kryo where, for some reason, Kryo is trying to set a field of non-Boolean type to a Boolean value. The particular field which it tries to set is not always the same, either.
Any ideas on why this might be happening?
Using Kryo/Kryonet v1.04.
Original issue: http://code.google.com/p/kryo/issues/detail?id=49
From martin.grotzke on June 25, 2010 22:16:35
Hi Nate,
I'd like to have the possibility to set a given RegisteredClass for a certain type, e.g. via s.th. like
void putRegisteredClass( Class type, RegisteredClass registeredClass )
My situation is the following: I have a serializer for cglib proxies that I register using a marker class:
kryo.register( CGLibProxySerializer.CGLibProxyMarker.class, new CGLibProxySerializer( kryo ) );
When a cglib proxy class is written via Kryo.writeClass, this proxy class is not yet known as it's s.th. like
MSM_de.javakaffee.kryoserializers.cglib.CGLibProxySerializerTest$MyServiceImpl$$EnhancerByCGLIB$$d0595dcf
For this class I want to register the previously registered CGLibProxySerializer, so that this one is used for the actual proxy class.
I know that I could override getRegisteredClass(Class) like this:
public RegisteredClass getRegisteredClass( final Class type ) {
if ( CGLibProxySerializer.canSerialize( type ) ) {
return super.getRegisteredClass( CGLibProxySerializer.CGLibProxyMarker.class );
}
return super.getRegisteredClass( type );
}
Unfortunately, CGLibProxySerializer.canSerialize( type ) is rather expensive and this would be called for each writeClass, so I'd prefer to just override handleUnregisteredClass(Class):
protected void handleUnregisteredClass( final Class type ) {
if ( CGLibProxySerializer.canSerialize( type ) ) {
putRegisteredClass( type, getRegisteredClass( CGLibProxySerializer.CGLibProxyMarker.class ) );
}
else {
super.handleUnregisteredClass( type );
}
}
The patch for putRegisteredClass(Class, RegisteredClass) is attached.
Can you include this or s.th. similar in kryo?
Thx && cheers,
Martin
Attachment: Kryo_putRegisteredClass.patch
Original issue: http://code.google.com/p/kryo/issues/detail?id=22
From [email protected] on July 19, 2011 16:04:11
What steps will reproduce the problem?
1.install java 7
2.run java program
What is the expected output? What do you see instead?
not to throw a exception, exception thrown saying the proxy class isnt registered
What version of the Kryo are you using?
newest
Please provide any additional information below.
it worked before i installed the new java
Original issue: http://code.google.com/p/kryo/issues/detail?id=46
From martin.grotzke on September 08, 2010 15:05:35
When Kryo is used in a multi-threaded environment external synchronization is required to ensure that the internally used HashMap classToRegisteredClass (and probably the IntHashMap idToRegisteredClass) cannot be broken which might cause infinite loops.
The suggested patch now synchronizes write access of classToRegisteredClass on exactly this object. From my understanding this is enough to ensure that the HashMap internal linked lists cannot be broken. As read access is not synchronized it might happen that some thread gets an "invalid" object from the map that is replaced by a second thread, but IMHO this isn't an issue as correct functionality/behavior is not affected by this.
As the synchronized block on classToRegisteredClass also included the idToRegisteredClass.put, I think this potential concurrency issue is also solved.
Is this patch acceptable? Can you apply it as soon as possible and make a new release? This would save the world for me right now :-)
Attachment: Kryo_concurrentHashMapAccess.patch
Original issue: http://code.google.com/p/kryo/issues/detail?id=26
From [email protected] on November 18, 2011 09:56:04
Hello,
i want to build kryo 1.04 as maven project.
The problem is that in the pom.xml the version is 1.1-SNAPSHOT and
if i want to build this it returns:
The following artifacts could not be resolved: com.esotericsoftware:reflectasm:jar:0.8, com.esotericsoftware:minlog:jar:1.2
Were can i get this artifacts? The tags i can find are in the wrong version. I need this as maven project in svn or git.
Original issue: http://code.google.com/p/kryo/issues/detail?id=48
From [email protected] on March 08, 2011 07:00:51
What steps will reproduce the problem?
1.create a bean class, holding a reference to another one, like
public class Dinner
{
private Dinner next;
public Dinner getNext()
{
return next;
}
public void setNext(Dinner next)
{
this.next = next;
}
}
2.instantiate one and set the next to itself,
Dinner d = new Dinner();
d.setNext(d);
3.Use kryo ( version 1.01 ) to serialize it,
byte[] bytes = buffer.writeObjectData(src);
You will get the BufferOverflowException for sure.
Original issue: http://code.google.com/p/kryo/issues/detail?id=41
From martin.grotzke on April 05, 2010 23:10:33
The FieldSerializer right now does not handle final fields. It should do so if setFieldsAsAccessible is set to true
(default). As an alternative, it would be nice to have the possible to have s.th. like
setSupportFinalFields(boolean).
Attached is a patch for FieldSerializer that checks setFieldsAsAccessible and does not skip the field if
setFieldsAsAccessible is true.
Attachment: FieldSerializer_finalFields.patch
Original issue: http://code.google.com/p/kryo/issues/detail?id=15
From [email protected] on September 02, 2010 16:55:48
This is not an issue but rather a proposal.
You write that you use generated bytecode to access public fields and cached reflection to access protected and private fields.
I propose that you use bytecode corresponding to the example below to also access protected fields (and with a variant also package visible fields) but improved speed.
// an existing class with a non-private field x:
class Existing {
protected byte x;
}
// a serializer which can access x within java rules:
class Serializer extends Existing {
public static void writeObject(final ByteBuffer b, final Existing t) {
b.put(t.x);
}
}
The idea is to create a class which inherits from the class in question (which allows to access the field) but not to use instances of that class (we have no use for it anyway).
Accessing package visible fields is also possible with a variant of this method - provided the package is not protected by the SecurityManager. Just generate a class in that package.
Looking at your code I think that a fairly straitforward variant or your MethodAccess code should do it.
Accessing private fields is of course no possible with this approach as that would require geenrating access code in the class at question which is not possible after that class is loaded.
In the long run you might consider providing a ClassLoader which intercepts class load calls and adds special custom serialization methods in all classes of your choice. Then you'd only need to call those methods during serialization.
Yours
Gunnar Zarncke
Original issue: http://code.google.com/p/kryo/issues/detail?id=25
From [email protected] on February 27, 2010 20:06:03
Steps will reproduce the problem:
Instead, it would be better to throw an exception with explicit Class
property in it, to make it possible to see which class was not registered.
With the code like this:
throw new KryoUnregisteredException(type, "Class is not registered: "...)
This addition is needed to register classes dynamically in runtime, and
retry the serialization until all classes are registered.
Alternative solution would be to use user-supplied callback code which
performs registration instead of throwing an exception.
Original issue: http://code.google.com/p/kryo/issues/detail?id=7
From [email protected] on September 08, 2011 16:44:57
Compressor only uses a short to store the length of the compressed data (lines 78 and 91). This cannot be easily changed by subclasses either, since the length is written in the parent class.
I altered Compressor to use int, and was able to successfully retrieve my data.
Original issue: http://code.google.com/p/kryo/issues/detail?id=47
From [email protected] on August 03, 2010 13:48:36
What steps will reproduce the problem?
Attachment: KryoDateDefect.java
Original issue: http://code.google.com/p/kryo/issues/detail?id=23
From [email protected] on March 20, 2010 14:29:26
Any use of the library requires one to know the size of the serialized
object which is not always true. Allocating 10 MB per thread in a server
setting just "to be sure" is not ideal.
For instance:
Kryo kryo = new Kryo();
kryo.setAllowUnregisteredClasses(true);
ByteBuffer buffer = ByteBuffer.allocate(1024 * 1024 * 10);
kryo.writeClassAndObject(buffer, "This is a test");
What is the expected output? What do you see instead?
I would expect a version of ther API to work with Outputstream for writing
and InputStream for reading, not ByteBuffer.
For instance:
Kryo kryo = new Kryo();
kryo.setAllowUnregisteredClasses(true);
OutputStream outputStream = ...
kryo.writeClassAndObject(outputStream, "This is a test");
What version of the product are you using? On what operating system?
Kryo 1.0 on Ubuntu 9.10 & Win7
If there is not requirement for reading the buffer after the data is
written to it, this should be simple to fix, perhaps by adding a thin
wrapper to allow your API to accept ByteBuffer, InputStream/OutputStream, etc.
So I guess this boils down to:
Do you read back the buffer contents after you have started serializing an
object?
Thanks for your time! :)
Original issue: http://code.google.com/p/kryo/issues/detail?id=10
From [email protected] on November 24, 2010 09:20:08
The generated classes with ASM should have the internal version compatible with the JVM that runs the code. Actually, is fixed in the 1.6 version.
This is not a big problem (maybe only we still running our products in 1.5 only), but maybe should say something about "for JRE 1.6+" somewhere in the documentation.
Thanks.
Original issue: http://code.google.com/p/kryo/issues/detail?id=32
From [email protected] on April 12, 2010 21:52:41
Hi Nate,
I've checked out the latest revision of kryo from svn and built using
Netbeans 6.0.1
$ uname -a
SunOS bluto 5.10 Generic_137111-06 sun4u sparc SUNW,Ultra-80
$ java -version
java version "1.6.0_07"
Java(TM) Platform, Standard Edition for Business (build 1.6.0_07-b06)
Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode)
These are the failure results, all other tests are passing:
Testsuite: com.esotericsoftware.kryo.serialize.ReferenceFieldSerializerTest
Tests run: 5, Failures: 2, Errors: 0, Time elapsed: 1.028 sec
Testcase:
testNonStaticInnerClassPublicConstructor(com.esotericsoftware.kryo.serialize.ReferenceFieldSerializerTest):
FAILED
Incorrect length. expected:<18> but was:<15>
junit.framework.AssertionFailedError: Incorrect length. expected:<18> but
was:<15>
at
com.esotericsoftware.kryo.KryoTestCase.roundTripKryo(KryoTestCase.java:86)
at
com.esotericsoftware.kryo.KryoTestCase.roundTrip(KryoTestCase.java:74)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializerTest.testNonStaticInnerClassPublicConstructor(ReferenceFieldSerializerTest.java:76)
Testcase:
testNonStaticInnerClassPrivateConstructor(com.esotericsoftware.kryo.serialize.ReferenceFieldSerializerTest):
FAILED
Incorrect length. expected:<18> but was:<15>
junit.framework.AssertionFailedError: Incorrect length. expected:<18> but
was:<15>
at
com.esotericsoftware.kryo.KryoTestCase.roundTripKryo(KryoTestCase.java:86)
at
com.esotericsoftware.kryo.KryoTestCase.roundTrip(KryoTestCase.java:74)
at
com.esotericsoftware.kryo.serialize.ReferenceFieldSerializerTest.testNonStaticInnerClassPrivateConstructor(ReferenceFieldSerializerTest.java:91)
Test com.esotericsoftware.kryo.serialize.ReferenceFieldSerializerTest FAILED
Original issue: http://code.google.com/p/kryo/issues/detail?id=16
From martin.grotzke on April 05, 2010 21:17:40
In kryo-serializers I just wanted to reference the latest kryo from trunk without just referencing the projects
in eclipse :-)
For this I created a very simple pom.xml (for maven2) that builds kryo, see the file attached.
As version I chose 1.1-SNAPSHOT as a wild guess. Stuff like scm info, license, mailing list etc. is left out...
When you run "$ mvn install" maven tells you that neither minlog nor reflectasm is available in public repos
and that you need to install them. So just do
$ mvn install:install-file -DgroupId=com.esotericsoftware -DartifactId=reflectasm -Dversion=0.8 -
Dpackaging=jar -Dfile=lib/reflectasm-0.8.jar
and
$ mvn install:install-file -DgroupId=com.esotericsoftware -DartifactId=minlog -Dversion=1.2 -
Dpackaging=jar -Dfile=lib/minlog-1.2.jar
and afterwards again
$ mvn install
Then everything's fine.
It would be great to find this or s.th. similar in kryo. :)
Attachment: pom.xml
Original issue: http://code.google.com/p/kryo/issues/detail?id=14
From [email protected] on March 11, 2010 04:51:10
Kryo should support BigDecimal and BigInteger classes out of the box.
They could probably stand to be optimized but I have attached Serializers
to provide the basic required functionality, and appropriate unit tests.
Original issue: http://code.google.com/p/kryo/issues/detail?id=9
From [email protected] on February 14, 2012 12:49:56
I have a class B which contains a transient field that its initialization requires deserialization of class A. Trying to deserialize class B completely breaks Kryo (running a single thread). I thought that maybe calling 'Kryo.getContext().reset()' would solve the issue but that didn't help.
What steps will reproduce the problem?
Run the attached code (also given below).
What is the expected output? What do you see instead?
I expect the program to end successfully. Instead I get an exception.
What version of the Kryo are you using?
1.04
Please provide any additional information below.
The code to reproduce the problem:
-------------------------------------------------------------------
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.HashMap;
import java.util.LinkedList;
import java.util.Map;
import java.util.Vector;
import com.esotericsoftware.kryo.Kryo;
import com.esotericsoftware.kryo.ObjectBuffer;
public class Main {
public static <T> void serialize(T obj, String filename) throws FileNotFoundException, IOException
{
Kryo kryo = new Kryo();
kryo.setRegistrationOptional(true);
//Kryo.getContext().reset();
ObjectBuffer buffer = new ObjectBuffer(kryo, 100000);
OutputStream os = new FileOutputStream(filename);
buffer.writeClassAndObject(os, obj);
os.close();
}
@SuppressWarnings("unchecked")
public static <T> T deserialize(String filename) throws IOException, ClassNotFoundException
{
Kryo kryo = new Kryo();
kryo.setRegistrationOptional(true);
//Kryo.getContext().reset();
InputStream is = new FileInputStream(filename);
ObjectBuffer buffer = new ObjectBuffer(kryo, 100000);
Object obj = buffer.readClassAndObject(is);
is.close();
return (T) obj;
}
public static class Class1
{
private Vector<float[]> values = new Vector<float[]>();
public Class1() {
for(int i=0; i < 2; ++i) values.add(new float[i+1]);
}
public float[] getValue(int i) { return values.get(i); }
}
public static class Class2
{
private Map<String, Vector<LinkedList<Float>>> data = new HashMap<String, Vector<LinkedList<Float>>>();
private transient Class1 class_1 = readClass1();
public Class2() {
Vector<LinkedList<Float>> value1 = new Vector<LinkedList<Float>>();
value1.add(new LinkedList<Float>());
value1.lastElement().add(1.1f);
value1.lastElement().add(1.2f);
value1.add(new LinkedList<Float>());
value1.lastElement().add(2.1f);
value1.lastElement().add(2.2f);
Vector<LinkedList<Float>> value2 = new Vector<LinkedList<Float>>();
value2.add(new LinkedList<Float>());
value2.lastElement().add(1.1f);
value2.lastElement().add(1.2f);
value2.add(new LinkedList<Float>());
value2.lastElement().add(2.1f);
value2.lastElement().add(2.2f);
value2.add(new LinkedList<Float>());
value2.lastElement().add(3.1f);
value2.lastElement().add(3.2f);
data.put("key1", value1);
data.put("key2", value2);
}
public float[] getValue() { return class_1.getValue(1); }
private Class1 readClass1()
{
try {
return deserialize("d:/test_java_class_1.dat");
} catch (Exception e) {
throw new Error("Can't deserialize !", e);
}
}
}
public static void main(String[] args) throws Exception
{
com.esotericsoftware.minlog.Log.TRACE = true;
Class1 base = new Class1();
serialize(base, "d:/test_java_class_1.dat");
Class2 one = new Class2();
System.out.println(one.getValue().length);
serialize(one, "d:/test_java_class_2.dat");
Class2 two = deserialize("d:/test_java_class_2.dat");
System.out.println(two.getValue().length);
}
}
Attachment: Main.java
Original issue: http://code.google.com/p/kryo/issues/detail?id=50
From [email protected] on March 01, 2010 09:08:41
Hello
I'm just investigating alternativs for java serialization. We are using
SpringHTTPInvoker to transmit objects. After it seems everything should run
now. I run into a Stackoverflow during serialisation. We have a quite
complex entity-structure where it is possible to navigate forth and back
through the object tree. When I look at the stacktrace I would say the
repeating fieldtypes are the problem.
java.lang.StackOverflowError
at java.lang.reflect.AccessibleObject.(AccessibleObject.java:137)
at java.lang.reflect.Field.(Field.java:104)
at java.lang.reflect.Field.copy(Field.java:127)
at java.lang.reflect.ReflectAccess.copyField(ReflectAccess.java:122)
at sun.reflect.ReflectionFactory.copyField(ReflectionFactory.java:289)
at java.lang.Class.copyFields(Class.java:2739)
at java.lang.Class.getDeclaredFields(Class.java:1743)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.rebuildCachedFields(FieldSerializer.java:65)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.(FieldSerializer.java:52)
at com.esotericsoftware.kryo.Kryo.getDefaultSerializer(Kryo.java:224)
at com.esotericsoftware.kryo.Kryo.getRegisteredClass(Kryo.java:240)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.rebuildCachedFields(FieldSerializer.java:100)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.(FieldSerializer.java:52)
at com.esotericsoftware.kryo.Kryo.getDefaultSerializer(Kryo.java:224)
at com.esotericsoftware.kryo.Kryo.getRegisteredClass(Kryo.java:240)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.rebuildCachedFields(FieldSerializer.java:100)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.(FieldSerializer.java:52)
at com.esotericsoftware.kryo.Kryo.getDefaultSerializer(Kryo.java:224)
at com.esotericsoftware.kryo.Kryo.getRegisteredClass(Kryo.java:240)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.rebuildCachedFields(FieldSerializer.java:100)
at
com.esotericsoftware.kryo.serialize.FieldSerializer.(FieldSerializer.java:52)
at com.esotericsoftware.kryo.Kryo.getDefaultSerializer(Kryo.java:224)
at com.esotericsoftware.kryo.Kryo.getRegisteredClass(Kryo.java:240)
I'm wondering if kryo would have the same problem with repeated objects and
circular references.
Maybee an IdentiyHashMap would solve this during processing the fields.
Cheers
Marco
What version of the product are you using? On what operating system?
Windows Kryo 0.99
Please provide any additional information below.
Original issue: http://code.google.com/p/kryo/issues/detail?id=8
From [email protected] on October 31, 2009 00:53:14
StringSerializer's get() reads too much data from the buffer.
put() counts byte[]'s length, but get() reads char[length],
As some char is more then 1 byte(eg. chinese), it causes an error.
The fixed get() looks like:
static public String get (final ByteBuffer buffer) {
int length = IntSerializer.get(buffer, true);
Context context = Kryo.getContext();
byte[] bytes = (byte[])context.get("byteArray");
if (bytes == null || bytes.length < length) {
bytes = new byte[length];
context.put("byteArray", bytes);
}
buffer.get(bytes, 0, length);
return new String(bytes, 0, length, charset);
}
Original issue: http://code.google.com/p/kryo/issues/detail?id=3
From [email protected] on November 30, 2009 04:36:08
fields with the modifier final should be serialized, as they can contain
runtime data. Same goes to static fields
class Foo {
static int count = 0;
final int ID;
public Foo() {
ID = count++;
}
}
the only fields not needed to be serialized are: "transient", "static final"
Original issue: http://code.google.com/p/kryo/issues/detail?id=6
From [email protected] on September 30, 2010 06:53:56
What steps will reproduce the problem?
Original issue: http://code.google.com/p/kryo/issues/detail?id=28
From [email protected] on March 02, 2011 23:32:04
What steps will reproduce the problem?
1.When 2 objects reference the same collection/map/array and you make a roundtrip (serialize/deserialize), you end up with 2 collections/map/array instead of the same ones in each object.
What is the expected output? What do you see instead?
Serializing the same collection should result in only one collection after deserialization. Right now I end up with 2 collections. I understand the the ReferenceFieldSerializer is not intended to handle this case, because Collections/Map/Array are handled by other serializers so I made some modifications to the code to be able to handle this case with a decorator. If you want to integrate it to kryo, feel free to, or maybe you have a better approch to propose.
What version of the Kryo are you using?
1.04
Please provide any additional information below.
Attached is a patch for the modifications and a jUnit test for the case.
Attachment: kryo_collections_references.patch
Original issue: http://code.google.com/p/kryo/issues/detail?id=38
From [email protected] on November 09, 2009 16:05:34
What steps will reproduce the problem?
Kryo kryo = new Kryo();
kryo.register(ArrayList.class);
//TestClass stc = new TestClass();
ArrayList al = new ArrayList(Arrays.asList("1", "2", "3"));
ByteBuffer buffer = ByteBuffer.allocate(1024);
kryo.writeObject(buffer,al);
buffer.flip();
ArrayList stc1 = kryo.readObject(buffer, ArrayList.class);
System.out.println(stc1.get(1));
What is the expected output? What do you see instead?
Exception is java.nio.BufferUnderflowException
What version of the product are you using? On what operating system?
0.92, XP SP2 and jdk 1.6
Please provide any additional information below.
Original issue: http://code.google.com/p/kryo/issues/detail?id=4
From [email protected] on April 13, 2010 12:42:21
This is a very preliminary rough patch. I have some other ideas that I'd
also like to experiment, I've posted it here so others may experiment with
it also.
New BSD License as per Kryo.
This builds and all the tests pass, note that this patch is set to weak
references in Kryo's constructor by default.
You've got some performance testing code also I believe?
Cheers,
Peter.
Attachment: kryoWeakLinks.patch
Original issue: http://code.google.com/p/kryo/issues/detail?id=17
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.