Få genvägar till klient-server med Java

(98-09) Används verktygtillverkarnas förslag på serverprogram kan utvecklingen underlättas. Annars är det bara SQL- och Javahackande som hjälper.

Hur ser då ett bra utvecklingsverktyg för Java ut?

Det ska vara snabbt, användaren ska inte behöva vänta långa stunder. Det ska gå att separatkompilera klasser. Om hela projektet måste kompileras om varje gång något ändras förlorar man tempo. Det ska vara enkelt att använda AWT-klasser (Abstract Windowing Toolkit): Användargränssnittet ska designas grafiskt, och komponenter på skärmen ska lätt kopplas till kod och andra komponenter.

Viktigt är också hur bra hjälp det finns. Hjälp för den aktuella klassen eller komponenten ska aldrig vara mer än ett par tangenttryckningar bort.

Verktyget ska ha grafiskt stöd för databaskoppling med hjälp av JDBC (Java DataBase Connectivity). JDBC går att använda med alla verktyg, men det som skiljer är hur väl det går att grafiskt koppla ihop databasens komponenter (tabeller och så vidare) med Javakoden.

För att testa verktygen satte vi oss ned för att skriva en enkel klient till en relationsdatabas av typ kundregister. Lätt och smidigt med JDBC och moderna grafiska verktyg trodde vi. Lätt var det förvisso, efter att ha insett att all JDBC-kod måste skrivas för hand. De grafiska komponenter som följde med verktygen passade nämligen inte till den JDBC-drivrutin som följer med den använda databasen Postgresql. Konspiratoriskt lagda personer spekulerar i om verktygen bara är avsedda för utveckling med databaser som säljs av respektive verktygstillverkare.

Visualage är det mest »grafiska» verktyget av de testade. Hela program går att rita upp på skärmen, men det normala är att vanligt förekommande klasser - till exempel kommunikation med en postserver via IMAP-protokollet - skrivs som vanlig kod och paketeras som en JavaBean-komponent för vidare bruk i den grafiska editorn. Den främsta anledningen till att inte göra allt arbete grafiskt är att programkod skriven för hand blir mycket effektivare än om den ritas upp. Dessutom finns det ganska många algoritmer som inte passar för att ritas upp, till exempel vanliga for-slingor.

Ett stort plus för större projekt är att all kod lagras i en databas med versionshantering, varje metod med källkod, bytekod och grafisk design för sig. En fleranvändarversion av koddatabasen är utlovat, men har inte dykt upp ännu.

Tyvärr går det inte att importera källkod från andra verktyg för vidare grafisk programmering. För att dela projekt med andra Visualage-utvecklare finns exportfunktioner som ser till att den grafiska designen följer med.

Men koddatabasen upplevs inte bara positivt: Det är svårare för programmerare att skriva löpande, sammanhängande programkod eftersom koden för varje metod ligger i olika fönster. Dessutom kompileras varje metod så fort programmeraren stänger metodfönstret, vilket ger en liten men irriterande paus vid fönsterbyte.

Hjälpfunktionen är usel: All hjälp och dokumentation ligger på en egen webbserver som installeras tillsammans med verktyget. Visserligen finns det kopplingar från Visualage till favoritwebbläsaren, men en integrerad hjälp hade varit många gånger mer produktivitetshöjande.

I den testade Enterprise-versionen av Visualage följer det med komponenter för att komma åt databaser och IBMs transaktionshanterare. Dessutom finns verktyg för att underlätta RMI-programmering (Remote Method Invocation) men inget stöd för Corba-objektmäklare ännu. Databaskopplingen med JDBC var i likhet med de andra verktygen en besvikelse: De färdiga komponenterna fungerande dåligt med vår JDBC-driver, och hade dessutom fel som gjorde att de försvann från skärmen ibland. Med IBMs egna JDBC för DB2 gick det bättre.

Symantec Visual Cafe är i jämförelse med Visual Age snabbt, men kräver mer än 64 Mbyte minne för att komma till sin fulla rätt.

Att skapa underklasser av olika slag, till exempel applet eller frame är lätt, verktyget lägger automatiskt till all initieringskod som krävs. Vidare arbete med att lägga till kopplingar mellan grafiska komponenter och Javabeans går lätt - bara att välja »add interaction».

I likhet med andra »visuella» verktyg måste Visual Cafe lagra information om vilken kodsnutt som hör till vilken knapp, textfält och så vidare. (Verktygen är för dumma för att läsa godtycklig källkod och återskapa användargränssnittet direkt.) Kopplingarna lagras genom att respektive kodfragment står mellan kommentarer i källkoden. Raderas kommenterarna av misstag går det inte längre att komma åt komponenterna för grafisk redigering.

I likhet med Visual J++ kan Visual Cafe skapa rena Windowsprogram, där Java ersätter C++ och direkt anropar Windows biblioteksfunktioner. En klar prestandafördel även om det ger maskinberoende kod som får Javapuristerna att se rött.

För databaskopplingar är det meningen

att Dbanywhere ska användas. Dbanywhere är en serverkomponent - ett mellanprogram med eget programmeringsgränssnitt om man så vill - som ligger mellan Javaprogrammet och eventuella databaser. En fördel är att en applet lätt kan komma åt databaser på andra servrar än den appletprogrammet kom ifrån. Nackdelen är så klart att projektet blir låst till att använda servrar med Dbanywhere, vilket i skrivande stund innebär maskiner Windows NT på Intel. Gränssnittet mot Dbanywhere är dessutom Symantecs eget, vilket gör att det är svårt att byta ut databaskopplingen mot någon annan variant.

Så länge Dbanywhere används går det att göra en hel del av databaskommunikationen grafiskt: Till exempel översätts datatyper från SQL automatiskt till motsvarande Javatyp och tabeller kopplas till listobjekt. Men om ambitionen är att vara oberoende av Symantecs serverprogram genom att till exempel använda JDBC direkt mot databasen, får programmeraren istället snällt sitta och skriva koden för hand. Inga av de färdiga objekten fungerade tillsammans med vår JDBC-databas.

Visual J++ är Microsofts inlägg bland Javaverktygen. Tyvärr verkar det inte riktigt som språket tas på allvar, Visual J++ ger intryck av att vara gjord med motiveringen: »Titta! vi har visst ett Javaverktyg.»

Det största problemet är att gränssnittet är samma som i C++ verktygen från Microsoft. I och för sig kan det vara en fördel för C-programmerare som snabbt vill börja skriva Javakod.

Men i övrigt är det inte bra: Istället för att knappar och andra objekt direkt motsvarar en AWT-komponent, lagras gränssnittet i en Windows-resursfil. Filen översätts sedan till Javakällkod, för vidare arbete. Nackdelarna är många, främst att det inte direkt går att koppla kod till ett grafiskt objekt.

Så länge ambitionen bara är att ersätta C++ med Java för Windowsprogrammering är dock Visual J++ ett snabbt ver

Text : Ola Sigurdson