refactor: load(InputStream) of SerializationModelStreamer

[pvojtechovsky]

alternative to #2627

[monperrus]

We are trying a fix a static warning. Maybe it's a false positive that is not important.

Is there a way to write a test case showing a real problem?

[pvojtechovsky]

We are trying a fix a static warning.

where can I see it?

Is there a way to write a test case showing a real problem?

the problem - if any - is in concept that method has InputStream input parameter and that this method is responsible to close that InputStream. The safer approach is that creator of InputStream is closing it too.

But I don't think that it is problem in this case.

[monperrus]

the problem - if any - is in concept that method has InputStream input parameter and that this method is responsible to close that InputStream.

Completely agree, this is bad design.

The safer approach is that creator of InputStream is closing it too.

Yes.

We are trying a fix a static warning.

where can I see it?

@zielint0 what warning is it?

[zielint0]

@pvojtechovsky
@monperrus

This PR was created to make sure that resource is closed. I tried to use modern 'try with resource' construct but I failed - it broke tests. So I proposed good, old 'finally'. I suspected that this piece of code is tricky, so asked for deep review to make sure that it is a good fix.

I found this place in code by inspection: AutoCloseable used without 'try'-with resources. I just wanted to be sure that resource is always released. In this case it is not a sophisticated checker. It simply points resources without modern 'try'. As well I could find it by code review.

The full description of checker is here below.

Reports AutoCloseable instances which are not used in a try-with-resources statement, also known as Automatic Resource Management. This means that the open resource before/in try, close in finally style which was used before try-with-resources was available is also reported. This inspection is meant to replace all opened but not safely closed inspections when developing in Java 7 and higher.
Use the first table below to specify which AutoCloseable subclasses should be ignored by this inspection. Specify AutoCloseable subclasses here which do not need to be closed.
Note: This inspection will still warn on streams returned from the java.nio.file.Files methods lines(), walk(), list() and find(), even when java.util.stream.Stream is specified to be ignored in this table. These streams contain an associated I/O resource that needs to be closed.
Use the second table below to specify which methods returning AutoCloseable will be ignored when called.
Use the first checkbox below to ignore an AutoCloseable if it the result of a method call. When enabled, the results of factory methods will also be ignored.
Use the second checkbox below to specify that the inspection should not warn if an AutoCloseable instance is passed as a method call argument. If enabled the inspection assumes the resource is closed in the called method. Method calls inside a finally block with close in the name and an AutoCloseable argument will not be ignored.

[monperrus]

For now, we can proceed with this solution.