Gaurav Seth's WebLog : JLCA

.NET Vs J2EE: How do we compare

GauravS — Thu, 10 May 2007 14:21:00 GMT

A customer recently wrote the following to us-

My organization is currently considering either .NET or Java (J2EE) as our enterprise application development platform.

I am sold on .NET as I believe that:-

· There are cheaper resources (per hour rate) and large vendor/contractor providers

· It quicker to develop applications with .NETusing either Visual Studio or Web Express

· Tools are free

· Strong technical community (MSDN).

He needed facts, independent white papers to confirm the findings.

Here is a link to Competitive Reports and Evidence: Comparing .NET to J2EE. This site contains extensive materials designed to help users evaluate Microsoft .NET vs. J2EE application server technologies. Each area contains downloadable whitepapers, benchmark comparisons, and sample source code (including studies by independent parties like Forrester)

The website Resources for Java Developers contains the above and more sections.

In case you know of more resources, feel free to add.

JLCA 3.0 – A Perspective: Cheat Sheet unleashed

GauravS — Mon, 19 Jun 2006 09:05:00 GMT

As I promised, I have posted the JLCA 3.0 cheat sheet for the users on my Blogs. The aim of this exercise has been for the JLCA users to understand the conversion process using the Java Language Conversion Assistant 3.0 and the issues they might face during the conversion process. Here is the TOC of the Cheat Sheet.

Introduction

Java Language Conversion Assistant (JLCA henceforth) is a tool that provides support for the conversion of software written in VJ++ and Java to Microsoft’s Visual C# .NET and .NET Framework. JLCA 3.0 is the latest version of the tool. It supports conversion of a majority of Java’s APIs and Java technologies supported by J2SE 1.3 and J2EE 1.3. It also addresses important issues of reducing the compilation errors and improving the conversion coverage and user experience as compared to the previous versions of the tool.

INTRODUCTION

J2SE AND J2EE COVERAGE

· J2SE 1.3 BASIC FEATURES

· J2SE 1.3 JAVA FOUNDATION CLASSES (JFC)

· J2EE 1.3 FEATURES

JLCA 3.0

· JAVA APIs CONVERSION

· JAVA TECHNOLOGIES CONVERSION

o Java Beans

o Enterprise Java Beans (EJBs)

o Common Object Request Broker Architecture (CORBA)

- CORBA – Dealing with other languages

o Remote Method Invocation (RMI and RMI-IIOP)

o Java Messaging Service (JMS)

o Serialization

o Java Accessibility (JAAPI)

o Java Event Model (AWT and Swing)

o Threads

· USABILITY FEATURES

o Visual Studio .NET Designer Compliant

o JLCA Extensibility Compliant

In case you have any comments you may write back to me.

JLCA 3.0 - Usability Features

GauravS — Mon, 19 Jun 2006 08:49:00 GMT

JLCA 3.0 includes a new set of features to improve the tool’s usability. Special source code analysis has enabled this version to produce better converted code and could produce customized converted code. These new features are the following:

Visual Studio .NET Designer Compliant

Usually, as many development environments, Java IDEs provide designer tools to facilitate/automate the visual component’s programming (like forms, panels and controls). These tools generate visual code with some characteristics that allow the tool to “interpret” and visualize it in an interactive manner. Previous versions of JLCA does support the conversion of visual applications to produce converted code compliant with MS Visual Studio .NET Designer.

JLCA 3.0 converts Java applications supported by a designer and preserves the design support in Visual Studio .NET Designer. Specific recognizing and analysis are performed to achieve this issue. JLCA supports a designer-compliant conversion that only visual components written in designer tools of the following IDEs: Microsoft J++ 6.0, IBM WebSphere Application Developer and JBuilder.

The analysis made over Java’s visual applications automatically generated by the mentioned IDEs allows to produce target code compliant with MS Visual Studio .NET Designer. In this sense, the converted code preserves the design-time maintainability enabled in the Java application. Further, this improves tool usability and maintenance productivity.

However, since JBuilder designer tool is more flexible than .NET designer (for instance, it can “interpret” at design-time not only automatically-generated code), there are some restrictions to this feature. Although it is not the Java’s most common scenario, JLCA 3.0 warns when parts of code -non compliant with .NET designer- could not be targeted as expected.

Table 33 and Table 34 show the most relevant details about converting visual applications to be supported by Visual Studio .NET Designer. In a summarized manner, they enunciate the design-time features -supported by Visual Studio .NET- preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting visual applications enabled for design-time support.

Coverage Details

Java Design-Time Support	JLCA 3.0 Coverage	Description
Custom Visual Components	Converted	User components extending from Java’s converted widgets (AWT and Swing) preserve design-time support. Design-time support for overloading is often converted.
Different IDEs	Converted	JLCA 3.0 enables Microsoft Visual Studio .NET design-time support in applications written in Microsoft J++ 6.0, IBM WebSphere Application Developer and JBuilder. Because of JBuilder’s designer is very flexible, support is limited. Only Java code recognized by designer tools of these IDEs preserves design-time support.
Visual Components And Applets	Converted	Design-time supports for most of converted visual components. Converted AWT and Swing components take the advantage of System.Windows.Forms widgets. Applets are converted to UserControls.
Visual Properties And Events	Converted	Converted widget properties settings preserve design-time support. Conversion is achieved for settings having literal or constant values. Also, the majority of converted events for visual components preserve design-time support.

Table 33: Visual Studio .NET Designer Compliance Coverage

Issues

Issue

Description

Code Not Compliant For

Visual Studio .NET Designer

JLCA 3.0 preserves design-time functionality only for converted components with settings that could be recognized by VS.NET designer. In the conversion of any control, it tries to determine which settings would be supported by the target designer. So, it moves to method “InitializeComponent” only this kind of code. However, components or unsupported settings (without literal or constant values) are left in the place they were. In this case, JLCA warns the user about this situation.

A workaround could require user-intervention to determine a correct value for .NET Framework designer and move the respective initialization to “InitializeComponent”. Another option could be to disable the special conversion made to preserve design-time support.

Since JLCA realizes code movements (only for compliant code) but it leaves -in the original place- the non-compliant code, this could cause different behavior because of the instructions execution order. So, the converted application could require a review of the JLCA warnings about non-moved code and determine whether exist different behavior.

Disabling Conversion to Code Compliant With Visual Studio .NET

Ideally, source applications with design-time support are desired to preserve this characteristic through the conversion.

There could be applications in which there is no need to preserve it or the converted code is so confusing as it has many problems with code not compliant for the target designer.

An option could be disable this special conversion. It could be achieved by renaming –inside all the source code of visual components- the special Java method in charge of managing the Java design-time supports (an initializations method). The method name changes between IDEs. Thus, in MS J++ this method is named as “initForm”; in IBM WebSphere is “initialize” and; in JBuilder is “jbInit”.

General Issues And

Visual Studio .NET Designer

Compliant Code

This feature is highly-dependant on the successful conversion achieved for the different Java’s widgets.

On the other hand, supported IDEs produce Java code placing –by convention- the settings inside a common routine. VS.NET design-time support is based on method InitializeComponent which contains the creation and settings for the widgets. It only supports property settings specified in using literal or constants.

Since conversion is not always achieved for all Java’s widgets and properties and, since VS.NET Designer does not support all the Java code supported by Java IDEs, special analysis is made to decide and move -to the target method InitializeComponent- the converted Java code that could be recognized by VS.NET Designer. When it cannot be recognized, JLCA warns the user to consider the problem.

Layout Management

Majority of Java’s Layout Managers are not converted as .NET has no direct equivalent. JLCA only converts FlowLayout and GridLayout through properties Dock and Anchor. So, design-time support for visual components using layout managers is very limited. However, this issue overcomes the scope of this feature.

A workaround could consider redesigning the target application to adapt it for .NET’s layout capabilities or use a .NET third party library for layout management.

Visual Components Not Converted

As any designer tool, VS.NET cannot recognize unsupported or unnecessary Java code. Since conversion is not always achieved for all Java’s widgets and properties, applications with unconverted visual code are unable to be displayed at design-time.

A workaround could require a review of the JLCA warning corresponding to the unconverted element in order to decide what to do (there are cases in which this code is unnecessary and thus, could be ignored).

Table 34: Visual Studio .NET Designer Compliance Issues

JLCA Extensibility Compliant

Using previous versions of JLCA, the conversion of J2EE third-party components or other Java extensions could be frustrating in the sense of the manual changes required to convert these components to equivalent components of the .NET framework or from third-parties, too. Now, JLCA 3.0 functionality could be extended –in an ad-hoc manner- by adding transformation rules to convert new or not supported APIs by JLCA (mappings). These rules must be created and specified using JLCA Companion, a product seamlessly integrated with Microsoft Visual Studio .NET and JLCA 3.0. Also, these rules –better referred as custom mappings- can either add support to redefine existing transformations already bundled within JLCA.

This makes it possible to increase the percentage of automated conversion for your specific application. Using the JLCA Companion with JLCA 3.0 can dramatically shorten conversion timeframes by eliminating much of the need to manually rewrite unsupported portions of the application. The JLCA Companion is sold and supported by Artinsoft.

Next section and Table 3 Shows the most relevant details about the extensibility support bundled in JLCA 3.0. In a summarized manner, they enunciate the extensibility features and they suggest the issues the user should take care while using JLCA Extensibility. This section won’t give specific details about JLCA Companion and the ways to define the transformation rules (or custom mappings). Mainly, this section refers to the extensibility support included in JLCA 3.0 (which is achieved through JLCA Companion). Other resources -explaining details about JLCA Companion- could be downloaded from Artinsoft web-site and JLCA Companion documentation.

Coverage Details

Extensibility is performed through transformation rules applied in a member-level fashion. These transformation rules are designed to achieve automatic conversion in non-converted Java’s APIs or third party components. Also, they can be used to override the JLCA behavior in converted APIs. Since some components in .NET framework does not behaves in the same manner of Java’s ones (by example, Swing’s), this could be useful to map already converted Java APIs to more equivalent .NET Framework components from third parties.

Transformation rules are similar to entries in a dictionary. When JLCA is analyzing the Java code, it identifies syntax elements and decomposes the expression into basic elements. Elements corresponding to API or third party members are converted looking up in the conversion dictionary. The conversion dictionary contains the entries for already supported members.

When using JLCA extensibility capabilities (through JLCA Companion) you set a broader base of entries for the conversion tool to work with. Each entry is defined and looked up using the respective element’s complete name and signature.

Extensibility support covers the automatic conversion in the following areas:

