Browse Prior Art Database

Automatic Java proxy creation for .NET assemblies at build-time and run-time Disclosure Number: IPCOM000126804D
Original Publication Date: 2005-Aug-02
Included in the Prior Art Database: 2005-Aug-02
Document File: 2 page(s) / 44K

Publishing Venue



This paper describes a way of developing a Java* application for multi-platform deployment with transparent access to platform native libraries

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Automatic Java proxy creation for .NET assemblies at build-time and run-time

When developing a Java* application for multi-platform development the application may need to use libraries that are native to the target deployment platform. For example, there are times when a developer will need to use an assembly that is native to .NET to support .NET specific features. The developer can write .NET assemblies to be invoked by the Java application using JNI, but this is prone to errors, is time consuming and is not automated. The original Java source code needs to be able to be compiled, and the native library accessed at runtime.

At development time one of the following procedures can be followed: A .NET assembly can be run through a tool to create a Java wrapper for each type in the .NET assembly. These wrappers will be used to compile the Java application.

The application is coded to use reflection to access the types, and so the
.NET assembly does not need to be run through a tool.

The .NET assembly implements an equivalent set of types as existing Java libraries (this most often occurs through a factory pattern where implementation is independent of implementation and the factory is used to create the instances). No tool is required.

At runtime the Java application will access a type in that is implemented in a .NET assembly. A class loader will load the assembly and create a dynamic proxy through which the .NET type can be accessed. This enables a Java developer access to
.NET assemblies. The advantage to alternative of using JNI is that this process can be automated and does not require the application developer to develop source code to access the types held in the .NET assemblies. In contrast to generating the proxies at development time, this invention also provides access to dynamically loading types from .NET assemblies which have not been statically linked, and also provides for deployment time decisions as to the implementation libraries (Java or
.NET) to be used at runtime.

    The application will consist of a set of classes, including one with a main() method which is the entry point to the application (this is standard Java).

At runtime the following processes will occur:

Invoke the JVM passing: a wrapper class...