Test: Java passar perfekt för IBMs Visualage

(97-19) Visualage för Java är ett bra verktyg för att utveckla klienter för Internet och intranät. Men ett dåligt hjälpsystem gör att det tar tid att bli produktiv.

IBM fortsätter sin serie av Visualage-verktyg med en Javaversion. Naturligt nog med tanke på verktygets ursprung är Visualage främst avsett för utveckling av klient-server tillämpningar för större system.

Det går så klart också att skriva enklare Java-applets för att piffa upp websidor med. Men det finns bättre och mindre krävande verktyg för ändamålet.

För den som inte är van vid utveckling i Visualage är första intrycket överväldigande: Programmet är en kompakt massa av svårförståeliga ikoner och fönster. Men misströsta inte, efter en eller ett par dagar kommer aha-upplevelsen och man förstår hur allt hänger ihop.

Skillnaden mot många andra »Visual»-produkter är att det verkligen går att konstruera hela programmet grafiskt - inte bara användargränssnittet.

Det som gör detta möjligt är att alla klasser och metoder finns tillgängliga som ikoner. Metodanrop görs med pilar till respektive objekt, eventuellt med en extra pil som anger var parametrar ska hämtas.

Riktigt användbart blir systemet först när användaren har lagt upp ett eget klassbibliotek. En klass som till exempel hanterar Postgirotransaktioner kan då enkelt återanvändas genom att koppla olika kommunikations- och användargränssnitt till klassen.

Den grafiska konstruktionen gör det också möjligt att göra program som är mer lättförståeliga än en ren källkod. Men det kräver mycket disciplin och hård styrning från projektledaren. Det finns nämligen ingen inbyggd kontroll av att grafiken är läslig. Program måste delas upp i lämpliga bitar som får plats på en skärm. Dessutom måste varje bit ritas snyggt. I värsta fall går det att åstadkomma program som ser ut som en explosion i en spagettifabrik, vilket är klart sämre än rå okommenterad källkod.

Hur är då Java-varianten av Visualage att arbeta med?

Först av allt måste det konstateras att Java passar avsevärt bättre för utveckling med Visualage än tidigare språk som Smalltalk och C++.

I Smalltalk finns det till exempel ingen typkontroll vilket gör att det går att skriva till synes korrekta program som havererar under körning för att exempelvis ett heltal skickas som parameter istället för en sträng.

C++ är bättre på typkontroll men lider av att det inte går att exekvera koden utan en omfattande kompilering. I Java kan varje metod kompileras för sig, vilket gör att det i likhet med Smalltalk omedelbart går att se resultatet av en ändring i källkoden.

Ytterligare ett plus för Java är att Sun har standardiserat ett klassbibliotek, vilket gör att Javaprogram i princip blir allmängiltiga. I tidigare versioner av Visualage var programmerarna hänvisade till IBMs egna klassbibliotek som antingen måste länkas statiskt eller distribueras till varje klient.

Tyvärr finns ingen integration med andra Visualage-produkter. Det går alltså inte att ta ett objekt eller användargränssnitt från exempelvis Visualage Smalltalk och använda i Java-versionen.

Däremot finns det verktyg som automatiskt skapar kitt för att koppla samman C++ och Javaklasser. Vissa begränsningar finns: Till exempel kan inte objektpekare användas hur som helst.

Alla filer för ett projekt lagras i Visualages databas (repository). Det är bra eftersom det gör att verktyget automatiskt kan sköta finesser som revisionskontroll och inkrementell kompilering av metoder.

Mindre bra är att varje metod hamnar i ett separat fönster. Många programmerare hade nog föredragit att ha hela koden för till exempel en klass som löpande text. Som det är nu måste flera fönster trängas på skärmen för att ge en någorlunda överblick.

När väl programmet är klart är det bara att exportera class-filen och lägga den i rätt programkatalog i exempelvis webservern. Lika lätt är det att importera Java-kod.

Det är också lätt att testa program under utvecklingen. Så fort en ändring har gjorts - det må vara grafiskt eller i koden för en metod - är det bara att trycka på run-knappen.

Den inkrementella kompileringen gör att större den av ett program alltid är kompilerat och klart. Men minsta kompileringsenhet verkar vara det aktuella »fönstret».

Skriver man koden som text finns normalt bara en metod i fönstret, vilket går snabbt att kompilera.

Tråkigare är det i den grafiska konstruktionen: Det verkar som om all kod för det aktuella fönstret måste kompileras om även om det bara är en liten ändring. Även på en riktigt snabb dator blir det en irriterande fördröjning på några sekunder till och med för en enkel tillämpning som daytime-exemplet här bredvid.

Förutom processorkraft krävs också rejält med minne. IBM rekommenderar 64 Mbyte arbetsminne. Och visst går produkten att använda med så mycket minne, men 128 Mbyte är ett mer realistiskt minimum för ett utvecklingssystem.

Dessutom stimulerade Visualage en minnesläcka i Windows NT: Efter cirka fyra timmars arbete tar allt minne slut och systemet blir oanvändbart. Det enda som hjälper är att starta om Windows. Kanhända är problemet rättat i senaste servicepaketet från Microsoft (vi provade inte).

En brist jämfört med andra liknande verktyg är att det inte går att kompilera till Intel x86 kod. För beräkningsintensiva serverprogram, eller servrar med många klienter är detta nästan ett krav. Kod som tolkas i den virtuella javamaskinen blir nämligen snabbt för långsam. En variant är förstås att utveckla programmet i Visualage för att sedan kompilera om det med någon annan kompilator som kan skapa en direkt exekverbar fil.

Den första upptäckten en användare gör är nog att hjälpsystemet är obefintligt. Eller rättare sagt, referensmanualen ligger för sig själv som HTML och måste läsas i en webläsare. En i och för sig hyfsad sökfunktion finns genom ett seperat sökprogram som agerar miniwebserver.

Varför? suckar man. Det hela verkar vara ett misslyckat försök av IBM hänga på någon slags Internettrend. Användarna hade haft mycket större nytta av en traditionell hjälp: Klicka på en klass och definitionen kommer upp; tryck på F1 i en dialogruta och informationen om den rutan kommer fram.

Lätt inses också att Visualage inte är någon genväg till Java. För att kunna programmera krävs en gedigen förståelse av klassbiblioteken till Java. Även med grafisk programkonstruktion måste användaren helt enkelt veta vilka klasser och metoder som passar att lösa probemet med.

Den medföljande dokumentationen är som sagt en referensmanual - inte en bruksanvisning. Visserligen följer det med en hel rad exempel på tillämpningar, men en kort introduktion till klassbiblioteken och hur de används hade varit på sin plats. Som det är nu får programmeraren inhämta kunskaper i JDK 1.1

Text : Ola Sigurdson