ASN.1 Basic Encoding Rules implementation. Only the BER are implemented. This is not an implementation of ASN.1, such as an ASN.1 compiler or runtime. It could be used as the core of an ASN.1 runtime.
BigInteger
)InputStream
or Reader
and an
Enumeration
(of BerObject
s), respectively.
I strongly considered introducing BER streams for reading and
writing rather than using methods (BerObject.writeTo
and BerModule.readFrom
) that take streams as arguments.
The pros of having specialized BER streams are that they would be
more natural for Java programmers, and they allow multiple
character encodings to be used for a given module. The cons are that
client code would need to pass around BER streams rather than
passing around more generic Java streams, the added complexity
(the BER stream classes wouldn't replace any existing classes) and
the question of what kind of streams they should be. The obvious
choices for input are to extend InputStream
or to
implement DataInput
or ObjectInput
, with
the corresponding choices for output.
I think that in the end only InputStream
makes sense.
What we would want from readBoolean
is that it read a
BER-encoded BOOLEAN, not a Java boolean
. We couldn't
implement the implicit contract of DataInput
, though
we may be able to implement its method signatures.
As it happens, one of our uses of the BER classes reads from sockets
that have been wrapped in a BufferedInputStream
. From
that it reads both Java primitives and BER-encoded objects using a
DataInputStream
. This shared DataInputStream
implementation would not be possible with BER streams, though any
implementation of BER streams should, in my opinion, be usable in cases
where some bytes may be read from the stream using other encodings,
such as those of DataInput
, via other stream wrapper objects
wrapping the same underlying stream.
If BER streams are introduced, the basic changes would be as follows:
BerModule
and a character encoding as constructor arguments. (The
BerModule
is not strictly required for the output
stream, but I think being able to restrict the BER types that
may be written to those defined in a module is a nice-to-have
feature.)BerObject
methods gReadLength
,
gWriteLength
, and writeTo
and the
BerModule
method readFrom
move to the
appropriate stream class.BerContentsInputStream
would naturally, though
not necessarily, extend BerInputStream
.Note that it would certainly be possible to introduce the BER streams on top of the existing implementation, without interferring with existing client code.
BerTypes
The constants of BerTypes
may more properly belong in
BerIdentifier
. Perhaps BerIdentifier
should
implement BerTypes
and the latter be deprecated for use
from outside the package.
Copyright 1999 Vizdom Software, Inc. All Rights Reserved.
This program is free software; you can redistribute it and/or modify it under the same terms as the Perl Kit, namely, under the terms of either:
- the GNU General Public License as published by the Free Software Foundation; either version 1 of the License, or (at your option) any later version, or
- the "Artistic License" that comes with the Perl Kit.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See either the GNU General Public License or the Artistic License for more details.