Type References: rules to convert references to classes and interfaces.

Constructors and Methods: rules to convert invocations and declarations of constructors/methods.

Fields: rules to convert field references.

Issues

Issue	Description
Custom Conversion Correctness	JLCA does not verify whether the target code is correct. When JLCA Companion builds the transformation rules, it realizes a shallow checking following the target language syntax. It verifies neither the type correctness nor the semantics. JLCA assumes as valid the user-programmed transformation rule. Dealing with semantic and syntax problems requires to review and redefine the transformation rule.
Disabling JLCA Extensibility Support	A command line switch is included in JLCA to be specified at the conversion time if custom mappings should be loaded (applied) or not. JLCA default behavior is to enable extensibility support. The option to exclude custom mappings is /NoExtensibility. This could be used to easily compare transformations with or without transformation rules assemblies. Also, this could be used to allow specific conversions to ignore the applying of custom mappings.
Enabling .NET Third Party Libraries	Conversion of Java code ported to .NET Framework third party libraries requires user intervention to install these libraries in the development machines (to compile the target code). Additionally, the target VS.NET projects require adding the references to these libraries.
Rules Reutilization and Portability	Transformation rules must be defined and compiled using JLCA Companion. Successful compilation will add these rules to JLCA rules base. Using these rules in other machines with JLCA 3.0 could be achieved in two ways: re-compile the transformation rules in these machines or copy the corresponding output assembly (previously compiled) to these machines. This assembly must be specified on every JLCA Companion project and it is placed in the JLCA installation directory named as “Maps”.
Transformation Rules Design and Coding	Coding the transformation rules require analyze/test the functionality, behavior, hierarchy and similarity between the source and targeting APIs. Depending of the degree of equivalence provided by the target API, the porting –through JLCA Companion’s transformation rules- is feasible. However, there could be cases where the target API provides a similar functionality but in a different way. A workaround could involve to design and code components exposing a similar interface of the Java’s. Thus, the target components could be coded by the user and they could be wrapping the underlying target API. In this manner, the transformation rules would be coded like mappings in a one-to-one style.

Table 35: Extensibility Support Issues

JLCA 3.0 - Threads

GauravS — Fri, 16 Jun 2006 15:53:00 GMT

In Java, there are two ways to create a new thread of execution. One is to declare a class inheriting java.lang.Thread and overriding the method run(). The other way is to create a class implementing java.lang.Runnable and passing it to a new instance of java.lang.Thread. Java Threads are mainly converted to .NET framework through System.Threading API.

JLCA 3.0 takes into account the following Java Threading features: Thread subclassing, Thread Runnable implementation, Thread Priorities and Thread Synchronization.

Table 31 and Table 32 show the most relevant details about Java Threads conversion. In a summarized manner, they enunciate the Java Threads features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting applications using threads.

Coverage Details

Java Threads	JLCA 3.0 Coverage	Description
Runnable Implementation	Converted	Java threads performed by implementing interface java.lang.Runnable are converted to .NET Framework through a Compatibility Interface (SupportClass).
Thread Groups	Not Converted	Thread Groups are not converted to .NET Framework as .NET Framework does not provide an equivalent to manage threads hierarchies, groups and relationships. A workaround could require adapting the converted application to use the most likely .NET Framework features such as Thread Pools (System.Threading.ThreadPool).
Thread Inheritance	Converted	Java threads performed by inheriting class java.lang.Thread are converted to .NET through a Compatibility Class (SupportClass). A majority of thread’s features are converted to .NET Framework.
Thread Priorities	Converted	Thread Priorities are converted to enum System.Threading.ThreadPriority.
Thread Synchronization	Converted	Thread Synchronization performed by java.lang.Object’s method such as notify, notifyAll and wait, and by synchronized method is converted to .NET Framework through class System.Threading.Monitor and lock statement.

Table 31: Java Threads Conversion Coverage

Issues

Issue	Description
Checking whether a Thread Is Interrupted	Checks around whether a thread that has been interrupted is converted to .NET or not[ME1] . However, a workaround could involve the use of property System.Threading.Thread.ThreadState.
General Issues	Java Threads are converted to .NET Framework through API System.Threading. Most of features of Java threads are converted to .NET Framework. The functionality not converted could require the use of the documentation of JLCA warnings.
Thread Groups	Most of the functionality related with Thread Groups is not converted as .NET Framework does not provide a similar one. A workaround could require adapting the converted application to use the most likely features of .NET Framework such as Thread Pools (System.Threading.ThreadPool).

Table 32: Java Threads Conversion Issues

[ME1]By???

JLCA 3.0 - Java Event Model (AWT and Swing)

GauravS — Thu, 15 Jun 2006 15:10:00 GMT

Java Event Model mechanism is primarily featured by listeners and adapters used to deal with the different types of events fired by AWT, Swing of the user himself. Most of Swing components use new event types and listeners. Java Event Model is mainly converted through towards .NET Framework event delegation model inherent in System.Windows.Forms and System.ComponentModel APIs and, .NET Framework Classes such as System.EventHandler and System.EventArgs.

JLCA 3.0 main conversion about AWT and Swing events takes into account: Most of the Java API Listeners and Adapters in AWT (some in Swing), DragAndDrop Operations and Custom User Events.

Table 27,Table 28,Table 29 and Table 30 show the most relevant details about Java’s Event Model conversion. In a summarized manner, they enunciate the Java Event Model features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting applications using events.

Coverage Details

Class / Interface in Package java.awt.event	Functionality	JLCA 3.0 Coverage	Description
ActionEvent ActionListener	ActionEvent indicates when a component-defined action occurred. ActionListener is the listener interface for receiving action events.	Converted	Converted to System.Windows.Forms.Button.Click, System.Windows.Forms.TextBox.KeyPress, System.Windows.Forms.ListBox.DoubleClick and System.Windows.Forms.MenuItem.Click.
ActiveEvent	This is the interface for events that know how dispatch themselves.	Not Converted	These events have no equivalent in .NET Framework.
AdjustmentEvent AdjustmentListener	AdjustmentEvent is the event emitted by Adjustable objects. AdjustmentListener is the listener interface for receiving adjustment events.	Converted	Converted to System.Windows.Forms.Scrollbar.Scroll.
ComponentEvent ComponentAdapter ComponentListener	ComponentEvent indicates that a component moved, changed size, or changed visibility. ComponentAdapter & ComponentListener are adapter and listener for receiving componentevents.	Converted	Converted to System.Windows.Forms.Control.Resize, System.Windows.Forms.Control.Move and System.Windows.Forms.Control.VisibleChanged.
ContainerEvent ContainerAdapter ContainerListener	ContainerEvent indicates when a component was added or removed. ContainerAdapter & ContainerListener are adapter and listener for receiving containerevents.	Converted	Converted to System.Windows.Forms.ContainerControl.ControlAdded and System.Windows.Forms.ContainerControl.ControlRemoved
FocusEvent FocusAdapter FocusListener	FocusEvent indicates that a Component has gained or lost the input focus. FocusAdapter & FocusListener are Adapter and listener for receiving keyboard focus events on a component.	Converted	Converted to System.Windows.Forms.Control.Enter and System.Windows.Forms.Control.Leave.
HierarchyBoundsAdapter HierarchyBoundsListener	These are adapter class and listener interface for receiving ancestor moved and resized events.	Not Converted	These events have no equivalent in .NET Framework.
HierarchyEvent HierarchyListener	These are event and listener for change to hierarchy of component occurs.	Not Converted	These events have no equivalent in .NET Framework.
InputEvent	This is the root event class for all component-level input events.	Not Converted	These events have no equivalent in .NET Framework.
InputMethodEvent InputMethodListener	InputMethodEvent contain information about text that is being composed using an input method. InputMethodListener is the listener interface for receiving input method events.	Not Converted	These events have no equivalent in .NET Framework.
InvocationEvent	This executes the run() method on a Runnable when dispatched by the AWT event dispatcher thread.	Not Converted	These events have no equivalent in .NET Framework.
ItemEvent ItemListener	ItemEvent indicates that an item is selected or deselected. ItemListener is the listener interface for receiving item events.	Converted	Converted to System.Windows.Forms.CheckBox.Click System.Windows.Forms.MenuItem.Click and System.Windows.Forms.ListBox.SelectedIndexChanged.
KeyEvent KeyListener	KeyEvent indicates that a keystroke occurred in a component. KeyListener is the listener interface for receiving keyboard events.	Converted	Converted to System.Windows.Forms.Control.KeyPress, System.Windows.Forms.Control.KeyDown and System.Windows.Forms.Control.KeyUp.
MouseEvent MouseListener MouseMotionAdapter MouseMotionListener	MouseEvent indicates that a mouse action occurred in a component. MouseListener is the listener interface for receiving mouse events. MouseMotionAdapter & MouseMotionListener are the adapter and listener for receiving mouse motion events.	Converted	Converted to System.Windows.Forms.Control.Click, System.Windows.Forms.Control.MouseEnter, System.Windows.Forms.Control.MouseLeave, System.Windows.Forms.Control.MouseMove, System.Windows.Forms.Control.MouseDown and System.Windows.Forms.Control.MouseUp.
TextEvent TextListener	TextEvent indicates that an object's text changed. TextListener is the listener interface for receiving text events.	Converted	Ported to System.Windows.Forms.TextBox.TextChanged.
WindowEvent WindowAdapter WindowListener	WindowEvent indicates that a window has changed its status. WindowAdapter & WindowListener are the adapter and listener for receiving window events.	Converted	Converted to System.Windows.Forms.Form.Load, System.Windows.Forms.Form.Activated, System.Windows.Forms.Form.Deactivated, System.Windows.Forms.Form.Closed and System.Windows.Forms.Form.Closing.

Table 27: Java Event Model Conversion Coverage (1) – Package java.awt.event

