New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NullPointerException on Deserialization of a QTuple #676

Closed
dmiorandi opened this Issue Mar 10, 2014 · 6 comments

Comments

Projects
None yet
2 participants
@dmiorandi

in #640 was solved QTuple SerializationException but I've seen now that Deserialization (of QTuple) is not working cause a null pointer on DslExpression class calling hashCode method.

I've patch myself the DslExpression class changing hashCode method like this...

    @Override
    public final int hashCode() {
        return mixin==null?-1:mixin.hashCode();
    }

I can't figure out if this is the right behavior but it works. Please consider if this can be integrated in your code (or if there is a cleaner approach).

Can you add to your serialization method used on tests also deserialization, something like this?

    protected Object serializeDeserialize(Object obj) throws IOException, ClassNotFoundException{
        ByteArrayOutputStream fileOut = new ByteArrayOutputStream();
        ObjectOutputStream out = new ObjectOutputStream(fileOut);
        out.writeObject(obj);

        ByteArrayInputStream fileIn = new   ByteArrayInputStream(fileOut.toByteArray());
        ObjectInputStream in = new ObjectInputStream(fileIn);
        Object objReaded = in.readObject();     
        in.close();
        out.close();
        fileOut.close();
        return objReaded;
    }

@timowest timowest added the bug label Mar 10, 2014

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Mar 10, 2014

Member

Deserialization seems to crash with RelationalPathBase.columnMetadata creation

Member

timowest commented Mar 10, 2014

Deserialization seems to crash with RelationalPathBase.columnMetadata creation

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Mar 11, 2014

Member

The implemention with the eager calculation is not optimal from a performance point of view, but it is stable and simple. Feel free to suggest alternatives.

Returning -1 for mixin == null will not work, since this will create changing hash codes. The mixin field will be populated after the object has been fully populated.

Member

timowest commented Mar 11, 2014

The implemention with the eager calculation is not optimal from a performance point of view, but it is stable and simple. Feel free to suggest alternatives.

Returning -1 for mixin == null will not work, since this will create changing hash codes. The mixin field will be populated after the object has been fully populated.

@dmiorandi

This comment has been minimized.

Show comment
Hide comment
@dmiorandi

dmiorandi Mar 12, 2014

I didn't understand completly your response.

If understand #676 solve this issue, right?
About the eager solution you mean to calculating hashcode in the constructor? A this time I have got not suggestion to you.

I didn't understand completly your response.

If understand #676 solve this issue, right?
About the eager solution you mean to calculating hashcode in the constructor? A this time I have got not suggestion to you.

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Mar 12, 2014

Member

If understand #676 solve this issue, right?

Both your patch and my commit provide a solution

About the eager solution you mean to calculating hashcode in the constructor?

With eager calculation I mean the calculation in the constructor which has the benefit that the hashCode will be directly available when deserialized, and it will be the correct one.

Returning -1 for the hashCode has the problem that this will corrupt usage as the hashCode changes when the object is fully initialized.

Member

timowest commented Mar 12, 2014

If understand #676 solve this issue, right?

Both your patch and my commit provide a solution

About the eager solution you mean to calculating hashcode in the constructor?

With eager calculation I mean the calculation in the constructor which has the benefit that the hashCode will be directly available when deserialized, and it will be the correct one.

Returning -1 for the hashCode has the problem that this will corrupt usage as the hashCode changes when the object is fully initialized.

@dmiorandi

This comment has been minimized.

Show comment
Hide comment
@dmiorandi

dmiorandi Mar 12, 2014

Imho, this is a good solution at now.

Imho, this is a good solution at now.

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Mar 24, 2014

Member

Released in 3.3.2

Member

timowest commented Mar 24, 2014

Released in 3.3.2

@timowest timowest closed this Mar 24, 2014

@timowest timowest added this to the 3.3.2 milestone Apr 13, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment