Recent changes to feature-requests

Support for Multiple-line comments

2007-10-08T12:12:35Z

ASN.1 2002 introduced Multiple-line comments using "/*" "*/" pairs. BN1.5.1 doesn't support this notation.

Prepared reflection data supports for Enum

2007-09-11T19:57:33Z

The enumeration encoding/decoding is not supported prepared data feature and had a performance troubles.
This is must be fixed in 1.5.2.

ObjectIdentifier datatype support

2007-07-12T18:43:42Z

We are need to the OID support for version 1.5 for Java/.NET.

Grammar cannot handle parameterization

2007-06-13T07:20:48Z

Example:

MyString{INTEGER:maxSize} ::= CHOICE {
utf8 UTF8String(SIZE(0..maxSize)),
bmp BMPString(SIZE(0..maxSize))
}

compiler gives:

line 104:1: unexpected token: MyString
line 104:25: unexpected token: }
line 104:31: unexpected token: CHOICE
java.lang.NullPointerException

Grammar cannot handle ellipsis (extension marker "...")

2007-06-13T07:14:33Z

ASN.1 syntax allows to design SEQUENCE:s and CHOICE:s for extendability by using the extension marker "...".

This is not supported in BNotes. Example:

ExtendableSeq ::= SEQUENCE {
a INTEGER (0..31),
b INTEGER (0..15),
...
}

Comiler gives:

line 107:3: unexpected token: ...

Bug in BitString.getLength()?

2007-03-01T21:09:17Z

Hi Abdulla,

I think there's a bug in BitString.getLength().

public int getLength() {
return bitStrValue.length;
}

Shouldn't this be:

public int getLength() {
return bitStrValue.length * 8 - trailBitsCnt;
}

Or am I confused?

Regards,
John

Additional C# type support

2007-01-24T20:40:20Z

I am trying to add byte and enum properties to my class.

I didn't realize that there was an ASN1Enum attribute, I figured that this would be implicit CS element, but it is not.

Also, I would like byte to be a valid type, currently only int and long are supported.

I added the following code to make this work:

Encoder.cs, encodeCSElement method

if (obj.GetType().IsEnum)
{
System.Type declaringType = System.Enum.GetUnderlyingType(obj.GetType());
if (declaringType == typeof(long))
{
return encodeInteger((long) obj, stream, info);
}
else if (declaringType == typeof(int))
{
return encodeInteger((int) obj, stream, info);
}
else if (declaringType == typeof(byte))
{
return encodeInteger((byte) obj, stream, info);
}
else
{
return 0;
}

Similar code is required for decoding.

-Chris Peterson

Encoding/decoding performance issues.

2006-12-07T21:42:37Z

Hi Abdullah,

I've run into some performance bottlenecks with the encoders and decoders. The problem seems to be that they rely heavily on java reflection, particularly reflection on annotations, and this is really slow! I've attached an example that generates java hprof output to demonstrate this.

I've also prototyped some workarounds that demonstrate a noticable improvement when reflection is minimized.

I believe the performance of the encoders and decoders could be orders of magnitude faster if the reliance on annotations was removed, although I recognize that this is no small undertaking.

Would it be possible to replace the class and field annotations with static class members? These could
be accessed by the coders with almost no overhead.

Regards,
John