Javonet 1.3 – Supports Applets, New Data Types, Proxies and Works Faster!

Javonet Goes On-Line

New Javonet version 1.3 has been released. This version has introduced great new possibilities. Javonet has been adjusted to work within Java applets directly from the browser making the impossible possible.

Critical Note

WARNING: While migrating your code from Javonet 1.2 to 1.3 you must modify each place that retrieves decimal value from .NET side to expect BigDecimal instead of Float.

Java Applet Support – Javonet goes to browser!

Since the first version, Javonet has been doing great while bridging Java application with local .NET environment on the hosting machine. Javonet 1.3 goes further, adding support for Java applets.

Starting with version 1.3 Javonet can be used within Java applets directly from Web Browser. Javonet is loaded by Java applet from the browser and utilizes the .NET Framework from the end-user’s computer. In addition to the access to .NET Framework libraries, adding custom .NET DLLs has been made easier – it will be deployed to the end-user temporary folder and loaded by Javonet.

Diagram below depicts the general overview of Java Applets using .NET through Javonet:

Applet Using Javonet Overall Concept Diagram

Keep watching! In upcoming days we will publish new exciting tutorial showing step by step guide how to implement Java Applet using the Javonet solution.

Proxy support for activation

Due to multiple requests to allow activation of Javonet from networks isolated from the internet access through enterprise proxies we have added proxy support to Javonet.

Javonet.Activate method has been extended with three new overloads:

 
activate(String email, String licenceKey, String proxyHost)
activate(String email, String licenceKey, String proxyHost, String proxyUsername, String proxyPassword)
activate(String email, String licenceKey, String proxyHost, String proxyUsername, String proxyPassword, String proxyDomain)

Using these new arguments proxy details, used by Javonet while performing activation, can be specified. Javonet support any HTTP proxy:

• Without authentication
• With authentication
• With authentication based on Active Directory accounts

In proxyHost field hostname and port or ip address and port in standard formats can be specified

• hostname:port
• ip_address:port

New Data Types Support – sbyte, ushort, uint, ulong

Javonet built-in implicit Java to .NET and .NET to Java data types conversion mechanism has been extended to support new .NET types including: sbyte, ushort, uint and ulong.

Javonet 1.3 covers all primitive types from Java and .NET frameworks.

New data types mean that you can easily call methods expecting arguments in these types or set/get values from fields and properties with these types.

Because of the fact that Java does not provide unsigned variables we have introduced new wrapping classes called: NUShort, NUInt and NULong which allow the signaling of the Javonet so that particular corresponding Java type should be converted to these unsigned types on .NET side.

Sample usage:

.NET method:

 
void DotNetMethod(uint arg1, ushort arg2);

Java calling that method:

 
Long arg1 = 1;
Integer arg2 = 2;

obj.Invoke(“DotNetMethod”,new NUInt(arg1), new NUShort(arg2));

You can read more about creating instances of .NET objects and calling methods from Java in our quick start guide: Read More

As you can see in this example all you need to do is wrap Java type with one of the wrapping classes and pass them as the argument to the method. Notice that for NUInt Javonet expects Java Long variable. It is because of the fact that unsigned integer is above the range of Java integer and the type with higher range should be used.

While retrieving values of these types from .NET side, you will receive directly appropriate matching Java type.

Example

 
Long ui = 4294967295L;
sample.set("UIntField", new NUInt(ui));
Long uir = sample.get("UIntField");
System.out.println(uir);

Full data types mapping table has been attached below.

Data Types Improvements – CRITICAL

Several improvements for existing data types conversion has been introduced improving Javonet performance and usability.

The most important difference has been introduced for .NET decimal type. Javonet up to 1.2 (and including) did not provide the way to directly pass decimal to .NET with implicit conversion. Decimal values returned from .NET were implicitly mapped to java.lang.Float variables.

Starting with Javonet 1.3 java.math.BigDecimal has been introduced to support .NET decimal field on Java side. Now both passing and retrieving decimal values requires usage of the BigDecimal variable.