Class / Interface in Package java.awt.dnd	Functionality	JLCA 3.0 Coverage	Description
AutoScroll	Interface that provides auto scrolling facility.	Not Converted	It is not converted to .NET Framework as the auto-scrolling is managed implicitly in .NET Framework.
DnDConstants	Contains constant values representing the type of action(s) to be performed by a Drag and Drop operation.	Converted	Converted to System.Windows.Forms.DragDropEffects.
DragGestureEvent DragGestureListener	DragGestureEvent occurs when a particular DragGestureRecognizer detects that a platform dependent drag initiating gesture has occurred on the Component. DragGestureListener is invoked when an object of that class detects a drag initiating gesture.	Partially Converted	Core Functionality achieved through DragSource is converted. Advanced functionality is not converted as .NET Framework does not have its equivalent.
DragGestureRecognizer MouseDragGestureRecognizer	This is an abstract base class for the specification of a platform-dependent listener that can be associated with a particular Component in order to identify platform-dependent drag initiating gestures.	Not Converted	It is not converted to .NET Framework as similar functionality is not available in .NET Framework.
DragSource DragSourceContext DragSourceDragEvent DragSourceDropEvent DragSourceEvent DragSourceListener	DragSource is responsible for the initiation of the Drag and Drop operation. DragSourceContext is responsible for managing the initiator side of the Drag and Drop protocol. DragSourceEvent is the base class for DragSourceDrag Event and DragSourceDrop Event. DragSourceListener is the event interface for originators of Drag and Drop operations to track the state of the user's gesture, and to provide appropriate "drag over" feedback to the user throughout the Drag and Drop operation.	Partially Converted	Core functionality exposed by these components is converted to .NET Framework. Since Drag n Drop is managed in a different way in .NET Framework, there is no equivalent for these classes but, the functionality is converted to .NET Framework’s Drag n Drop.
DropTarget DropTargetContext DropTargetDragEvent DropTargetDropEvent DropTargetEvent DropTargetListener	These are associated with a Component when that Component wishes to accept drops during Drag and Drop operations.	Partially Converted	Core functionality exposed by these components is converted to .NET Framework. Operations like dragEnter, dragOver, dragExit and drop are being converted.
InvalidDnDOperationException	This is thrown by various methods in the java.awt.dnd package.	Converted	It is converted to a more general exception (System.Exception) since there is no direct equivalent in .NET Framework.

Table 28: Java Event Model Conversion Coverage (2) – Package java.awt.dnd

Class / Interface in Package javax.swing.event

Functionality

JLCA 3.0 Coverage

Description

AncestorEvent

AncestorListener

AncestorEvent occurs when there is a change to ancestor happens.

AncestorListener listens for AncestorEvent.

Not Converted

These have no equivalent in .NET Framework.

CaretEvent

CaretListener

CaretEvent occurs when text caret has changed.

CaretListener listens for changes in the caret position of a text component.

Not Converted

These have no equivalent in .NET Framework.

ChangeEvent

ChangeListener

ChangeEvent occurs when state has changed in the event source.

ChangeListener listens for ChangeEvents.

Partially Converted

Only JSlider and JTabbedPane are converted to System.Windows.Forms.TrackBar.ValueChanged and System.Windows.Forms.TabControl.SelectedIndexChanged.

HyperlinkEvent

HyperlinkListener

HyperlinkEvent occurs when something has happened with respect to a hypertext link.

HyperlinkListener listens for HyperlinkEvent

Partially Converted

Only JEditorPane is converted to System.Windows.Forms.RichTextBox.LinkClicked.

InternalFrameEvent

InternalFrameListener

InternalFrameEvent adds support for JInternalFrame objects as the event source.

InternalFrameListener is the listener interface for receiving internal frame events.

Partially

Converted

JInternalFrame is converted. Messages Deiconified and Iconified are not supported.

javax.swing.Action

Action interface provides a useful extension to the ActionListener interface in cases where the same functionality may be accessed by several controls.

Partially

Converted

Only actionPerformed is converted.

ListDataEvent

ListDataListener

ListDataEvent occurs when list changes.

ListDataListener listens for changes in list.

Not Converted

These have no equivalent in .NET Framework.

ListSelectionEvent

ListSelectionListener

ListSelectionEvent occurs when a change in the current selection occurs.

ListSelectionListener listens for lists selection value changes.

Partially

Converted

Only JList is converted to System.Windows.Forms.ListBox.SelectedValueChanged.

MenuDragMouseEvent

MenuDragMouseListener

MenuDragMouseEvent occurs when menu element has received a MouseEvent under drag conditions.

MenuDragMouseListener listens for MenuDragMouseEvent.

Not Converted

These have no equivalent in .NET Framework.

MenuEvent

MenuListener

MenuEvent occurs when a menu has been posted or selected or canceled.

MenuListener listener for menu events.

Partially Converted

JMenu (message Selected) is converted to System.Windows.Forms.MenuItem.Select.

MenuKeyEvent

MenuKeyListener

MenuKeyEvent occurs when menu element has received a KeyEvent forwarded to it in a menu tree.

MenuKeyListener listens for MenuKeyListener.

Not Converted

These have no equivalent in .NET Framework.

PopupMenuEvent

PopupMenuListener

PopupMenuEvent occurs with regarding to JPopupMenu.

PopupMenuListener listens for PopupMenuEvent.

Partially

Converted

JPopupMenu is converted to System.Windows.Forms.ContextMenu.Popup (message WillBecomeVisible)

PropertyChangeEvent

PropertyChangeListener

PropertyChangeEvent occurs whenever a bean changes a "bound" or "constrained" property.

PropertyChangeListener listens for PropertyChangeEvent.

Not Converted

These have no equivalent in .NET Framework.

TableColumnModelEvent

TableColumnModelListener

TableColumnModelEvent occurs when a table column has been added or moved or removed.

TableColumnModelListener listens to changes in a TableColumnModel.

Partially

Converted

Only converted for messages Added/Removed to System.Data.DataColumnCollection.CollectionChanged.

TableModelEvent

TableModelListener

TableModelEvent occurs when a table model has changed.

TableModelListener listens to changes in a Table Model.

Converted

AbstractTableModel is converted to System.Data.DataTable.RowChanged.

TreeExpansionEvent

TreeExpansionListener

TreeExpansionEventoccurs when a tree expands or collapses a node.

TreeExpansionListener listens for TreeExpansionEvent.

Converted

Converted to System.Windows.Forms.TreeView.BeforeExpand,

System.Windows.Forms.TreeView.BeforeCollapse,

System.Windows.Forms.TreeView.AfterExpand and

System.Windows.Forms.TreeView.AfterCollapse.

TreeModelEvent

TreeModelListener

TreeModelEvent occurs when tree model has changed.

TreeModelListener listens to changes in a TreeModel.

Not Converted

These have no equivalent in .NET Framework.

TreeSelectionEvent

TreeSelectionListener

TreeSelectionEvent occurs when the selection in a TreeSelectionModel changes.

TreeSelectionListener listens for TreeSelectionEvent.

Converted

JTree is converted through System.Windows.Forms.TreeView.AfterSelect.

UndoableEditEvent

UndoableEditListener

UndoableEditEvent occurs when operation that can be undone has occurred.

UndoableEditListener listens for undoable operations.

Not Converted

These have no equivalent in .NET Framework.

Table 29: Java Event Model Conversion Coverage (3) – Package javax.swing.event

Issues

Issue

Description

Events Equivalence And

Event Handling Behavior

In some cases, Java’s events behave differently to .NET Framework’s equivalent ones in the sense: the events are fired and handled on corresponding controls. So, the behavior of converted applications could be different since the status of the .NET Framework controls slightly differs.

Thus, the stabilization of converted applications –in event handling issues- could require reviewing the .NET framework documentation to learn about the specific events used on the application, their collateral effects and the way they are fired and handled on respective controls.

EventObject.getSource()

In Java, the use of method java.util.EventObject.getSource() is to identify the event firing a component.

In .NET Framework, the sender of the event is passed as parameter to the event handling method.

Invocations to getSource() are converted only within event-handling methods (in Java, listener’s methods).

So, conversion for method getSource() could require user-intervention if it is up to 2 level of depth. A workaround could require modifying the arguments of the respective routines to the expected correct parameters sent from the event handling routine.

Event Queue Managing And

Low-Level Event Handling

Accessing of system event queue is converted because there is no centralized mechanism to read events from a queue and post them.

Also, low-level event handling –also known as containment model- is not converted in .NET Framework because the heavy centralization and the lack of modularity inherent in this Java’s model, makes it a very particular way to handle events.

General Issues

Java Event Model conversion is mostly based on source code patterns. Java’s event notification –through listeners and adapters- is converted to .NET Framework through events and delegates.

In .NET Framework, listener and adapter classes are not essential. However, their methods are converted to delegates through delegate System.EventHandler. In this way, the same source methods are notified when events occur. In .NET Framework, Event “listener registration” is performed attaching event handlers (delegates) to the corresponding events.

User Raised Events

Events programmatically-raised by the user (not by the GUI normal interaction) through method dispatchEvent() are not completely converted. Only ActionEvent and ItemEvent (for Button, MenuItem and CheckboxMenuItem) are converted through method PerformClick.

Remaining user raised events have no equivalent in .NET Framework. A workaround could require designing another way of event notification.

Table 30: Java Event Model Conversion Issues

JLCA 3.0 - Java Accessibility (JAAPI)

GauravS — Thu, 15 Jun 2006 11:53:00 GMT

Java Accessibility allows extending programs by interfacing application components with assistive technologies -such as speech recognition and audio output- for users having special needs and/or permissions. Accessibility could be featured as a two-sided conversation between an assistive technology and accessibility-friendly components of the application. Java grants access to assistive technologies for all components in VM and brings the ability to relate –direct and quickly- assistive technologies with GUI applications without interfering. Java Accessibility is mainly converted to .NET Framework through classes AccessibleObject, AccessibleRole, AccessibleSelection, AccessibleStates and Control on System.Windows.Forms API.

Principally, JLCA 3.0 helps to convert the following features of Java Accessibility: Accessible Classes, Accessible Contexts (partially) and Accessible Components.

Table 25 and Table 26 contains relevant details about Accessibility conversion. In a summarized manner, they enunciate the Accessibility features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting applications using Accessibility.

Coverage Details

