Freigeben über

JLCA - The Source Converter Tool

  • Artikel

Ah! I wish that the Java Language Conversion Assistant should have been a tool so powerful that one just needs to provide the project files/solution to it, do some settings and BINGO... you have a solution available, up and running, which is completely migrated to C#, makes use of the complete technology set made available by then .NET Framework and needs no further user intervention other than building and deploying the solution.

I presume I am talking of an ideal scenario or a dream tool. Neah! Not exactly. Though this should be the best possible tool available, but tools and software evolve over a period of time. There is nothing called perfect in terms of software products. The reasons can be many like the changing needs of the customers, the evolving technologies etc. But evolution must continue.

For any product, it is equally important to know, discuss and improve upon the pain points as it is to know what the product does well. Thus today I am going to talk about a few issues that the users should be aware of while they are migrating their Java/J2EE solutions to C# and .NET Framework using the JLCA tool. The knowledge about these would help you plan your migrations more effectively. I am summarizing the points under various subcategories of technologies JLCA helps migrate. Though this not be an exhaustive list, here are what my finding are with the JLCA tool (would post more on similar lines in days to come):

Java Beans
- Conversion for Icons used to represent Java Beans in tool boxes or list views is not supported.
- Conversion for setting the default event to a Java as Multicast is not converted. Setting event descriptors as Unicast is not supported, too.

EJB’s
- 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 target .NET Serviced Components.
- Transaction Isolation Levels are not converted. For container-managed transaction, they are specified using vendor-specific tools. For bean-managed transactions they are specified using an API (like java.sql.Connection.setTransactionIsolation()).
- Environment Entries are not converted at all because logical references publishing –before performed through JNDI- must be executed from a Directory Service. A workaround could require publish the resource in a Directory Service like ADS and specify -in the target code- where the resource was published.
- Stateful Session Beans are not converted entirely because COM+ is a stateless technology in the sense it require to manage “session state” for each client.
- State Synchronization availability with the outcome of transactions is not converted since COM+ is able to manage transactions in a different way.
- Entity beans relationships with another one are not entirely converted, since they are based on the underlying vendor-specific datastore schema. For each relation, JLCA converts the relations by means of a Serviced Component fields and provides a dummy implementation for the respective properties. Additional steps could require set each property -for each relation- with the respective value.

CORBA support
- 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 as the code is vendor dependant. Also, conversion for applications using Portable Object Adapters (POA) instead of Basic Object Adapters (BOA) requires a little user-intervention. Also, the POA policies functionality could be lost. On the other hand, clients using Dynamic Invocation Interface (DII) are not converted.
- Java CORBA applications using DSI are not converted.

RMI and RMI-IIOP
- Although in .NET, there are ways for loading dynamically external libraries/assemblies, there is no equivalent for RMI Dynamic Class Loading features (such as use java.rmi.server.RMIClassLoader).
- Server applications using custom registries to publish remote objects (using related classes such as java.rmi.registry.LocateRegistry) are not converted.
- Activatable remote objects are converted to non-activatable remote objects. RMI Activation features are not converted because .NET manages the [de]activation on remote objects differently.
- Although java.rmi.RMISecurityManager is converted, .NET Remoting manages security differently. Issues related to setting up the security properties and policy files are not converted.
- Use of RMI’s System properties to configure the RMI behavior is not converted

NOTE: The limitations presented here are my own observations with the tool. Though the list looks big, the limitations are very meager as compared to quality of migrations that are possible with JLCA3.0 in these feature areas. Most of these limitations and their workarounds are extensively documented in the converted code with appropriate links to documentation inserted at the appropriate places in the converted code.

Comments

  • Anonymous
    March 06, 2006
    The comment has been removed
  • Anonymous
    April 25, 2006
    Continuing from my previous post JLCA - The Source Converter Tool here are some more of my findings...