kryo: ArrayIndexOutOfBoundsException when serializing generic classes

Using Kryo 5.0.0-RC3-SNAPSHOT, I get the following Stacktrace when running the test:

com.esotericsoftware.kryo.KryoException: java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
Serialization trace:
input (SerializeTest$StringSupplierContainer)
	at com.esotericsoftware.kryo.serializers.ReflectField.write(ReflectField.java:92)
	at com.esotericsoftware.kryo.serializers.FieldSerializer.write(FieldSerializer.java:107)
	at com.esotericsoftware.kryo.Kryo.writeClassAndObject(Kryo.java:630)
import com.esotericsoftware.kryo.Kryo;
import com.esotericsoftware.kryo.io.Output;
import org.junit.jupiter.api.Test;

import java.io.Serializable;
import java.util.function.Supplier;

import static org.assertj.core.api.Assertions.assertThat;

public class SerializeTest {

	@Test
	void serialize() {
		final Kryo kryo = new Kryo();
		kryo.setRegistrationRequired(false);

		final Output output = new Output(1024);
		kryo.writeClassAndObject(output, new StringSupplierContainer());
		final byte[] result = output.toBytes();

		assertThat(result).isNotNull();
	}

	static class EmptyStringSupplier implements Supplier<String>, Serializable {

		@Override
		public String get() {
			return "";
		}
	}

	static class StringSupplierContainer extends SupplierContainer<String> {

		StringSupplierContainer() {
			super(new EmptyStringSupplier());
		}
	}

	static class SupplierContainer<T> {

		private final Supplier<T> input;

		SupplierContainer(Supplier<T> input) {
			this.input = input;
		}
	}
}

Possibly related to #648

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 1
  • Comments: 25

Commits related to this issue

Most upvoted comments

@NathanSweet Can you help here?

My pleasure @magro!

I only compiled existing fixes and verified them with my tests. Original contributions were by @tostino, @maxisvest, and @aijm.

I’ll test RC6 against my main application tomorrow.

@magro: I have just pushed #717. This PR contains all currently known failing test-cases.

I will shortly create another PR that applies known fixes for these issues and resolves all these cases. All of these fixes are quite simple and as far as I can tell should not break other functionality.

@magro: This makes sense. I’ll create a PR with tests for #654 and #655 asap.

Any intention in fixing the underlying problem? I’m also victim to this error. The proposed pr seems to lead into other issues here. Not sure it’s related to this issue, eventually, I’m in need of a proper fix, though.