Class / Interface in Package javax.accessibility	Functionality	JLCA 3.0 Coverage	Description
Accessible	Accessible is the main interface that should be implemented by all supporting this package.	Converted	Converted to System.Windows.Forms.Control.AccessibilityObject.
AccessibleAction	This interface provides assistive technology to determine object’s action or to ask objects to perform some action.	Not Converted	This could be performed through AccessibilityObject members like: DefaultAction and DoDefaultAction.
AccessibleBundle AccessibleResourceBundle	These classes are used to maintain a strongly typed enumeration.	Not Converted	In .NET Framework, the Accessibility model has no common abstraction to display locale-based strings for roles and states.
AccessibleComponent	This interface should be supported by any object that is rendered on the screen.	Converted	Converted to System.Windows.Forms.Control. It provides access to component’s properties.
AccessibleContext	AccessibleContext represents the minimum information that all accessible objects return.	Converted	Converted to AccessibleObject as it provides information about any accessible component. This information is based on the role of the visual class being used.
AccessibleHypertext AccessibleHyperlink	These are used to represent hypertext information on screen.	Not Converted	Some behavior to navigate accessible hypertext can be performed through methods of AccessibleObject.
AccessibleIcon	This interface should be supported by any object that has an associated icon.	Not Converted	In .NET Framework icons-related information is not exposed through .NET Framework's accessibility mechanism.
AccessibleRelation AccessibleRelationSet	These are used to support relations for accessible objects.	Not Converted	.NET Framework does not have equivalent.
AccessibleRole	AccessibleRole determines the role of a component.	Converted	Converted to System.Windows.Forms.AccessibleRole that allows describing the generic function of components.
AccessibleSelection	AccessibleSelection provides the standard mechanism for an assistive technology to determine what the current selected children are, as well as modify the selection set.	Not Converted	In .NET Framework, it is handled differently. A workaround could require a check on AccessibleSelection and AccessibilityObject.State.
AccessibleState AccessibleStateSet	These are used to determine component’s particular state or component’s state set.	Converted	Converted to System.Windows.Forms.AccessibleStates which allows describing the common states of components. State sets are converted through the enum’s functionality.
AccessibleTable	AccessibleTable describes a user-interface component that presents data in a two-dimensional table format.	Not Converted	In .NET Framework, form tables can be accessed as simple lists within instances of AccessibleObject.
AccessibleTableModelChange	This interface describes a change to the table model.	Not Converted	.NET Framework does not provide such functionality.
AccessibleText	This interface provides the standard mechanism for an assistive technology to access text via its content, attributes, and spatial location.	Not Converted	In .NET Framework, there is no direct equivalent. Some behavior to navigate text in a character-based way could be achieved through property AccessibilityObject.Value.
AccessibleValue	This interface provides the standard mechanism for an assistive technology to determine and set the numerical value as well as get the minimum and maximum values.	Not Converted	Reduced behavior to provide a current state for a data type with a range of values could be performed through property AccessibilityObject.Value.

Table 25: Accessibility Conversion Coverage

Issues

Issue	Description
Accessible Icons, Tables And Relations	These Java Accessibility features are not natively supported by .NET Framework’s accessibility model.
Accessible Texts, HyperTexts And HyperLinks	Java’s Accessibility Functionality to display text components and web content (through relations between hypertext and hyperlinks) is not converted to .NET Framework. A workaround could require the use of components to display web content in an accessibility-like manner.
Broken Inheritance	In Java, most visual classes implementing interface Accessible also inherit from java.awt.Component. Conversion of Accessible classes is carried-out to System.Windows.Forms.Control. Java classes inheriting from Component are converted to .NET Framework classes which are not derived from System.Windows.Forms.Control. As Control is the base class for .NET Framework’s Accessibility, these kinds of Java classes could not be converted to .NET Framework accessibility-compliant classes. Broken Inheritance happens with the conversion of classes such as: javax.swing.JMenuItem, javax.swing.JMenuBar, javax.swing.JMenu, java.awt.MenuItem, java.awt.MenuBar and java.awt.Menu. In case of these classes, the accessibility methods are not converted.
General Issues And Accessibility Context Conversion	Conversion of Java’s Accessibility to .NET Framework’s Accessibility is very limited because both models are very different and .NET Framework has no support to advanced-key features of Java accessibility. Accessibility conversion is based on class AccessibleContext since it manages the base information for all accessible components such as: name, description, role and state. Conversion for Accessible.getAccessibleContext, AccessibleContext.getAccessibleComponent and AccessibleContext.setAccessibleDescription is based on source code patterns. In .NET Framework accessibility descriptions are assigned directly to the controls (in Java are managed by a context), the conversion tool then should track which context belongs to the control. This support is based on source code patterns.
User-Defined Accessible Components	In Java, implementing own Accessible components is done through interfaces Accessible and AccessibleContext (to manage user-defined accessibility information). In .NET Framework, classes implementing the Java’s interface Accessible will inherit from System.Windows.Forms.Control as in .NET accessibility support is built-in in Windows Forms. Since there is no multiple-inheritance in C# .NET, this could lead to compilation problems if the user-defined accessible component is extending from class which is not converted to a child of the Control. A workaround could require redesigning the target hierarchy of user-defined accessible components. Consider to derive from classes like AccessibleObject or Control.ControlAccessibleObject (to provide the necessary accessibility information).

Table 26: Accessibility Conversion Issues

JLCA 3.0 - Serialization

GauravS — Wed, 14 Jun 2006 09:47:00 GMT

Serialization corresponds with the core and native technology that Java provides to save/recover the state of objects. It is used by other Java technologies inherent in J2SE 1.3. Java provides two kinds of Serialization: Basic Serialization (Java managed) and Custom Serialization (User managed). In Java, Serialization could be used by means of interfaces java.io.Serializable and java.io.Externalizable. Serialization is primarily converted to .NET framework through System.Runtime.Serialization API.

Main conversion achieved by JLCA 3.0 corresponding to Serialization is related to the following features: Basic and Custom Serialization, Inheritance Hierarchy, Inner Classes Serialization, transient fields and serialPersistenFields and some JavaDoc tags.

Table 23 and Table 24 show the most relevant details for Serialization conversion. In a summarized manner, they enunciate the Serialization features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting applications using Serialization.

Coverage Details

Class / Interface in Package java.io	Functionality	JLCA 3.0 Coverage	Description
Externalizable Serializable	These interfaces support Serialization in Java.	Converted	Java’s Serializable classes are converted to System.Runtime.Serialization.ISerializable with an attribute System.SerializableAttribute. Basic serialization mechanism is converted completely. Custom serialization (using methods writeObject and readObject) is converted by means of the method ISerializable.GetObjectData and a special constructor. This conversion has some restrictions.
InvalidClassException InvalidObjectException NotSerializableException	Exceptions.	Converted	Map to System.Runtime.Serialization.SerializationException.
NotActiveException OptionalDataException ObjectStreamException StreamCorruptedException WriteAbortedException	Exceptions.	Converted	These exceptions were converted to a more general exception (System.Exception).
ObjectOutputStream	ObjectOutputStream writes primitive data types and graphs of Java objects to an OutputStream.	Converted	Serialization-related behavior is converted through System.Runtime.Serialization.SerializationInfo. Special methods (defaultWriteObject and defaultReadObject) are converted to a SupportClass using FormatterServices.GetSerializableMembers.

Table 23: Serialization Conversion Coverage – Package java.io

Issues

Issue	Description
Custom Serialization	Conversion of methods writeObject and readObject has conflicts with some source code patterns. Full conversion is achieved when the code -to serialize and deserialize- resides totally in these methods and it is not inside flow of control structures. In general, conversion of serialization code inside flow-control structures –like loops, ifs or switches- will raise runtime exceptions because a same key is being used to serialize/deserialize two different values. .NET Framework Serialization requires a unique key for the data. A workaround could require assigning a unique key for each value written/read. Further, conversion of methods writeObject and readObject calling routines behind the serialization will raise compilation errors. A workaround could require adapting the code-behind routines to receive/use the respective SerializationInfo and assign unique –but synchronized- keys for the values written/read.
Externalization	Conversion for Externalizable classes with custom serialization (using methods writeExternal and readExternal) is carried-out in the same manner as the Serializable classes. But defining a custom stream serialization format -as Externalization does- is not converted. A workaround could require reviewing the hierarchies of Externalizable classes and consider add/remove attributes depending on the metadata required for each member of the hierarchy.
General Issues And Repository Convertion	Serialization Conversion is carried-out to .NET Framework Serialization. As in Java, .NET Framework serialize and deserialize objects use an own format. So, an object serialized in Java could not be deserialized in .NET framework because .NET Framework does not know how deal with Java’s format. The best conversion is achieved when the conversion includes both applications which serializes and deserializes the information, and when the objects’ repository is not to be converted. If not, a workaround could require converting the objects repository, separately. This conversion process could be performed with a Java program reading the Java objects and writing them to an intermediate repository (with an intermediate format, if .NET Framework’s format is unknown). After which, a C# program could read this intermediate repository and write them in the .NET Framework’s objects repository using the converted application.
Serial Persistent Fields	Supported case is related when the array variable “serialPersistentFields” is declared and initialized at the same time and the initialization does not invoke/use methods or fields. After conversion, the array variable could be commented. A workaround could require add/remove an attribute System.NonSerializedAttribute to fields not referenced by the array variable serialPersistentFields.

Table 24: Serialization Conversion Issues

JLCA 3.0 - Java Messaging Service (JMS)

GauravS — Tue, 13 Jun 2006 11:25:00 GMT

Messaging is a system of asynchronous request conducted as event-driven communication layer that allows applications to exchange information in the form of messages. The Messages are transmitted using a Message Oriented Middleware (MOM), an intermediary between the clients exchanging information. JMS is an API to access messaging systems that can be used with many different MOM vendors. It also provides a JMS compliant service. JMS is mainly converted to .NET framework through System.Messaging API. Converted applications only support a unique MOM: Microsoft Message Queuing (MSMQ). MSMQ must be installed separately and MSMQ v3.0 should be used for applications using Multiple-Destination Messaging.

Principally, JLCA 3.0 helps to convert the following JMS features: Queues/Topics, Message Producers, Message Consumers (Listeners), Messages (Headers, Properties and Bodies) and Exceptions. JMS Features like Connection Factories, Connections and Sessions are not converted since they are not needed in .NET.

Table 21 and Table 22 show the most relevant details about JMS conversion. In a summarized manner, they enunciate the JMS features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting applications using JMS.

Coverage Details

