Read single object

[Rots]

Thanks for the great library!
Currently the implementation expects to always read to the end of the stream.

jserial/deserialize.go

Lines 356 to 365 in afb2f73

	// end check has next byte in stream.
	func (sop *SerializedObjectParser) end() bool {
	if sop.rd.Buffered() == 0 {
	_, eof := sop.rd.Peek(1)
	return eof != nil
	}
	return false
	}

I have a case where the stream contains other stuff in addition to the serialised java object. And I don't have a size of the java object to be able to r = io.LimitReader(r,size) before attempting to parse.
I.e. I want to be able to do something like:

sop := jserial.NewSerializedObjectParser(r)
minimal, err := sop.ParseSingleSerializedObjectMinimal()
if err != nil {
    return err
}
r.Read(buf)

where buf would be populated with content right after the first serialised object
minimal would then be the single deserialised object, instead of a slice/jsonArray

[jkeys089]

@Rots unfortunately, I think that use case is outside the scope of this lib. You'd need to find a way to wrap your stream to segment the Java object from the non-Java object and then you could use this lib to deserialize just the Java object. Sorry I don't have any better advice to offer ☹️

[Rots]

Hmm, why is that out of scope? I think it's a perfectly valid use case...
E.g. if i don't have the control over the source stream, but I still want to get objects out. As the java object stream is already segmented, it doesn't look impossible to implement. In the code I am already getting the first object and stopping correctly at the next byte (happens to be unknown to the parser)
For me it would be enough to just return after the first object instead of looping this (while also keeping the original reader intact):

jserial/deserialize.go

Lines 33 to 45 in afb2f73

	for !sop.end() {
	var nxt interface{}
	if nxt, err = sop.content(nil); err != nil {
	if errors.Cause(err).Error() == io.EOF.Error() {
	err = errors.New("premature end of input")
	}
	return
	}
	content = append(content, nxt)
	}

In practice, of course I understand that it's a bit more complicated because of the use of buffered stream etc.

[jkeys089]

@Rots I just mean this project is focused on deserializing Java objects. If you have a stream containing anything other than serialized Java objects then that would be outside the scope of this project.

However, after re-reading your question I think I understand what you're asking is: could we support limiting the total number of objects and ensure we don't read more than absolutely necessary from the reader. That sounds pretty reasonable.

[Rots]

stream containing anything other than serialized Java objects then that would be outside the scope of this project

I can easily reach the same problem with only serialised java objects in the stream, e.g. trying to parse the following:

ObjectOutputStream oos = new ObjectOutputStream(out);
oos.writeObject(o1);
oos = new ObjectOutputStream(out);
oos.writeObject(o2);

Remember, the point of having libraries is the ability to combine them with other functionality to achieve higher-order logic. Artificial restriction to only a subset of use cases is not a good idea at such low level.
Anyway, I have a custom working version for now.

[jkeys089]

@Rots I think we could deserialize that stream without any issue. Are you just saying you might want to only deserialize the o1 object and not o2? If so, I already agreed with your point that is is reasonable to limit the number of objects. If not, I might be misunderstanding the issue.

[Rots]

:) We're aligned in practise, but not in theory...

With the above example I was trying to illustrate that the functionality would be useful even if dealing with only Java objects (since you insist on focusing on Java serialisation) - it's really a different perspective on the same issue. The proposed functionality would also be able to handle the above case with two objects. Of course at this level, it would be up to the user of this library to decide to call it twice, as this is "business logic" of reading the stream, not protocol of the java serialisation.

I think we could deserialize that stream without any issue

Yes, but currently, it fails with unknown type 0xac as there's no way to handle the repeated headers.

I might be misunderstanding the issue

Again, I think we agree on the issue, just not entirely on the "why" :)

Like you've noticed, I have a PR that does the trick for me.