Malek KemmouTechnology Architect, Application PlatformMicrosoft Middle East and Africamalek@microsoft.com

Java/J2EE to .NET MigrationJava/J2EE to .NET Migration

AgendaAgenda

• Technical Overview of Java to .NET Migration– Migration Approaches– Java/J2EE to .NET Equivalences– Determining an Appropriate Migration

Strategy

Migration Approaches

• Three basic techniques for migrating Java/J2EE solution to .NET:– Manual Migration

• Re-write the solution from scratch in .NET by hand

– Automated Migration• Use tools to automate the migration of source code

or implementation (binary, XML, etc)

– Port/Migrate Java Source to J#:• Recompile Java source using J# compiler/libraries

– Limited to JDK 1.1.4, minus RMI, etc… more on this later

Migration Approaches

• In practice, a hybrid approach is typical:– Automated migration:

• get part of the way (automated migration < 100%)• migrate specific components (like web tier, etc)

– Manual migration:• complete what the automated process didn’t do (or do ‘well’)• re-write solution components to take full advantage of .NET

Fx, etc– Port/Migrate to J#:

• Compile ‘business logic’ code (that doesn’t directly use platform APIs) to J# to run on .NET

• As long as the business logic code is factored to NOT directly use APIs > JDK 1.1.4, or RMI, or 3rd party Java libraries, etc

• NOTE: Typically, Java code is not factored into distinct business logic code and infrastructure/platform code – this approach will only be applicable in a minority of cases….

Manual Migration

• Re-Write (from scratch) Solution or Component in .NET– For instance, a .NET WinForms client as a replacement for an existing

Swing client• The requirements and functionality are replicated, but an entirely

new architecture, codebase, etc. is implemented• Develop new solution in C# or J#:

– C# and Java have a lot of similarities… Java devs usually don’t have difficulty getting quickly up to speed on C#

– However…J# can be used to leverage existing Java Language development skills, while supporting development on .NET (also, there are other aspects of J# discussed later that may tip the scales in favor of using J#)

• Requires:– Good understanding of .NET APIs, architecture, programming models,

idioms, tools and products to take full advantage of platform

Manual Migration Approach (cont)

• Pros:– Take full advantage of .NET, Windows, etc – Architecture, Fx,

PAG blocks, etc.• Existing Java solution may be old (legacy), poorly architected – a

chance to build new version, apply lessons learned• Automated migration produces a more direct equivalent of Java

solution, and will not be as optimal– In-house resources eventually will be (more) familiar and trained

in .NET, C#/J#, Visual Studio, etc.• Cons:

– Potentially significant effort to re-implement (depending on size/breadth of Java Solution)

– Experienced .NET Architects/Developers are required:• Significant training/experience needed for in-house (java) devs• Or experienced 3rd party resources (MCS, etc)

Automated Migration Approach

• Use automated code conversion tools to produce ‘equivalent’ .NET source or binary code

• Tools to convert Java source code:– Java Language Conversion Assistant (JLCA) – Visual Studio Wizard

which can convert VJ++, J2SE 1.4, and J2EE 1.3 source code to C#/.NET

– VJ++ Upgrade Wizard – convert complete VJ++ projects to VJ#.NET solutions

• Tools to convert Java binary code:– Java Binary Conversion Utility (JBImp) – to convert Java binary (byte

code, up to JDK 1.1.4) to .NET MSIL • Conversion coverage:

– Conversion is < 100%... It CAN be up to 80-85%, depending on what JDK versions are used, what standard and 3rd party APIs are used, etc.

– Considerable understanding of .NET Fx, architecture, etc. is also required for fixing up unconverted code, 3rd party APIs, etc.

JLCA

• JLCA is a free Visual Studio Add-In• Current (3.0) version is available for download• File->Open->Convert… to select an existing

Java source tree or VJ++ project• Converter generates C# source, VS solution

files, and a conversion report showing the various files that were produced, and conversion issues/ommisions

JLCA - cont

• The conversion process is ‘conservative’ and reports anything that may be an issue, so the report is often large… don’t be alarmed!– Many of the warnings are about checking that

converted items exhibit slightly different behavior, but for most cases, these are okay.

• E.g. java.lang.toString -> System.ToString. ‘toString’ is used a lot, and each of the usages will be flagged, but in 95% of the cases, the converted behavior is fine… this will generate a lot of (harmless) warnings