Example

 
BigDecimal f = new BigDecimal("10.5676");
sample.set("DecimalField", f);
BigDecimal val = sample.get("DecimalField");
System.out.println(val);

This change has been introduced to provide more accurate values conversion and precision.

WARNING: While migrating your code from Javonet 1.2 to 1.3 you must modify each place that retrieves decimal value from .NET side to expect BigDecimal instead of Float.

Data Types Conversion Table

Following table represents mapping of .NET to Java types used by built-in implicit data conversion mechanism.

 
In the example below you can see samples of setting and getting values from properties for each of data types with implicit conversion.

.NET Sample Object

 
    public struct TestStruct
    {
        public Decimal DecimalField { get; set; }
        public Double DoubleField { get; set; }
        public float FloatField { get; set; }
        public ushort UShortField { get; set; }
        public uint UIntField { get; set; }
        public ulong ULongField { get; set; }

        public short ShortField { get; set; }
        public int IntField { get; set; }
        public long LongField { get; set; }

        public sbyte SByteField { get; set; }
        public byte ByteField { get; set; }

        public char CharField { get; set; }

        public string StringField { get; set; }

        public bool BoolField { get; set; }
    }

Java usage

 
    NObject sample = Javonet.New("TestStruct");
    
    BigDecimal f = new BigDecimal("10.5676");
    sample.set("DecimalField", f);
    BigDecimal val = sample.get("DecimalField");
    System.out.println(val);
    
    Float f2 = 1543.563f;
    sample.set("FloatField", f2);
    Float val2 = sample.get("FloatField");
    System.out.println(val2);
    
    Double f3 = 1543.56377;
    sample.set("DoubleField", f3);
    Double val3 = sample.get("DoubleField");
    System.out.println(val3);
    
    Integer us = 65535;
    sample.set("UShortField", new NUShort(us));
    Integer usi = sample.get("UShortField");
    System.out.println(usi);
    
    Long ui = 4294967295L;
    sample.set("UIntField", new NUInt(ui));
    Long uir = sample.get("UIntField");
    System.out.println(uir);
    
    BigInteger bi = new BigInteger("18446744073709551615");
    sample.set("ULongField", bi);
    BigInteger bir = sample.get("ULongField");
    System.out.println(bir);
    
    Short s = 32767;
    sample.set("ShortField", s);
    Short sr = sample.get("ShortField");
    System.out.println(sr);
    
    Integer i = 2147483647;
    sample.set("IntField", i);
    Integer ir = sample.get("IntField");
    System.out.println(ir);
    
    Long l = 9223372036854775807L;
    sample.set("LongField", l);
    Long lr = sample.get("LongField");
    System.out.println(lr);
    
    Byte b = 127;
    sample.set("ByteField", b);
    Byte br = sample.get("ByteField");
    System.out.println(br);
    
    byte sb = -128;
    sample.set("SByteField", new NSByte(sb));
    byte sbr = sample.get("SByteField");
    System.out.println(sbr);
    
    char c = 'x';
    sample.set("CharField", c);
    char cr = sample.get("CharField");
    System.out.println(cr);
    
    Boolean bl = true;
    sample.set("BoolField", bl);
    Boolean blr = sample.get("BoolField");
    System.out.println(blr);
    
    String str = "string";
    sample.set("StringField", str);
    String strr = sample.get("StringField");
    System.out.println(strr);

Other Improvements

• BUG: Issues with multi-threaded access to Javonet API have been resolved
• BUG: Byte data type conversion issues have been resolved. Since Javonet 1.3 Java “Byte” variable is implicitly converted to .NET byte (because Java is using signed bytes and .NET is using unsigned bytes – byte values is correctly translated to .NET equivalent)
• BUG: Data types conversion issues caused by different localization settings have been resolved. Since Javonet 1.3 implicit data type conversion is fully locale/culture insensitive
• Javonet execution overhead has been decreased by the average of 3%
• Our Javonet doc files have been updated. Please check: Javonet Docs