Recent changes to feature-requests

Support for Multiple-line comments

Olivier — Mon, 08 Oct 2007 12:12:35 -0000

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

Prepared reflection data supports for Enum

Abdulla(h) Abdurakhmanov — Tue, 11 Sep 2007 19:57:33 -0000

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

Abdulla(h) Abdurakhmanov — Thu, 12 Jul 2007 18:43:42 -0000

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

Grammar cannot handle parameterization

Tomas Carlfalk — Wed, 13 Jun 2007 07:20:48 -0000

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 "...")

Tomas Carlfalk — Wed, 13 Jun 2007 07:14:33 -0000

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()?

John Finley — Thu, 01 Mar 2007 21:09:17 -0000

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

Anonymous — Wed, 24 Jan 2007 20:40:20 -0000

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.

John Finley — Thu, 07 Dec 2006 21:42:37 -0000

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