– Common code and API usages may generate many of the same JLCA warnings or issues. Usually, these can be fixed by copy/replace for all the items, quickly dealing with many items in the report

JLCA - Cont

• Java Source:

JLCA - Cont

• Conversion Report:

JLCA - Cont

• Visual Studio Solution/C# Source:

JLCA Companion

• The JLCA Companion is an additional add-on tool to the JLCA that allows new migration rules to be added, and existing ones to be modified:– Can be used to create custom rules to automate conversion of

in-house or 3rd party APIs (e.g. not part of standard J2SE/J2EE)– Implement automated conversion for common coding patterns

and design idioms used throughout a project or organization

• Artinsoft (the makers of the JLCA) license the JLCA Companion for a fee

• Contact Artinsoft for further details on licensing and usage:– http://www.artinsoft.com

JBImp

• Java Binary Conversion Utility – command line executable that comes as part of the JLCA

• Converts Java byte code into .NET MSIL• Useful for converting existing (legacy) binary

code where source is not available– Limitations:

• Java version limited to 1.1.4 (minus RMI, JNI, etc) – same feature limits and additions as J++.

• Suitable permissions are necessary (e.g. can’t convert a commercial, 3rd party library without consent)

VJ++ Upgrade Wizard

• Part of Visual J#.NET

• Opening a VJ++ project in VJ#.NET will run the upgrade wizard and completely convert it to a J#.NET project.

• Useful for converting any of those VJ++ projects laying around

• If only binary available, Jbimp can be used to convert that to MSIL

Automated Migration

• Pros:– Can be considerably faster to migrate, depending on how much

the JLCA can convert• For ‘standard’ J2SE/J2EE apps, upwards of 80-85% conversion can

be achieved– Resources can incrementally learn .NET, C# as they go along and

resolve migration issues• Cons:

– Does a very literal migration at a code level, reproducing java programming structure and idioms, potentially producing less than optimal .NET architecture, design, and code

– Requires understanding of the JLCA tool and mappings, it’s uses and limitations

– If a Java solution uses a wide range of Java APIs, 3rd party libraries, and some of the more ‘complicated’ bits of J2SE or J2EE (like CMP Entity Beans), considerably less of the source will be converted

Port/Migrate Java Source to J#

• J# supports Java Language Syntax (Java Language Spec 2.0)• J# implements JDK 1.1.4 functionality

– Minus RMI, JNI– Plus 1.2 Collections API– Plus WFC, J/Direct, Java/COM integration

• Java source code that fits within these bounds can be re-compiled under J# to produce .NET implementation

• Java code that doesn’t directly access platform APIs can be recompiled to MSIL to run on .NET– Business logic code that doesn’t directly call platform APIs– However, often business logic and calls to platform APIs are

intermingled• Mixed porting and migration approach

– Migrating (factoring) the Java source into ‘business logic’ and infrastructure/platform code

– Migrate the infrastructure/platform code manually or using automated tools

J# Browser Controls

• J# Browser Controls are browser-based equivalent to Java Applets• J# Browser Controls (v1.1) requires the following on client (browser)

host:– J# Browser Controls runtime– VJ# .NET 1.1 Redistributable package– .NET Framework SDK 1.1– Internet Explorer 5.1+

• Migrating an Applet to J# Browser Control involves:– Compiling Applet source code using J#– Updating HTML code to change Applet/Object tag to reference J#

Browser Control– Deploy the J# browser control and updated HTML

• If Applets utilize basic (JDK 1.1.4) functionality, then migration is as simple as recompile under J#, and deploying J# and .NET related infrastructure to client

Port/Migrate Java Source to J#

• Pros:– J# is a first class .NET language, fully supported for at least 7 years from

Whidbey– Resources can leverage their existing (Java) knowledge, and move to .NET

easier – For J2SE solutions applicable Java source code, no ‘migration’ necessary…

just recompile. – If the Java source conforms to all the limitations (e.g. JDK 1.1.4, etc), then

this is a very quick migration• Cons:

– Most Java solutions will contain code that operates against current JDK (1.3/1.4), not JDK 1.1.4.

• If the code is well factored, there may be ‘business logic’ which doesn’t directly use the 1.3/1.4 APIs (much)… But in many cases, this won’t be the case

