Partager via

JLCA 3.0 - Usability Features

  • Article

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

Comments