Class / Interface in Package javax.jms	Functionality	JLCA 3.0 Coverage	Description
BytesMessage StreamMessage	BytesMessage is used to send a message containing a stream of uninterpreted bytes. StreamMessage is used to send a stream of primitive types in Java.	Converted	Converted to System.Messaging.Message. The message contents are written /read to/from the property BodyStream using System.IO classes such as BinaryWriter and BinaryReader.
Connection ConnectionFactory QueueConnection QueueConnectionFactory TopicConnection TopicConnectionFactory	Interfaces supporting the connection facility.	Not Converted	System.Messaging.Message.MessageQueue takes care of the connection implicitly.
ConnectionConsumer ServerSession ServerSessionPool	Interfaces supporting pool facility to process messages on the server.	Not Converted	In .NET Framework, MSMQ does not support a pool-like facility.
ConnectionMetaData	ConnectionMetaData provides information describing the Connection object.	Not Converted	.NET Framework has only metadata about queuing. (System.Messaging.Message.SenderVersion).
DeliveryMode	DeliveryMode describes the delivery mode supported by JMS– PERSISTENT or NON-PERSISTENT	Converted	Its field's values are converted to boolean values as they are used by System.Messaging.Message.Recoverable.
Destination Queue	Destination object encapsulates a provider-specific address. Queue object encapsulates a provider-specific queue name.	Converted	In .NET Framework a queue reference is simply a string path. So, they are converted to System.String.
ExceptionListener	JMS provider informs the Connection object's registered ExceptionListener about connection problems.	Not Converted	In .NET Framework, registered clients are not notified about connection problems.
IllegalStateException	This exception is thrown when a method is invoked at an illegal or inappropriate time or if the provider is not in an appropriate state for the requested operation.	Converted	Converted to System.InvalidOperationException as it has a similar behavior.
InvalidClientIDException	This exception is thrown when a client attempts to set a connection's client ID to a value that is rejected by a provider.	Not Converted	In .NET Framework, a connection’s client ID could never be invalid as the equivalent property is read-only.
InvalidDestinationException JMSException JMSSecurityException	These exceptions are thrown when provider considers destination or name/password as invalid.	Converted	System.Messaging.MessageQueueException is used to notify .NET Framework’s equivalent faults.
InvalidSelectorException	This exception is thrown when a JMS client attempts to give a provider a message selector with invalid syntax.	Not Converted	In .NET Framework, approach for message selectors is not supported.
MessageConsumer MessageProducer	MessageConsumer is used to receive messages from a destination. MessageProducer is used to send messages to a destination.	Converted	System.Messaging.MessageQueue provides a similar approach in .NET Framework Messaging.
MessageEOFException	This exception is thrown when an unexpected end of stream has been reached when a StreamMessage or BytesMessage is being read	Converted	Converted to System.IO.EndOfStreamException.
MessageListener	MessageListener is used to receive asynchronously delivered messages.	Converted	In the onMessage method some lines of code are added to support the asynchronous message delivery in .NET Framework.
MessageFormatException MessageNotReadableEx MessageNotWritableEx	These exceptions are thrown when JMS Client attempts to read write-only message or to write to read-only message or to use a datatype not supported by provider.	Not Converted	.NET Framework’s equivalent for StreamMessage will never throw a similar exception. So a workaround could require adding near places where these exceptions are caught - the specific code to check the message availability and integrity.
MapMessage Message ObjectMessage TextMessage	Message is root interface of all messages. MapMessage is used to send a set of name-value pairs. ObjectMessage is used to send a message that contains a serializable object. TextMessage is used to send message containing java.lang.String.	Converted	Converted to System.Messaging.Message because the property Body could contain different kinds of messages. To convert MapMessage, it wraps a SortedList. To convert ObjectMessage, it wraps the respective object. To convert TextMessage, it wraps a System.String. Message custom properties (application-defined) are not supported in .NET Framework.
QueueBrowser QueueReceiver QueueSender	QueueBrowser is used to look at messages on a queue without removing them. QueueReceiver is used to receive messages that have been delivered to a queue. QueueSender is used to send messages to a queue.	Converted	System.Messaging.MessageQueue provides a similar approach in .NET Framework Messaging.
QueueRequestor TopicRequestor	These helper classes simplifies making of service requests.	Not Converted	No equivalent functionality is found in .NET Framework. It can be implemented by the user.
QueueSession Session TopicSession	In Java, sessions are used to create different kinds of message objects, message producers and consumers, and to manage transactions.	Not Converted	In .NET Framework, this functionality is implemented using classes Message, MessageQueue and MessageQueueTransaction.
ResourceAllocationException TransactionInProgressException TransactionRolledBackException	Exceptions	Converted	These exceptions are converted to a more general exception (System.Exception).
TemporaryTopic	TemporaryTopic object is a unique Topic object created for the duration of a TopicConnection.	Not Converted	In .NET Framework, the approach for a publish/subscribe system does not support the creation of temporary topics.
TemporaryQueue	TemporaryQueue object is a unique Queue object created for the duration of a QueueConnection.	Converted	It is converted to System.String to represent a temporary queue created by a Support Class. In .NET Framework, there are no temporary queues; so the converted code creates a physical one. It is expensive and it must be deleted explicitly.
Topic	Topic object encapsulates a provider-specific topic name.	Not Converted	In .NET Framework, the term "topic" is different. The multiple destination messaging is represented using different types of string formats.
TopicPublisher TopicSubscriber	TopicPublisher is used to publish messages on a topic. TopicSubscriber is used to receive messages that have been published to a topic.	Converted	System.Messaging.MessageQueue provides a similar approach in .NET Framework Messaging.
XAConnection XAConnectionFactory XAQueueConnection XAQueueSession XASession XATopicConnection XATopicSession	These are interfaces to provide XA interoperability.	Not Converted	For a class to be able to use XA interoperability in .NET Framework, it should inherit from System.EnterpriseServices.ServicedComponent.

Table 21: JMS Conversion Coverage – Package javax.jms

Issues

Issue	Description
Connections And Connection Factories	.NET Framework Messaging uses a different mechanism to access and reference queues. MSMQ has neither "administered objects" nor factories. Connections are opened automatically while sending and receiving. So, the user should review the converted code to possibly ignore all the code used to create a connection (through JNDI). In .NET Framework, they are not needed.
Custom Messages	Classes implementing the interface Message to define user-customized messages are converted to classes derived from System.Messaging.Message. Conversion of some Message‘s member is not supported. Conversion of custom messages requires some changes depending on the nature of the user defined message. The user should review the converted code carefully in order to assure its functionality is equivalent in .NET Framework. The user must localize the not converted and unnecessary issues in .NET Framework model.
Custom Properties	Functionality related to attaching custom properties to messages is not converted. The user should adapt this behavior to the target application. A workaround could require the use of a Hashtable to add/ retrieve custom properties and serialize/deserialize it to/from the property Message.Extension.
Destinations (Queues and Topics)	In .NET Framework, the one-to-many messaging handles topics as multiple queues. Queues/Topics are converted to Strings as their reference is a special formatted string.
General Issues And MSMQ	JMS is converted to .NET Framework Messaging and MSMQ as the back-end messaging provider. MSMQ is the only MOM supported in .NET Framework. Converted applications require install MSMQ as a separate package over Microsoft Windows 2000 or XP (depends of the MSMQ version). The user could config the queues using the Microsoft Management Console at ControlPanel->AdministrativeTools-> ComputerManagement->ServicesAndApplications-> MessageQueuing or using the methods System.Messaging.MessageQueue.Create.
JMS Interop	Converted JMS applications can not use JMS-compliant MOMs because .NET Framework Messaging is a wrapper for accessing MSMQ technology. A workaround could require using a bridge that translates message formats.
Message Acknowledgement	MSMQ does not handle acknowledgment as JMS-compliant MOMs, in the sense that it does not re-send messages when a MOM does not receive an acknowledgment. In .NET Framework, the user has to implement the code to receive process acknowledgment and re-send messages. Acknowledgement requesting could require the use of properties Message.AdministrationQueue and AcknowledgeType.
Message Concurrency	Message concurrency behavior though JMS classes ConnectionConsumer and ServerSessionPool is not converted. To support concurrency, the user could write a multithreaded server application having a client running for message processing.
Message Listeners	Classes implementing the interface MessageListener are converted for asynchronous message delivery. Since, there is no equivalent in .NET Framework; some code is automatically added in the converted message listener to support asynchronous operations. Finally, an event delegate is attached to the event System.Messaging.MessageQueue.ReceiveCompleted.
Message Selectors	The user should review the target code and adapt the Message Selectors functionality to .NET Framework Messaging model. A workaround could require the use of method MessageQueue.Peek to look at messages without removing them from the queue.
Publish/Subscribe Model And Multiple-Destination Messaging	Applications using Publish/Subscribe are converted to use Multiple-Destination Messaging. MSMQ supports durability by default (as Durable Subscribers in JMS). To enable Multiple-Destination Messaging, the user must install MSMQ v3.0 (only available for Win XP). Also, the user needs to change the path referencing the queues which can be done through three different mechanisms (IP Multicasting, Format Names and using Active Directory). The user should decide which mechanism of Multiple-Destination Messaging to use.
Security	Conversion of applications using the standard JMS security (to authenticate clients against the messaging server) requires user intervention as authentication works differently in .NET Framework and MSMQ. To authenticate a messaging application, the user could use the following classes of System.Messaging namespace: Trustee, MessageQueuePermission and MessageQueueAccessControlEntry.
Sessions	In .NET Framework, sessions are managed automatically by the class System.Messaging.MessageQueue. So, the user should review the converted code to possibly ignore the unnecessary code related to session management.
Temporary Queues	Temporary Queues are converted as non-temporary as the target code creates a physical queue that is not deleted automatically. Creation of temporary queues is converted through a Support Class. So, the user should remove them explicitly when necessary. Queues are only removed by calling the method delete. The application could require the design and implementation of a better approach for temporary queues. In .NET Framework, use of physical queues indiscriminately produces overhead.

Table 22: JMS Conversion Issues

JLCA 3.0 - CORBA - Dealing with Other Languages

GauravS — Fri, 09 Jun 2006 13:05:00 GMT

Since JLCA only converts Java applications and Java CORBA support is targeted through .NET Remoting, server and/or client applications written in other languages are not be converted entirely. Usually, a converted application could require extensive user-intervention to adapt the .NET Remoting application to the multi-language environment commonly seen in CORBA applications. Table 13 discusses possible scenarios behind Java applications using CORBA and suggests how to deal with converted applications.

CORBA

Scenario

A Non Java Server

If there is a CORBA server which is not written in Java with Java and non Java clients. JLCA can convert the Java clients into .NET Remoting clients.

However, it would be necessary to build a proxy application behaving as a bridge between .NET Remoting and CORBA. Such application would act as a Remoting server and a CORBA client. It listens to .NET Remoting requests and converts them into CORBA requests.

A Java Server

If there is a CORBA server written in Java with Java and non Java clients. JLCA can convert the Java server, object implementations and clients into .NET Remoting.

However, to let non-java clients to connect through .NET Remoting, it would be necessary to build a proxy application behaving as a bridge between CORBA and .NET Remoting. Such an application would act as a Remoting server and a CORBA client. It would listen to CORBA requests and would convert them into .NET Remoting.

Table 13: CORBA Conversion Scenarios