– Not applicable for J2EE/EJB– Requires deployment of VJ# redistributable package (in addition to .NET Fx)– If J# Browser controls are used, they also need to be installed on client host

The Java Migration Workshop

• A 3 Day, Hands-on workshop available at CTECs• Target audience is Java/J2EE architects and devs• Includes:

– Equivalences between J2SE/J2EE and .NET

– Manual and automated migration approaches and tools

– Module on J#

– Hands On Labs, which account for 50% of the total workshop time

Java/J2EE to .NET Equivalences

• Objectives:– Provide confidence (and reduce risk) associated with technical

feasibility of migration– Gain understanding of .NET at various levels, framed in terms of

(familiar) Java aspects

• Approach:– Show how Java/J2EE solution elements will (should) be

migrated to .NET– Leverage knowledge of existing Java architecture, design,

language to show how .NET provides equivalent (or better) capabilities

• Demonstrate that much of J2EE capabilities can be elegantly supported in .NET

• A good Java architect will be a good .NET architect!

Java/J2EE to .NET Equivalences - Cont

• Equivalences are done at several levels:– Language

• Java -> C#, J#

– APIs• e.g. JDBC -> ADO.NET

– Architecture/Idioms• e.g. RMI -> .NET Remoting

– Programming Models• e.g. JNDI -> ADSI

– Solution Architectures• e.g. Web App: JSP/Servlets/Struts/JDBC -> ASP.NET/Code

Behind/UIP Block/ADO.NET)

– Configuration/Deployment • JAR/WAR/EAR -> Assembly, .config,

Java/J2EE to .NET Equivalences - Cont

• There are many similarities in platform (leading to close mappings), however there are also distinct differences (.NET platform advantage)

• Ultimately, this information is useful for any migration approach:– Manual migration – developers can leverage their existing Java

knowledge to (better, quicker) understand .NET, and begin architecture/design of new .NET version

– Automated migration – developers need to know what the tools will produce, what the limitations are, where they may want to manually fixup to (better) utilize .NET, etc

– People migration – useful for presenting .NET technical details (without competetive FUD) to Java architects and devs, enabling them to gain understanding based on their existing Java knowledge

Java/J2EE to .NET Equivalences - Cont

• Java Migration Workshop includes equivalences • Module 1-3 – Mapping ‘basic’ J2SE to .NET

– J2SE 1.1.4 level API’s – consistent with what is defined in J++, J#

• Module 4 – Mapping ‘extended’ J2SE to .NET– J2SE 1.4 level API’s

• Module 5 – Mapping J2EE to .NET– J2EE 1.3

Determining A Suitable Migration Strategy

• Choose Manual Migration (Re-write) When:– Want to take full advantage of .NET, Windows, and

enterprise products like LCS, Sharepoint, Biztalk, etc.– The Java Solution uses significant 3rd party APIs or

custom APIs that will probably not migrate easily– The existing solution uses a wide range of Java APIs,

significant elements of J2SE/J2EE, programming idioms like JNDI, JCA, etc.

– The existing app is old and is time to be re-written, and/or there is a desire to create a truly .NET-native, .NET-architected solution

Determining A Suitable Migration Strategy

• Choose Automated Migration When:– Java Solution developed using relatively

standard J2SE and J2EE APIs– The existing solution is reasonably architected– A minimal amount of effort for migration is

desired (e.g. “just get it running natively on .NET”)

– A large system, that needs to be migrated within a specific (short) time frame

Determining A Suitable Migration Strategy - Cont

• Choose Port/Migrate to J# When:– Want to leverage existing Java language

development skills, and smooth(er) the transition to .NET development, while still taking full advantage of .NET platform, Visual Studio, etc

– Java solutions that include Applets (that can easily migrate to J# Browser controls)

– The Java solution fits within the bounds of J# JDK version and APIs

• OR, the Java solution is factored (or can be factored) to segregate pure Java Language logic (e.g. Business Logic) apart from infrastructure/platform calls

Determining A Suitable Migration Strategy - Cont

• Ultimately every situation is unique in some way(s), and a hybrid approach that considers a combination of these approaches may be the most optimal:– Use automated tools (JLCA) to get you part of

the way (50%+)– Use manual approaches to complete items

that JLCA doesn’t get, and/or re-write solution components in C#/J# to take better advantage of .NET, Web Services, SOA, PAG blocks, etc.

Questions ?