Subclass example:
class SubFoo extends BaseFoo {
public static ReadSerial check(ReadSerial rs){
if (rs.getInt("y") > 128) throw Exception("too big");
return rs;
}
private final int y;
public SubFoo( int x , int y) {
super(x);
this.y = y;
}
public SubFoo( ReadSerial rs ){
super(BaseFoo.check(check(rs)));
// SubFoo can't get at BaseFoo's rs.getInt("x"),
// it's visible only to BaseFoo. Instead SubFoo would get
// the default int value of 0. Just in case both classes have
// private fields named "x".
// ReadSerial is caller sensitive.
this.y = rs.getInt("y");
}
}
Classes in the heirarchy can provide a static method that throws an exception
to check invarients while preventing a finaliser attack. We'd want to check
invarients for other constructors also, but for berevity...
Eg:
class BaseFoo implements Serializable{
public static ReadSerial check(ReadSerial rs) throws Exception
{
if (rs.getInt("x") < 1)
throw IllegalArgumentException("message");
return rs;
}
....
Sent from my Nokia N900.
----- Original message -----
> So, if I understand this correctly, the way this would get used is:
>
> class BaseFoo implements Serializable {
> private final int x;
>
> public BaseFoo(ReadSerial rs) {
> this(rs.getInt("x"));
> }
>
> public BaseFoo(int x) {
> this.x = x;
> }
> }
>
> Right?
>
> What happens with subclasses? I think then I need an extra RS arg in my
> constructors:
>
> class SubFoo extends BaseFoo {
> private final int y;
>
> public SubFoo(ReadSerial rs) {
> this(rs.getInt("y"));
> }
>
> public BaseFoo(ReadSerial rs, int y) {
> super(rs);
> this.y = y;
> }
> }
>
> Is this what you envision?
>
>
>
>
>
> On 12/27/2014 8:03 PM, Peter Firmstone wrote:
> > Is there any interest in developing an explicit API for Serialization?:
> >
> > 1. Use a public constructor signature with a single argument,
> > ReadSerialParameters (read only, writable only by the
> > serialization framework) to recreate objects, subclasses (when
> > permitted) call this first from their own constructor, they have
> > an identical constructor signature. ReadSerialParameters that are
> > null may contain a circular reference and will be available after
> > construction, see #3 below.
> > 2. Use a factory method (defined by an interface) with one parameter,
> > WriteSerialParameters (write only, readable only by the
> > serialization framework), this method can be overridden by
> > subclasses (when permitted)
> > 3. For circular links, a public method (defined by an interface) that
> > accepts one argument, ReadSerialParameters, this method is called
> > after the constructor completes, subclasses overriding this should
> > call the superclass method. If this method is not called, an
> > implementation, if known to possibly contain circular links,
> > should check it has been fully initialized in each object method
> > called.
> > 4. Retains compatibility with current serialization stream format.
> > 5. Each serial field has a name, calling class and object reference,
> > similar to explicitly declaring "private static final
> > ObjectStreamField[] serialPersistentFields ".
> >
> > Benefits:
> >
> > 1. An object's internal form is not publicised.
> > 2. Each class in an object's heirarchy can use a static method to
> > check invarients and throw an exception, prior to
> > java.lang.Object's constructor being called, preventing
> > construction and avoiding finalizer attacks.
> > 3. Final field friendly.
> > 4. Compatible with existing serial form.
> > 5. Flexible serial form evolution.
> > 6. All methods are public and explicitly defined.
> > 7. All class ProtectionDomain's exist in the current execution
> > context, allowing an object to throw a SecurityException before
> > construction.
> > 8. Less susceptible to deserialization attacks.
> >
> > Problems:
> >
> > 1. Implementations cannot be package private or private. Implicit
> > serialization publicises internal form, any thoughts?
> >
> > Recommendations:
> >
> > 1. Create a security check in the serialization framework for
> > implicit serialization, allowing administrators to reduce their
> > deserialization attack surface.
> > 2. For improved security, disallow classes implementing explicit
> > serialization from having static state and static initializer
> > blocks, only allow static methods, this would require complier and
> > verifier changes.
> > 3. Alternative to #2, allow final static fields, but don't allow
> > static initializer blocks or mutable static fields, similar to
> > interfaces.
> >
> > Penny for your thoughts?
> >
> > Regards,
> >
> > Peter Firmstone.
