-
Enhancement
-
Resolution: Fixed
-
P3
-
1.4.0
-
None
-
beta
-
sparc
-
solaris_7
javax.print provides java classes to represent printing attributes
such as "number of copies". This design is used to facilitate an
extensible API by adding new attribute classes and collecting these
and standard attributes classes together to form a job specification,
or printer state description.
Many of these attributes should be made "final" classes.
Subclassing standard attribute classes is useful where the attribute
represents an set or enumeration of values which may have additional
values beyond those enumerated in the standard API.
However attributes representing integers, strings etc are not useful to
subclass, since all possible values can be represented with the
provided implementations.
Additionally a few enumeration types which represent
the closure of all possible values (boolean types) are also not
appropriate for subclassing.
By making these classes final we can in some cases use more
efficient implementations, and lock out unintended subclassing.
Also we can always compatibly remove the "final" modifier
in a future release for any classes for which a legitimate use of
subclassing is identified.
such as "number of copies". This design is used to facilitate an
extensible API by adding new attribute classes and collecting these
and standard attributes classes together to form a job specification,
or printer state description.
Many of these attributes should be made "final" classes.
Subclassing standard attribute classes is useful where the attribute
represents an set or enumeration of values which may have additional
values beyond those enumerated in the standard API.
However attributes representing integers, strings etc are not useful to
subclass, since all possible values can be represented with the
provided implementations.
Additionally a few enumeration types which represent
the closure of all possible values (boolean types) are also not
appropriate for subclassing.
By making these classes final we can in some cases use more
efficient implementations, and lock out unintended subclassing.
Also we can always compatibly remove the "final" modifier
in a future release for any classes for which a legitimate use of
subclassing is identified.