The suggested bridge application takes the advantage of the fact that servers and clients can be written in C++ and this language is fully supported by .NET Framework. Note that in both the above scenarios, the proxy approach is just a temporary solution. As soon as a third-party .NET solution is provided for the involved languages, the bridge will turn impractical. Table 14 summarizes the main advantages and disadvantages of the proxy-like application:

Advantages	Disadvantages
A great workaround for the unconverted features and they can continue working	Mixed architecture: CORBA and .NET Remoting instead of 100% .NET Remoting
CORBA and .NET Remoting applications can work together	A bridge adds a level of indirection.
Unconverted code remains unchanged
Proxy generation is relatively easy

Table 14: An Analysis for a Schema Involving a Bridge Application

JLCA 3.0 - Common Object Request Broker Architecture (CORBA)

GauravS — Wed, 07 Jun 2006 15:28:00 GMT

CORBA is a core part of the Object Management Architecture (OMA), a complete infrastructure for distributed computing. It was developed to merge remote procedure calls and object orientation to achieve support for distributed objects. The standard can be implemented with hardware, OS and programming language independence using the Interface Definition Language (IDL). IDL is a purely declarative language to define interfaces to CORBA objects.

It is important to mention that the IDL defines some definitions not natively supported by Java (like structures, valuetypes and unions). Java CORBA support simulates CORBA support with classes. Java CORBA support is related to OMG CORBA Specification 2.3, specifically IBM WSDK (IDLJ Compiler) and API org.omg.CORBA. Java CORBA support is mainly converted to .NET Framework using System.Remoting API. Special analysis allows JLCA 3.0 to convert Java simulations to .NET Framework native constructions. A shared assembly between server and clients - with interfaces or base abstract classes - needs to be defined to publish the remote objects.

Main conversion of Java CORBA in JLCA 3.0 supports the following features in IDL files: Names and Scoping, Modules, Interfaces, Typedefs, Exceptions, Basic Data Types, Constants, Arrays, Sequences, Enums, Structs, Unions and Value Types; Serialization and, Server and Client Sides.

Table 10,Table 11 and Table 12 contain relevant details for conversion of Java applications using CORBA. In a summarized manner, they enunciate the CORBA features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting applications using CORBA.

Coverage Details

IDL File Element	.NET Framework Equivalent	JLCA 3.0 Coverage	Description
Arrays	Arrays	Converted	IDL Arrays are converted to C# boundless arrays.
Basic Datatypes	Basic Datatypes on Namespace System	Converted	IDL Basic Datatypes are converted to .NET’s native datatypes.
Constants	public static readonly fields	Converted	IDL Constants within an Interface or Value Type are converted to public static readonly fields inside their respective owner. IDL Constants within modules are converted into public static readonly fields inside C# structs whose name is the name of the module + “_Fields”. IDL global constants (outside the modules) are converted inside a C# struct whose name is “global Fields”.
Exceptions	RemotingException	Converted	Exceptions are converted to user exceptions extending System.Remoting.RemotingException and implementing the interface ISerializable.
Interfaces	Interfaces	Converted	Multiple-Inheritance is supported at interface-level. Interfaces are converted to C# interfaces (inside the corresponding shared assembly). Abstract interfaces are converted as non-abstract ones. Attributes and Operations are converted to interface properties and methods respectively. Also in, out, and inout parameters are converted to normal, out and ref parameters. Furthermore, classes implementing IDL interfaces (published objects) are converted to classes implementing their converted interface and extending System.MarshallByRefObject.
Modules	Namespaces	Converted	IDL Nested modules are converted to nested namespaces.
Operation Contexts	-		JLCA 3.0 Warns the user when Operation Context Expressions are not converted.
Sequences	Arrays	Converted	IDL Sequences are converted to C# arrays. Bounded sequences are converted as boundless.
Structures Enumerations	Structs Enums	Convereted	IDL structs and enums are converted to serializable C# structs and enums respectively.
Unions	Structs	Converted	IDL Unions are converted to serializable C# structs with a discriminant used to select which value to use.
Value Types	Classes and Interfaces	Converted	Concrete Value Types are converted to serializable C# abstract classes. Factory methods are converted to public static methods. Custom Value Types are converted as non-custom ones. Also, Abstract Value Types are converted to interfaces. Furthermore, classes implementing IDL value types (published objects) are converted to serializable classes extending from/implementing its converted value type.

Table 10: CORBA Conversion Coverage (1)

Java

JLCA 3.0 Coverage

Description

CORBA Server And Client Applications

Partially

Converted

CORBA Server and Clients conversion is based on source patterns using the methods rebind/bind and resolve (for servers and clients, respectively) of classes org.omg.CosNaming.NamingContext and javax.naming.InitialContext. Conversion of servers produces a Configuration file (".config") to specify information about .NET Remoting.

Object Implementation (Published Objects)

Converted

Published Objects are converted to respective classes generated in the shared assemblies. These classes implement the corresponding converted IDL interface/valuetype and inherit from the class System.MarshallByRef.

Table 11: CORBA Conversion Coverage (2)

Issues

Issue	Description
Dynamic Skeleton Interface (DSI)	Java CORBA applications using DSI are not converted The object implementations requires user-intervention as a pre-conversion step. Converting object implementations extending from org.omg.CORBA.DynamicImplementation requires the source code to be modified changing the inheritance to the right skeleton and implementing the functionality declared in the respective IDL file.
General Issues And .NET Projects	Since IDL files contain the interface declaration for published objects which is used to organize the resulting .NET Framework Remoting application and to convert user objects implementations, CORBA conversion depends on these IDL files. For each IDL file inside the source code directory, JLCA 3.0 creates a shared .NET Framework Remoting Project with the same name as the IDL file (inside a folder called “IDLProjects”). It contains all the interfaces declared in the respective IDL file (published objects) and the implementation of objects passed by value between servers and clients. These projects should be shared for both server and client applications (just as the IDL File was “shared” in Java). Conversion for servers, clients and user-classes is contained inside the conversion’s target project. In this project, the user needs to add all the references for the required shared assemblies.
IDL, Skeleton And Stub Files	IDL files are required for CORBA conversion. Converting Java applications using CORBA without providing the corresponding IDL files will not successfully convert the CORBA functionality. This might require creating the respective IDL files before converting the code. Skeleton and Stub files are discarded because they are not needed in .NET. Thus, the user code existing in skeletons and stubs would be lost. In fact, in Java CORBA, it is highly recommended that users should not modify the stubs and skeleton files (as they are automatically generated).
Non IBM-WSDK Object Request Brokers	Object Request Brokers (ORB) implementations different than IBM WSDK (such as VisiBroker) are not converted. Thus, server/clients require intervention in the sections related to objects accesses and ORB initialization because the code is vendor dependant. Also, conversion of applications using Portable Object Adapters (POA) instead of Basic Object Adapters (BOA) requires some user-intervention. The POA policies functionality could be lost during the conversion. Clients that use Dynamic Invocation Interface (DII) are not converted.
Non-Java Servers/Clients	As Java CORBA is converted to .NET Remoting, the ideal scenario for CORBA conversion is when both server and client applications are being ported to .NET. However, a commonplace CORBA environment involves server and client applications implemented in different languages. Since JLCA only converts Java Code and Java CORBA support is targeted through .NET Remoting, such scenarios are not converted at all and require extensive user-intervention. This issue is extensively addressed in the next section.

Table 12: CORBA Conversion Issues

JLCA 3.0 - Enterprise Java Beans

GauravS — Tue, 06 Jun 2006 10:06:00 GMT

Enterprise Java Beans define a server side distributed component model architecture that intends to provide solutions for business applications in a transactional, secure, scalable and platform independent way. It provides features like automatic data persistence, remote messaging, security, resource management and transparent Client/Server communication. EJBs (versions 1.1 and 2.0) are primarily converted to .NET Framework through COM+ technology (System.EnterpriseServices API). EJBs with Container Managed Persistence (CMP) have no direct equivalent in COM+.

Principally, JLCA 3.0 helps to convert the following features of EJBs: Session Beans (Stateful and Stateless), Entity Beans (BMP and CMP), Message Driven Beans, Client Side, Security (Permissions and Roles) and Transactions (EJB level and Method Level). It is relevant to note that JLCA 3.0 only converts standardized features (stated in the EJB Specification) and does not convert vendor-specific implementations. Since features that are stated and configured from the application’s XML Deployment Descriptor (ejb-jar.xml) are converted, JLCA 3.0 requires that this file be placed inside the source code directory for successful conversion.

Table 8 and Table 9 contain the relevant details for EJB conversion. In a summarized manner, they enunciate the EJB features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting EJBs.

Coverage Details

Class / Interface in Package java.beans	Functionality	JLCA 3.0 Coverage	Description
AccessLocalException CreateException DuplicateKeyException EJBException FinderException NoSuchEntityException NoSuchObjectLocalException ObjectNotFoundException RemoveException TransactionRequiredLocalException TransactionRolledbackLocalException	Exceptions	Converted	These exceptions are converted to a more generic exception (System.Exception).
EJBContext	This provides an instance with access to the container-provided runtime context of an enterprise Bean instance.	Partially Converted	This interface is not completely converted. Some of its methods such as 'isCallerInRole' have direct equivalence in .NET Framework and are therefore converted.
EJBHome EJBLocalHome EJBLocalObject EJBObject	These are the interfaces that must be extended by Bean’s remote home, local home, local and remote interfaces respectively.	Partially Converted	These interfaces are not supported in .NET Framework. JLCA 3.0 supports the conversion of the common scenario where there are classes/interfaces extending/implementing user-defined EJB Local, Home, and Remote interfaces to publish the EJBs’ lifecycle and business logic.
EJBMetaData	This interface allows a client to obtain the enterprise Bean's meta-data information.	Not Converted	This interface is not converted as it is used only to provide EJB Meta Data Information.
EnterpriseBean EntityBean MessageDrivenBean SessionBean	These interfaces are implemented by every enterprise, entity, message-driven and session bean.	Converted	These interfaces are converted to System.EnterpriseServices.ServicedComponent since all EJB bean classes are converted to a COM+ ServicedComponent.
EntityContext SessionContext MessageDrivenContext	These interfaces are related to specific EJB Contexts.	Not Converted	These are not supported as COM+ Contexts are managed differently and their information is not equivalent in content/context to the information provided by EJB Contexts.
Handle HomeHandle	Interfaces implemented by EJB and home object handle respectively.	Not Converted	These interfaces are not converted as remote network references to objects are managed by the framework itself.
SessionSynchronization	This interface allows a session Bean instance to be notified by its container of transaction boundaries.	Not Converted	This interface is not needed in COM+ as COM+ manages synchronization and transactions automatically.

