1. Wprowadzenie.
Bardzo często zdarza się, że firmy z branży IT zmuszone są do wykorzystywania różnych środowisk programistycznych celem sprostania wymaganiom klientów. Inną bardzo istotną rzeczą jest to, iż projektuje się aplikacje w ten sposób, aby móc w późniejszym terminie wykorzystać elementy danej aplikacji w innych przedsięwzięciach. Podejście takie jest jak najbardziej naturalne, ponieważ pozwala przede wszystkim na redukcję kosztów i czasu tworzenia oprogramowania, co jest rzeczą fundamentalną w przedsiębiorstwach. Jednak w tej sytuacji może się pojawić nieoczekiwanie problem, gdy okaże się, że mamy do czynienia z różnymi platformami. Takie zderzenie z rzeczywistością może się skończyć właściwie na trzy sposoby. W przypadku najbardziej optymistycznym może istnieć narzędzie do skonwertowania kodu z jednej platformy na drugą i wtedy problem znika. Jednak najczęściej tak dobrze nie jest, co implikuje ręczne konwertowanie kodu pomiędzy platformami. W przypadku najbardziej pesymistycznym dochodzi do zaniechania konwersji i tworzenie komponentu od podstaw zgodnie z wymaganą platformą. Jako przykład można sobie wyobrazić próbę wykorzystania komponentu Javy w środowisku Visual Studio .NET. Zatem łatwo zauważyć, iż w procesie tworzenia oprogramowania istotną rolę pełnią różnego rodzaju konwertery.
Celem niniejszego artykułu jest przedstawienie czytelnikowi narzędzia „Java Language Conversion Assistant 3.0” oraz sposobów konwersji kodu programów rodzimych dla Javy na język Microsoft Visual C#. Następnie zostaną przedstawione przykłady konwertowania: aplikacji konsolowych, windowsowych, programów współbieżnych, a także przykład konwersji JSP na ASP.NET.
2. Opis instalacji oraz narzędzia Java Language Conversion Assistant 3.0 (JLCA 3.0).
Java Language Conversion Assistant jest narzędziem służącym do dokonywania konwersji kodu z języka Java lub Visual J++ na język Visual C#. Wersja 3.0 JLCA powstała na bazie JLCA 2.0 w stosunku do której prowadzono wiele nowych możliwości konwersji. Jako przykład można podać tutaj możliwość konwersji: Java Server Pages, servlety, Windows Foundation Classes (WFC), Abstract Windowing Toolkit (AWT), EJB, JAAS, JCE, JMS, JNDI, RMI, CORBA oraz aplikacje oparte na bibliotece Swing.
Minimalne wymagania sprzętowe, jakie muszą zostać spełnione to:
Procesor: Pentium PIII, 500MHz
RAM: 256MB
Przestrzeń dyskowa: 200MB
System operacyjny: Rekomendowany Windows XP
Wymagany: Microsoft Visual Studio .NET 2003
Proces instalacji jest właściwie dwu etapowy. Pierwszy etap związany jest z instalacją właściwego narzędzia JLCA, a następnie przechodzimy do instalacji dokumentacji związanej z JLCA. Po zainstalowaniu obu składników można już uruchomić środowisko VS.NET i odszukać zainstalowanych komponentów. Mianowicie dokumentacja znajduje się w zakładce HELP -> Contents lecz aby ją ujrzeć należy wybrać filtr Visual C#. Natomiast samo narzędzie JLCA znajduje się pod zakładką: FILE -> Open -> Convert.
Rys. 1: Okno wyboru narzędzia do konwersji.
Sposób konwersji:
Kiedy Java Language Conversion Assistant jest już zainstalowany można przystąpić do skonwertowania pierwszego prostego źródła z języka Java na język Visual C#.
Sposób konwersji najprościej jest przedstawić na oczywistym przykładzie. Dlatego też spójrzmy na poniższą klasę w języku Java:
[Kod Java]
//HelloWorld.java
public class HelloWorld
{
private static String napis;
/** Creates a new instance of HelloWorld */
public HelloWorld()
{
napis = "";
}
/**
* @param args the command line arguments
*/
public static void main(String[] args)
{
ustaw();
pokaz();
}
private static void pokaz()
{
System.out.println(""+napis);
}
private static void ustaw()
{
napis = "Hello World";
}
}
Wykorzystując JLCA dokonamy konwersji tej klasy z języka Java na język Visual C#. Należy rozpocząć, zatem od wyboru narzędzia konwersji tak, jak pokazano na Rys.1. Następnie stajemy przed wyborem źródła, z jakiego następuje konwersja:
Rys. 2: Okno wyboru typu źródła konwertowanego projektu.
Zgodnie z potrzebami należy wybrać odpowiedni typ źródła. Pierwsza opcja służy do konwersji projektów wykonanych w Visual J++ 6.0. Natomiast druga dotyczy projektów wytworzonych w rodowitym języku Java. W opisywanym przykładzie należy zastosować drugą opcję. Po czym przechodzimy do wyboru miejsca źródła na dysku oraz istnieje możliwość wskazania miejsca plików dodatkowych np. wykorzystywanych bibliotek w projekcie:
Rys. 3: Okno wyboru plików źródłowych do konwersji
Następnym krokiem jest nazwanie projektu, który będzie wynikiem konwersji oraz wybranie typu aplikacji:
Rys. 4: Okno wyboru nazwy i typu projektu.
W opisywanym przykładzie powinno się wybrać typ aplikacji jako konsolowy lub też Class Library. Następnie pozostaje już tylko wybrać miejsce utworzenia projektu oraz zaakceptować wybrane dotychczas ustawienia konwersji. Po zakończeniu pracy JLCA generowany jest raport, w którym są zgromadzone wszystkie uwagi oraz ustawienia dotyczące procesu konwertowania, ewentualne błędy oraz lista utworzonych plików.
Rys. 5: Raport z przeprowadzonej konwersji.
Po tak przeprowadzonym procesie konwersji można już uruchomić projekt i obejrzeć nowy kod w języku Visual C#.
[Kod C#]
//HelloWorld.cs
using System;
/// <summary> </summary>
/// <author>
/// </author>
public class HelloWorld
{
private static System.String napis;
/// <summary>Creates a new instance of HelloWorld </summary>
public HelloWorld()
{
napis = "";
}
/// <param name="args">the command line arguments
/// </param>
[STAThread]
public static void Main(System.String[] args)
{
ustaw();
pokaz();
}
private static void pokaz()
{
System.Console.Out.WriteLine("" + napis);
}
private static void ustaw()
{
napis = "Hello World";
}
}
Po przeanalizowaniu obu fragmentów kodu widać wyraźnie, że konwersja obejmuje wszystkie elementy języka łącznie z komentarzami, typami i zasięgami zmiennych i funkcji.
Po przeprowadzeniu konwersji jest możliwe dostosowanie kodu do potrzeb. Często jest to wymagane, ponieważ po konwersji wyświetlany jest raport informujący o powstałych błędach, które trzeba poprawić już ręcznie.
3. Konwersja konsolowej aplikacji wielowątkowej – przyczyny błędów.
Przykładem aplikacji konsolowej, działającej w oparciu o kilka wątków może być np. obliczanie całki oznaczonej na zadanym przedziale z dokładnością delta metodą Romberga. W tej implementacji algorytmu zastosowano podejście rekurencyjne w kreowaniu i uruchamianiu wątków. Mianowicie początkowo tworzony jest wątek, który sprawdza szerokość przedziału, po jakim ma całkować i jeśli jest on mniejszy od 0,1 to sam wykonuje całkowanie, a na końcu w synchronizowanym bloku dodaje swój wynik do całościowego wyniku całki. Jeśli jednak przedział ten jest większy to dzieli przedział na dwie połowy i tworzy oraz uruchamia dla każdej z nich nowy wątek, który zajmuje się ich całkowaniem. Poniżej zamieszczony jest najistotniejszy fragment kodu klasy odpowiadającej za wątek całkujący:
[Kod Java]
//CalkaClass.java
import java.util.*;
public class CalkaClass extends Thread
{
double start;
double stop;
double step;
/** Creates a new instance of WatekA */
public CalkaClass(double start, double stop, double step)
{
super();
this.start = start;
this.stop = stop;
this.step = step;
}
public void run()
{
if((stop-start) < 0.1)
{
double moje_obl=0;
double x1=start;
double x2=start + step;
while(x2 <= (stop+step))
{
moje_obl = moje_obl + 0.5*(x2-x1)*(xkwadrat(x1)+xkwadrat(x2));
x1 = x1 + step;
x2 = x2 + step;
}
synchronized(oblcalki.rygiel)
{
oblcalki.calka = oblcalki.calka + moje_obl;
}
}
else
{
new CalkaClass(start, start+(stop-start)/2, step).start();
new CalkaClass(start+(stop-start)/2, stop, step).start();
}
}
}
Poniżej natomiast jest umieszczona metoda main wątku głównego, który tworzy wątek całkujący i oczekuje na zakończenie wszystkich procesów całkowania, aby na końcu wyświetlić wynik ostateczny:
[Kod Java]
//Z klasy oblcalki.java
public static void main(String[] args)
{
oblcalki ob = new oblcalki();
new CalkaClass(0.0, 27.0, 0.0000001).start();
while(CalkaClass.activeCount() > 1)
{
try
{
Thread.sleep(100);
}
catch(InterruptedException ie)
{
}
}
System.out.println(""+calka);
}
Cały kod programu znajduje się w załączonym pliku z przykładami!
Tak przygotowane pliki Javy można teraz poddać konwersji na język Visual C#. Jako parametry konwersji należy ustawić: źródło to pliki języka Java (Rys. 2) oraz typ źródła to aplikacja konsolowa (Rys. 4). Po przeprowadzonym procesie konwersji należy zwrócić szczególną uwagę na wygenerowany raport, ponieważ może się zdarzyć, że pewne elementy mogą zostać niepoprawnie skonwertowane lub też nie zostały skonwertowane w cale.
Rys. 6: Raport z konwersji konsolowej aplikacji wielowątkowej.
Po przeanalizowaniu powyższego raportu widać, że klasa CalkaClass.java została przekonwertowana bezbłędnie, czyli że każdy element języka Java znalazł swój odpowiednik w języku Visual C#. Jednak już w klasie oblcalki.java konwersja nie przebiegła tak gładko. Zostały wyodrębnione dwa błędy.
Pierwszy błąd jest związany ze statyczną metodą Sleep klasy Thread w aspekcie behawioralnym. Mianowicie problem jest związany z argumentami, jakie przyjmują. Okazuje się, że funkcja Javy przyjmuje argument typu long i oznacza on milisekundy natomiast funkcja z języka C# traktuje ten argument jako (ang. tick) czyli setki nanosekund.
Drugi błąd jest związany z niemożliwością konwersji statycznej metody activeCount klasy Thread, ponieważ w języku Visual C# nie ma odpowiednika takiej funkcji. W związku z tym należy zastąpić tą funkcję jakąś inną, jeśli jest lub zaimplementować własną. Poniżej przedstawiono fragment kodu z klasy CalkaClass.cs po konwersji:
[Kod C#]
using System;
public class CalkaClass:SupportClass.ThreadClass
{
internal double start;
internal double stop;
internal double step;
/// <summary>Creates a new instance of CalkaClass </summary>
public CalkaClass(double start, double stop, double step):base()
{
this.start = start;
this.stop = stop;
this.step = step;
}
override public void Run()
{
if ((stop - start) < 0.1)
{
double moje_obl = 0;
double x1 = start;
double x2 = start + step;
while (x2 <= (stop + step))
{
moje_obl = moje_obl + 0.5 * (x2 - x1) * (xkwadrat(x1) + xkwadrat(x2));
x1 = x1 + step;
x2 = x2 + step;
}
lock (oblcalki.rygiel)
{
oblcalki.calka = oblcalki.calka + moje_obl;
}
}
else
{
new CalkaClass(start, start + (stop - start) / 2, step).Start();
new CalkaClass(start + (stop - start) / 2, stop, step).Start();
}
}
}
Najbardziej strategicznymi elementami tej klasy jest dziedziczenie po klasie Thread, wywołanie konstruktora klasy, z której dziedziczono, kreowanie wątków i ich uruchamianie oraz wykonywanie obliczeń w bloku synchronizowanym. Przyglądając się powyższemu fragmentowi kodu widać, że wszystkie te elementy zostały pokryte bez zarzutu, co spowodowało bezbłędną konwersję.
Drugą konwertowana klasą była oblcalki.java z której powstała klasa oblcalki.cs. Poniżej przedstawiono tylko metodę Main z tej klasy.
[Kod C#]
public static void Main(System.String[] args)
{
oblcalki ob = new oblcalki();
new CalkaClass(0.0, 27.0, 0.0000001).Start();
//UPGRADE_ISSUE: Method 'java.lang.Thread.activeCount' was not converted. 'mshelp://MS.VSCC.2003/commoner/redir/redirect.htm?keyword="jlca1000_javalangThreadactiveCount_3"'
while (CalkaClass.activeCount() > 1)
{
try
{
//UPGRADE_TODO: Method 'java.lang.Thread.sleep' was converted to 'System.Threading.Thread.Sleep' which has a different behavior. 'mshelp://MS.VSCC.2003/commoner/redir/redirect.htm?keyword="jlca1073_javalangThreadsleep_long_3"'
System.Threading.Thread.Sleep(new System.TimeSpan((System.Int64) 10000 * 100));
}
catch (System.Threading.ThreadInterruptedException ie)
{
}
}
System.Console.Out.WriteLine("" + calka);
}
Do powstałego pliku od razu zostaje wygenerowany komentarz do metod, z którymi był problem podczas procesu konwersji. Ma to na celu prostsze odszukanie tych metod oraz ułatwienie podczas modyfikacji.
4. Konwersja aplikacji okienkowej (AWT vs. SWING) – przyczyny błędów.
Kolejnymi przykładami konwersji, jakie zostaną zaprezentowane, to przykłady aplikacji okienkowych. Mianowicie aplikacje wytworzone za pomocą komponentów Swing oraz AWT. Celem tego rozdziału jest przedstawienie różnic w konwersji obu wspomnianych technik, co może okazać się przydatne podczas tworzenia projektów w Javie, które będą konwertowane do języka Visual C#. Obie aplikacje są identyczne pod względem realizowanych funkcji, ponieważ realizują te same podstawowe funkcje kalkulatora.
Przykład AWTForm.java:
Przykład ten ma na celu zilustrowanie konwersji aplikacji okienkowych utworzonych z komponentów AWT. Poniżej przedstawione są fragmenty kodu w języku Java tuż przed konwersją.
Deklaracje zmiennych:
[Kod Java]
private java.awt.Button button1;
private java.awt.Button button2;
private java.awt.Button button3;
private java.awt.Button button4;
private java.awt.Label label1;
private java.awt.Label label2;
private java.awt.Label label3;
private java.awt.TextField textField1;
private java.awt.TextField textField2;
private java.awt.TextField textField3;
Przykład funkcji odpowiedzialnej za dodawanie dwóch liczb:
[Kod Java]
private void button1ActionPerformed(java.awt.event.ActionEvent evt)
{
String a = this.textField1.getText();
String b = this.textField2.getText();
this.textField3.setText(""+(Double.parseDouble(a)+Double.parseDouble(b)));
}
Metoda „main” klasy AWTForm.java:
[Kod Java]
public static void main(String args[])
{
new AWTForm().show();
}
Warto przyjrzeć się szczególnie metodzie „main” przed i po konwersji, ponieważ niezbędne okaże się wprowadzanie pewnych modyfikacji w jej ciele.
Tak przygotowany plik można już poddać konwersji i zwrócić szczególną uwagę na raport, jaki zostanie wygenerowany po zakończeniu. Należy jeszcze wspomnieć o ustawieniach trybu konwersji, mianowicie należy ustawić typ aplikacji jako „Windows Application” (Rys. 4).
Po wygenerowaniu raportu łatwo zauważyć, iż zostało wylistowanych 10 tych samych błędów związanych z próbą konwertowania metody: 'java.awt.Container.add' do metody: 'System.Windows.Forms.ContainerControl.Controls.Add'
Mianowicie pojawia się tutaj ostrzeżenie o możliwości nieprawidłowego działania związanego z aspektem behawioralnym funkcji. Jednak w tym przypadku metoda ta działa poprawnie i nie potrzebne są żadne zmiany. Inaczej dzieje się w przypadku przekonwertowanej metody „Main”, która została zamieszczona poniżej:
[Kod C#]
public static void Main(System.String[] args)
{
//UPGRADE_TODO: 'System.Windows.Forms.Application.Run' must be called to start a main form. 'ms-help://MS.VSCC.2003/commoner/redir/redirect.htm?keyword="jlca1135_3"'
new AWTForm().Show();
}
Okazuje się, że po konwersji metoda Main zawiera nadal Javowy sposób uruchamiania formularza. Otóż w komentarzu do funkcji otrzymujemy wskazówkę, iż musi zostać wywołana metoda 'System.Windows.Forms.Application.Run'.
Zgodnie ze wskazówkami należy dokonać pewnych zmian i ostatecznie można otrzymać:
[Kod C#]
public static void Main(System.String[] args)
{
Application.Run(new AWTForm());
}
Poniżej zamieszczono także deklaracje zmiennych, aby uwidocznić ich sposób konwersji:
[Kod C#]
private System.Windows.Forms.Button button1;
private System.Windows.Forms.Button button2;
private System.Windows.Forms.Button button3;
private System.Windows.Forms.Button button4;
private System.Windows.Forms.Label label1;
private System.Windows.Forms.Label label2;
private System.Windows.Forms.Label label3;
private System.Windows.Forms.TextBox textField1;
private System.Windows.Forms.TextBox textField2;
private System.Windows.Forms.TextBox textField3;
Należy jeszcze nadmienić, iż aby było możliwe uruchomienie programu należy dołączyć dodatkowo kilka bibliotek, mianowicie:
[Kod C#]
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;
Poniżej przedstawiono dla formalności funkcję odpowiedzialną za dodawanie liczb po konwersji:
[Kod C#]
private void button1ActionPerformed(System.Object event_sender, System.EventArgs evt)
{
//GEN-FIRST:event_button1ActionPerformed
System.String a = this.textField1.Text;
System.String b = this.textField2.Text;
this.textField3.Text = "" + (System.Double.Parse(a) + System.Double.Parse(b));
}
Tak skonwertowana i nieznacznie poprawiona aplikacja jest już gotowa do uruchomienia. Widać, że JLCA dokonał w przypadku AWT niemal idealnej konwersji. Kolejnym przykładem będzie ta sama aplikacja jednak wykonana z wykorzystaniem komponentów SWING.
Przykład SwingForm.java:
Podobnie jak w poprzednim przykładzie należy rozpocząć od deklaracji zmiennych. W związku z tym, że tym razem jest wykorzystywana biblioteka Swing deklaracje te wyglądają następująco:
[Kod Java]
private javax.swing.JButton jButton1;
private javax.swing.JButton jButton2;
private javax.swing.JButton jButton3;
private javax.swing.JButton jButton4;
private javax.swing.JLabel jLabel1;
private javax.swing.JLabel jLabel2;
private javax.swing.JLabel jLabel3;
private javax.swing.JTextField jTextField1;
private javax.swing.JTextField jTextField2;
private javax.swing.JTextField jTextField3;
Ważnym aspektem okaże się także metoda „main” klasy SwingForm.java, która zamieszczona jest poniżej:
[Kod Java]
public static void main(String args[])
{
new SwingForm().show();
}
Do pełnego obrazu konwersji umieszczona zostanie także poniżej funkcja realizująca dodawanie:
[Kod Java]
private void jButton1ActionPerformed(java.awt.event.ActionEvent evt)
{
String a = this.jTextField1.getText();
String b = this.jTextField2.getText();
this.jTextField3.setText(""+(Double.parseDouble(a)+Double.parseDouble(b)));
}
Zatem teraz można dokonać już konwersji oraz przeanalizować wygenerowany raport. Otóż okazuje się, że podczas konwersji powstało 30 błędów, z których dwa powtarzają się na przemian.
Pierwszym błędem jest próba konwersji metody: 'javax.swing.JFrame.getContentPane' na 'System.Windows.Forms.Form'. Oczywiście po raz kolejny konwerter informuje o tym, że aspekt behawioralny funkcji może się różnić, aczkolwiek nie musi. Jednak ostrzeżenie to jest generowane w celu upewnienia się użytkownika czy na pewno konwersja przebiegła poprawnie.
Drugim błędem jest znany już z poprzedniego przykładu problem konwersji: 'java.awt.Container.add' do metody: 'System.Windows.Forms.ContainerControl.Controls.Add'.
W obydwu przypadkach konwersja wydaje się być prawidłowa, zatem nie należy dokonywać zmian. Podobnie jak w poprzednim przykładzie deklaracja zmiennych zaszła poprawnie:
[Kod C#]
private System.Windows.Forms.Button jButton1;
private System.Windows.Forms.Button jButton2;
private System.Windows.Forms.Button jButton3;
private System.Windows.Forms.Button jButton4;
private System.Windows.Forms.Label jLabel1;
private System.Windows.Forms.Label jLabel2;
private System.Windows.Forms.Label jLabel3;
private System.Windows.Forms.TextBox jTextField1;
private System.Windows.Forms.TextBox jTextField2;
private System.Windows.Forms.TextBox jTextField3;
Nieco zmian należy dokonać w powstałej metodzie „Main”. Jednak są to zmiany identyczne jak w poprzednim przykładzie:
[Kod C#]
public static void Main(System.String[] args)
{
//UPGRADE_TODO: 'System.Windows.Forms.Application.Run' must be called to start a main form. 'ms-help://MS.VSCC.2003/commoner/redir/redirect.htm?keyword="jlca1135_3"'
//new SwingForm().Show();
Application.Run(new SwingForm());
}
Ostatni już błąd, jaki pojawił się w trakcie konwersji dotyczy funkcji kalkulatora i pojawia się we wszystkich funkcjach tj. dodawania, odejmowania, mnożenie oraz dzielenia. Dotyczy on mianowicie metody ustawiającej wartość pola TextBox. Otóż generowany jest następujący komunikat o dokonaniu konwersji metody: 'javax.swing.text.JTextComponent.setText' na 'System.Windows.Forms.TextBoxBase.Text'.
Błąd wynika z tego, że funkcja została skonwertowana nie na funkcję, lecz na zmienną typu (ang. property), czyli własność pola TextBox. Także w tym przypadku okazuje się, że konwersja odbyła się poprawnie. W celu zaobserwowania różnic przykład funkcji dodawania po konwersji umieszczony jest poniżej:
[Kod C#]
private void jButton1ActionPerformed(System.Object event_sender, System.EventArgs evt)
{
//GEN-FIRST:event_jButton1ActionPerformed
System.String a = this.jTextField1.Text;
System.String b = this.jTextField2.Text;
//UPGRADE_TODO: Method 'javax.swing.text.JTextComponent.setText' was converted to 'System.Windows.Forms.TextBoxBase.Text' which has a different behavior.
this.jTextField3.Text = "" + (System.Double.Parse(a) + System.Double.Parse(b));
}
Porównując obie techniki tworzenia aplikacji okienkowych w języku Java, a następnie konwertowanie ich na język Visual C#, skonwertowany kod okazuje się wiernie odzwierciedlać oryginał, jeżeli chodzi o funkcjonalność. Ilość błędów wygenerowanych prze JLCA podczas konwersji aplikacji AWTForm była prawie dwukrotnie mniejsza niż dla konwersji SwingForm. W większości przypadków błędy się powtarzają i są sygnalizacją ewentualnej różnicy w działaniu funkcji. Bardzo rzadko zdarza się, że funkcja nie jest konwertowana w cale, zmusza to jednak do własnej implementacji tej funkcji lub zastąpienia ją inną.
5. Konkluzja.
Microsoft Java Language Conversion Assistant 3.0 w porównaniu do swojej poprzedniej wersji jest zdecydowanie bardziej zaawansowanym narzędziem. Udostępnia o wiele większy wachlarz konwersji oraz wprowadza prostotę i niezawodność. Chociaż podczas konwersji metod dochodzi do wielu błędów to większość z nich sprowadza się do sprawdzenia ich aspektu behawioralnego. Nie da się jednak zaprzeczyć, iż podczas konwersji złożonych aplikacji ilość błędów może być znaczna i wtedy manualne sprawdzenie wszystkich błędów byłoby bardzo nieporęczne.