Table 8: EJBs Conversion Coverage – Package java.beans

Issues

Issue	Description
Applications Deployment	EJB Application Deployment Issues are not covered as JLCA 3.0 only supports features stated in the standard EJB Specification. These are stated in the XML Deployment Descriptor (ejb-jar.xml). The EJB deployment procedures are vendor-specific. The user should deploy the target COM+ Applications.
Bean Managed Transactions	There are no special rules to convert user transactions in BMP EJBs (using a transaction API like JTA). A workaround could be to use declarative transactions (attributes) for the targeted .NET Framework Serviced Components.
EJB Clients	EJB Clients conversion requires converting the server side application at the same time as the client because it needs the metadata information about the EJBs and the respective XML Deployment Descriptor. The conversion is based on source code patterns and it does not replicate the reference lookup (performed through JNDI). The user should manually add the respective references and fix JNDI-related issues in the Client project.
Entity Beans Relationships (Tag <ejb-relation>)	Entity bean’s relationships with one-another are not entirely converted by JLCA3.0 as they are based on the underlying vendor-specific datastore schema. For each relation, JLCA converts the relations by means of a Serviced Component field and provides a dummy implementation for the respective properties. Additional steps could require setting the respective value of each property for each relation.
Environment Entries	The Environment Entries are not converted at all because logical references for publishing – performed through JNDI - must be executed from a Directory Service. A workaround could require publishing the resources in a Directory Service like ADS and specifying in the target code where the resource was published.
General Issues And COM+ Projects	EJBs conversion depends on the XML Deployment Descriptor (ejb-jar.xml file). For each XML Deployment Descriptor found inside the source code directory (or inside files .jar and .ear) JLCA 3.0 creates a target COM+ project if all classes/interfaces described in the corresponding XML Deployment Descriptor are provided inside the source code directory. The target COM+ project is named as COMPlusApplication and contains only the EJBs classes/interfaces described in the respective XML Deployment Descriptor. The user should add all classes that contained EJBs are depending on (referencing and/or using) during the conversion to the target COM+ projects.
State Synchronization (javax.ejb.SessionSynchronization)	As COM+ manages transactions in a different way, state synchronization availability with the outcome of transactions is not converted. A possible workaround could be to declare a transactional .NET Framework Serviced Component by adding the attribute System.EnterpriseServices.Transaction and manually adding invocations to the implemented methods of javax.ejb.SessionSynchronization in the proper sections of the code.
Stateful Session Beans	Stateful Session Beans are not converted entirely by JLCA 3.0 because COM+ is a stateless technology, in the sense that it requires to manage “session state” for each client (Read more here). A workaround could require changing the application design to emulate persistence of session states.
Transaction Isolation Levels	Transaction Isolation Levels are not converted by JLCA 3.0. Container-managed transactions are specified using vendor-specific tools and bean-managed transactions are specified using an API like java.sql.Connection.setTransactionIsolation(). A workaround could be to apply the attributes (System.EnterpriseServices.Transaction.Isolation and System.EnterpriseServices.TransactionIsolationLevel) to the target .NET Framework Serviced Components.

Table 9: EJBs Conversion Issues

JLCA3.0 - Java Beans

GauravS — Mon, 05 Jun 2006 11:39:00 GMT

Java Beans are components that can be controlled dynamically and assembled to applications via visual components. However, they not only have visual uses but they could be used to implement non-visual components as well. They are mainly converted to .NET Framework through System.ComponentModel API and System.Windows.Forms.UserControl.

Principally, JLCA 3.0 conversion takes into account the following features of Java Beans - File Manifest.MF, Bean Classes (Visual and non-Visual), Descriptors Info (converted to the equivalent .NET Framework attributes for design-time), Properties (Bound and Indexed; Property Editors), Events, Inheritance Hierarchy and Persistence.

Table 6 and Table 7 below contain the relevant details for Java Beans conversion. In a summarized manner, they enunciate the Java Beans features preserved in the converted applications. On the other hand, they suggest the issues that the user should take care while converting application containing Java Beans.

Coverage Details

Class / Interface in Package java.beans	Functionality	JLCA 3.0 Coverage	Description
AppletInitializer	Provides a proper initialization to invoke java.beans.Beans.instantiate method.	Not Converted	This kind of initialization is not necessary in .NET Framework.
BeanDescriptor BeanInfo EventSetDescriptor IndexedPropertyDescriptor MethodDescriptor ParameterDescriptor PropertyDescriptor SimpleBeanInfo	Used within BeanInfo to provide information for design-time.	Not Converted	In .NET Framework, this kind of information is represented using attributes of System.ComponentModel. The required information of these classes is converted based onBeanInfo’s source code.
Beans	This class initializes a JavaBean.	Not Converted	In .NET Frameowrk, this should be done like a normal construction of a type.
Customizer	This class provides a complete custom GUI for customizing a target Java Bean.	Not Converted	Controls in .NET Framework have the capacity to define a class using System.ComponentModel.DesignerAttribute for controlling the controls in Design-time, but the approach is different.
FeatureDescriptor	This class is the common baseclass for PropertyDescriptor, EventSetDescriptor, and MethodDescriptor, etc.	Partially Converted	The important methods of this class that are inherited by other descriptors are also converted.
Introspector InstrospectionException	Provides a standard way for tools to learn about the properties, events and methods supported by a target Java Bean.	Not Converted	.NET Framework does not need more introspection than its normal reflection to extract the data or the corresponding exception.
PropertyChangeEvent	A "PropertyChange" event gets delivered whenever a bean changes a "bound" or "constrained" property.	Converted	Conversion maps to SupportClass.PropertyChangingEventArgs which extends from PropertyChangedEventArgs and provides properties used in constrained properties
PropertyChangeListener VetoableChangeListener	Provides listener to bean’s PropertyChange Event.	Not Converted	The listener related to the PropertyChangeEvent is converted like any other event listener.
PropertyChangeSupport	Utility class used by beans that support bound properties.	Not Converted	In .NET Framework this is handled with += or -= operators through the PropertyChangeListener.
PropertyEditor	This class provides support for GUIs that want to allow users to edit a property value of a given type.	Partially Converted	The enumerations and text representations are converted through System.ComponentModel.TypeConverter. Custom representations are supported partially since automatic conversion to System.Drawing.Design.UITypeEditor cannot be generalized.
PropertyEditorManager	Associates an editor to a data type.	Not Converted	In .NET Framework this functionality supported with editors like TypeConverter or UITypeEditor, with the System.ComponentModel.TypeConverterAttribute or System.ComponentModel.EditorAttribute
PropertyVetoException	This exception is thrown when a proposed change to a property represents an unacceptable value.	Converted	The System.ArgumentOurOfRangeException is thrown when the value of an argument is outside the allowable range of values as defined by the invoked method.
VetoableChangeSupport	This is a utility class used by beans that support constrained properties.	Not Converted	.NET Framework can support the change of values in a property but not with the kind of restrictions provided by this class.
Visibility	Determines whether the component must be visually displayed.	Not Converted	This methodology does not apply in .NET Framework.

Table 6: Java Beans Conversion Coverage – Package java.beans

Issues

Issue	Description
Bean Info Classes	Bean Info classes are analyzed to extract information and convert supported features. They are not converted since do not apply for the .NET Framework Component Model. The user can ignore the converted BeanInfo classes since their features are “converted” to .NET Framework model.
Bean’s Icons	Conversion of Icons used to represent Java Beans in tool boxes or list views is not supported. A workaround could be to use the attribute System.Drawing.ToolboxBitmap.
Bean’s Unicast and Multicast Events	Conversion of setting the default event as Multicast is not converted. Setting event descriptors as Unicast is not supported too. A workaround can be to use the class attribute System.ComponentModel.DefaultEvent.
General Issues And Manifest Files	Conversion for Java Beans requires the respective Manifest File (META-INF\MANIFEST.MF) to reside inside the source code directory (or inside .jar files). It allows identify Java Bean and relative BeanInfo classes.

Table 7: Java Beans Conversion Issues

JLCA 3.0 – Java API’s and Java Technologies

GauravS — Mon, 05 Jun 2006 11:36:00 GMT

JLCA 3.0 incorporates support to convert J2SE APIs. The APIs are converted to equivalent .NET Framework APIs or Compatibility Classes (Support Classes). Some APIs are either not converted or are converted with a different behavior. Table 5 enumerates the Java APIs that JLCA 3.0 supports and their mappings to .NET Framework API’s.

API in Java	Acronym	Mainly Target API
Java API for XML Processing	JAXP	System.Xml
Java Authentication and Authorization Service	JAAS	System.Security
Java Cryptography Extension	JCE	System.Security.Cryptography
Java Database Connectivity	JDBC	System.Data.OleDb
Java Naming and Directory Interface	JNDI	System.DirectoryServices
Java Transaction API	JTA	System.EnterpriseServices
JavaBeans Activation Framework	JAF	System.Windows.Forms.DataObject
JavaMail	JavaMail	System.Web.Mail
VJ++ Packages (com.ms.ui and com.ms.wfc)	VJ/WFC	System.Windows.Forms

Table 5: New Java APIs Supported by JLCA 3.0

Java Technologies Conversion

JLCA 3.0 includes new analysis and deductions to convert J2EE technologies and APIs. It converts these technologies taking into account the source code architecture. JLCA 3.0 analysis recognizes the common and most used Java patterns corresponding with the use of each technology in order to convert them to the best known equivalent in .NET Framework. The main J2EE Technologies and APIs that JLCA 3.0 adds supports for over the previous version are enumerated in the next few blogs.

JLCA 3.0 - Introduction

GauravS — Fri, 02 Jun 2006 11:16:00 GMT

Table 1 summarizes the JLCA versions released so far.

JLCA	Source	For .NET Framework
1.0	Visual Studio 2003	1.1 (Everett)
2.0	Download from here	1.1 (Everett)
3.0 Beta (GDR)	Download from here	1.1 (Everett)
3.0 Whidbey	Visual Studio 2005	2.0 (Whidbey)

Table 1: JLCA Released Versions

The following parts of this document describe the main issues and features addressed/implemented in JLCA 3.0.

· The section “J2SE and J2EE Coverage” gives idea of the conversion coverage achieved by JLCA 3.0 corresponding to Java 1.3 Features.

· The section “JLCA 3.0” describes the new features released in JLCA 3.0 compared to JLCA 2.0.

J2SE and J2EE Coverage

JLCA 3.0 is designed to assist in the conversion of Java applications using inherent J2SE 1.3 and J2EE 1.3 features. Furthermore, it is designed to assist in converting VJ++ applications using VJ++ features.

The previous versions of the tool added support to convert Java applications using some features of J2SE and VJ++. JLCA 3.0 adds more support to the target feature set as described above.

Table 2 ,Table 3 and Table 4 describe the conversion coverage achieved by JLCA 3.0 for J2SE Basic features, J2SE 1.3 Java Foundation Classes (JFC) features and J2EE 1.3 features. For each feature, they provide top level details of the targeted API’s, extent of conversion and description of their conversion by using JLCA 3.0.

J2SE 1.3 Basic Features

J2SE 1.3 Feature	Package / Functionality	JLCA 3.0 Coverage	Description
Arbitrary Precision Math	java.math	Partially Converted	Most of the functionality of this package is not converted.
Collections Framework	java.util	Converted	Conversion to .NET Framework is achieved natively or by means of support classes. Some members are converted with different behavior.
Extension Mechanism	java.lang.ClassLoader java.lang.Package java.lang.Thread java.net.JarURLConnect java.net.URLClassLoader SecureClassLoading	Not Converted	The Java Extension Mechanism does not apply for the .NET Framework.
I/O	java.io	Partially Converted	High rate of conversion is achieved for this package. Some hierarchy conflicts are present in the conversion.
Internationalization	Locales and Resources Calendar and Time Zone Formatting Loc-Sensitive String Ops Character Sets and Classif. AWT Attributes Stream I/O	Partially Converted	Conversion is achieved for Locales, Locale-Sensitive String Ops, and Resources. The remaining functionality is either not converted or is converted with a different behavior.
Java Archive (JAR) Files	java.util.jar java.net.JarURLConnection JAR Files Loading	Not Converted	Java Archive Files has no equivalent mapping in .NET Framework. JLCA is however able to read JAR Files to extract .class info.
Java Native Interface (JNI)	-	Not Converted	JNI functionality is not converted.
JavaBeans	java.beans	Partially Converted	Bean Classes, Properties, Events and Descriptors are converted.
Language and Utility Packages	java.lang java.util java.util.jar java.util.zip	Partially Converted	The functionality of java.lang and java.util packages is converted. The functionality of java.util.jar and java.util.zip packages is not converted.
Miscellaneous Features	The @deprecated Tag The APPLET Tag	Converted	JavaDoc tags are converted to .NET Framework Doc tags. Html <Applet> tag is converted to <Object> tag for Applet conversion.
Networking	java.net	Partially Converted	Encoding and Decoding parts in this package are not converted.
Object Serialization	java.io.Externalizable java.io.Serializable	Partially Converted	The core functionality of this package is converted. Some source-code patterns are not converted. The repository containing the serialized objects could require further conversion.
Package Version Identification	java.lang.Class java.lang.ClassLoader java.lang.Package java.lang.System	Partially Converted	Java Package Versioning does not apply for the .NET Framework. Some of the functionality of this package is converted.
Reference Objects	java.lang.ref	Partially Converted	WeakReference is converted.
Reflection	java.lang.reflect	Partially Converted	Advanced features are not converted.
Remote Method Invocation (RMI)	java.rmi java.rmi.activation java.rmi.dgc java.rmi.registry java.rmi.server	Partially Converted	The client conversion is based on source-code patterns. Some complementary functionality is not converted.
Resources	java.lang.Class java.lang.ClassLoader java.net.URLClassLoader java.util.ResourceBundle java.security SecurityManagement	Partially Converted	The Class Loading functionality is not converted. Remaining core functionality is converted with different behavior at times.
Security and Signed Applets	java.security java.security.cert java.security.interfaces java.security.spec	Partially Converted	The classes and interfaces holding Certificates, Keys, Signatures, Principals, Permissions, Digests and Encryption Algorithms are converted.
Sound	javax.sound.midi javax.sound.midi.spi javax.sound.sampled javax.sound.sampled.spi	Partially Converted	The javax.sound.sampled package is converted to Microsoft.DirectX.DirectSound, but needs Managed DirectX installed on the machine.

Table 2: J2SE 1.3 Basic Features Coverage

J2SE 1.3 Java Foundation Classes (JFC)

J2SE 1.3 JFC Feature	API / Functionality	JLCA 3.0 Coverage	Description
2D Graphics and Imaging	com.sun.image.codec.jpeg java.awt java.awt.color java.awt.font java.awt.geom java.awt.image java.awt.print	Partially Converted	The functionality of 2D Graphics and Colors, Fonts and Geometry is converted. Remaining features of this package are not converted or converted with a different behavior.
Abstract Window Toolkit (AWT)	java.awt java.awt.datatransfer java.awt.event	Partially Converted	The widget classes are converted. Conversion for Events is based on source-code patterns. Layout Management conversion is not well achieved.
Accessibility	javax.accessibility	Partially Converted	Highh rate of conversion is achieved for the basic features and is mainly based on source-code patterns.
Drag-and-Drop data transfer	java.awt.dnd	Partially Converted	The conversion supported is based on source-code patterns.
Input Method Framework	java.awt.Component java.awt.event java.awt.im java.text	Not Converted	This functionality does not have an equivalent in the .NET Framework model.
Project Swing Components	javax.swing javax.swing.border javax.swing.colorchooser javax.swing.event javax.swing.filechooser javax.swing.plaf javax.swing.table javax.swing.text javax.swing.tree javax.swing.undo	Partially Converted	The functionality of Models, Editors, Layout Management, Borders, Renderers and Pluggable Look And Feel is not converted.

Table 3: J2SE 1.3 Java Foundation Classes Coverage

J2EE 1.3 Features

J2EE 1.3 Feature	API / Functionality	JLCA 3.0 Coverage	Description
J2EE Connector 1.0		Not Converted	This feature is not supported.
CORBA JavaTM IDL	Idl	Partially Converted	The conversion of IDL Files to .NET framework is covered. The Server and Client side conversion is based on source-code patterns.
CORBA RMI-IIOP	org.omg.CORBA Org.omg.CosNaming	Not Converted	This feature is not supported.
ECperf 1.0		Not Converted	This feature is not supported.
Enterprise JavaBeans (EJBs) 2.0 and 1.1 (CORBA Mapping)	javax.ejb javax.ejb.spi XML Deployment Descriptor	Partially Converted	High rate of conversion is achieved for classes and interfaces for any EJB, Transactions and EJB Security. Container-Managed Persistense (CMP) Entity Beans are converted partially. Client Side conversion is based on source-code patterns. To achieve conversion the ejb-jar.xml file should be included.
Java API for XML Processing (JAXP)	javax.xml.parsers javax.xml.transform	Partially Converted	Conversion to .NET Framework is achieved natively or by means of support classes. Conversion for SAX (org.xml.sax) and DOM (org.w3c.dom) is supported.
Java API for XML Registries (JAXR)	javax.xml.registry	Not Converted	This feature is not supported.
Java API for XML-based RPC (JAX-RPC)	javax.xml.rpc	Not Converted	This feature is not supported.
Java Architecture in XML Binding (JAXB)	javax.xml.bind	Not Converted	This feature is not supported.
Java Database Connectivity (JDBC)	java.sql javax.sql	Partially Converted	High rate of conversion is achieved for JDBC 1.0, for calling statements and stored procedures, data types, transactions and connection pools. For JDBC 2.0, only RowSetMetaData and RowSet are partially converted. The driver operations are not converted.
Java Message Service 1.0.2b	javax.jms	Partially Converted	JMS core functionality is converted to use MSMQ. Some advanced JMS functionality is not converted.
Java Naming and Directory Interface (JNDI)	javax.naming javax.naming.directory javax.naming.event javax.naming.ldap javax.naming.spi Service Providers	Partially Converted	Features related to accessing naming/directory services are converted. Functionality relative to event notification, LDAP and service plugging in is not converted.
Java Servlet 2.3	javax.servlet javax.servlet.http	Partially Converted	The core and HTTP Servlets functionality is converted. Contexts and Bindings are not converted.
Java Transaction API 1.0.1B	javax.transaction javax.transaction.xa	Partially Converted	The support has been added to convert JMS, EJBs and JDBC.
Java Transaction Service 1.0	javax.jts org.omg.CORBA org.omg.CosTransactions Org.omg.CosTSPortability	Not Converted	This feature is not supported.
JavaBeans Activation Framework 1.0.1	javax.activation	Partially Converted	Few functionality conversions have a different behavior.
JavaMail API 1.2	javax.mail javax.mail.event javax.mail.internet javax.mail.search	Partially Converted	The basic mailing functionality is converted while the advanced JavaMail features are not converted.
JavaServer Faces	javax.faces	Not Converted	This feature is not supported.
JavaServer Pages (JSP) 1.2	Core Functionality Tag Libraries JSP Standard Tag Library	Partially Converted	Most of JSP core functionality and tag libraries are converted. Web Application Deployment is made using IIS. Java Standard Tag Library is not converted.
SOAP with Attachments API for Java (SAAJ)	javax.xml.soap	Not Converted	This feature is not supported.

Table 4: J2EE 1.3 Features Coverage

JLCA 3.0 Cheat Sheet – A perspective

GauravS — Fri, 02 Jun 2006 10:23:00 GMT

A lot many times I feel that exhaustive documentation is not available on the Java Language Conversion Tool (JLCA). We have recently been working on the same and in the next few blogs, I would aim to present parts of a cheat sheet for JLCA in the way of my blogs. Here is a list of all topics that I would be covering:

========

INTRODUCTION

J2SE AND J2EE COVERAGE

· J2SE 1.3 BASIC FEATURES

· J2SE 1.3 JAVA FOUNDATION CLASSES (JFC)

· J2EE 1.3 FEATURES

JLCA 3.0

· JAVA APIS CONVERSION

· JAVA TECHNOLOGIES CONVERSION

o Java Beans

o Enterprise Java Beans (EJBs)

o Common Object Request Broker Architecture (CORBA)

o Remote Method Invocation (RMI and RMI-IIOP)

o Java Messaging Service (JMS)

o Serialization

o Java Accessibility (JAAPI)

o Java Event Model (AWT and Swing)

o Threads

· USABILITY FEATURES

o Visual Studio .NET Designer Compliant

o JLCA Extensibility Compliant

· MISCELLANEOUS FEATURES

========

With time, as I publish each section, I would make the above as links so that users can read this as one document.