Læs også: Her er de gode værktøjer til Java-programmering
Computerworld News Service: Eclipse er det dominerende Java-udviklingsmiljø, ligegyldig hvordan man vender og drejer det, særligt i forhold til adoption og størrelsen af dets økosystem af plugins.
Det opnåede denne position på grund af dets oprindelige udspring.
IBM besluttede at afhænde det til en separat fond, hvor Big Blue kunne finansiere dets videre udvikling, men hvor Eclipse samtidig kunne trække på støtte fra andre leverandører, som ellers sandsynligvis ville vægre sig ved at skulle bidrage til et produkt ejet af en anden leverandør.
Denne strategi har fungeret fint, delvist fordi den har været velfinansieret og på grund af en velvalgt ledelse, der har gjort et fremragende arbejde med at række ud til bidragydere, opbygge et community, styre fremdriften af underprojekter og undgå stridigheder.
Google valgte Eclipse
Det blev for nylig tydeligt, hvor vigtig Eclipses leverandøruafhængighed er, da Google offentliggjorde, at dette udviklingsmiljø er søgegigantens førstevalg til Android-udvikling.
Selvom Oracles NetBeans ellers kunne have været en kandidat til denne anbefaling, så har Oracles nylige sagsanlæg mod Google endegyldigt udelukket en sådan udvikling. Der er gået politik i markedet, og Eclipse har altid spillet sine kort rigtigt.
Eclipse-formlen mangler dog en ting: Bedre teknologi. Eclipse har længe været et middelmådigt Java-udviklingsmiljø, som mange bruger, men få virkelig elsker. Det er stødt blevet forbedret i årenes løb i kraft af årlige udgivelser, der omhyggeligt synkroniseres på tværs af mange komponenter og sendes på markedet i juni.
Den seneste udgivelse, version 3.6 med kodenavnet Helios, føjer adskillige nye funktioner til Eclipse. Dem går jeg i detaljen med om lidt.
Et specielt design
Eclipse har et design, der i flere forskellige henseender er usædvanligt. Det gør det til et udviklingsmiljø af sin helt egen art, hvilket betyder, at viden om, hvordan andre udviklingsmiljøer fungerer, ikke har megen værdi i brugen af Eclipse.
Det grundlæggende koncept i Eclipse er såkaldte perspektiver, hvilket er forskellige måder at repræsentere panelerne og layoutet i udviklingsmiljøet. Disse perspektiver kan til tider være radikalt forskellige alt afhængigt af aktiviteten.
Det er et design, der imødekommer plugin-udvikling men på bekostning af brugervenligheden, da brugeren må håndtere dramatisk forskelligartede layouts afhængig af hvilken aktivitet, der udføres.
Læs også: Her er de gode værktøjer til Java-programmering
Glem alt om "just do it"
Læs også: Her er de gode værktøjer til Java-programmering
Inden for det grundlæggende miljø til Java-udvikling dropper Eclipse alle konventioner og kræver, at brugeren tilpasser sig udviklingsmiljøets vision.
Før man kan oprette eksempelvis projekter, er man først nødt til at oprette et arbejdsrum.
Det er inden for dette arbejdsrum (et koncept uden pendant i de andre udviklingsmiljøer), man bygger projekter. Man kan også oprette arbejdssæt, hvilket er dele af arbejdsrummet, som er grupperet, som var de separate helheder.
Denne afhængighed af arbejdsrum betyder, at oprettelse eller migration af projekter kan være en langtrukken proces, som kun er dårligt understøttet af guider med usædvanlige og uforklarede valgmuligheder.
Konceptet "just do it" eksisterer ikke i Eclipse. Næsten alting kræver, at man udfylder dialogbokse eller vælger mellem valgmuligheder, der enten ikke er til at skelne fra hinanden eller som ikke giver nogen intuitiv mening.
Et eksempel
Lad os gennemgå et eksempel med et blandet Java- og Groovy-projekt, der er importeret til Eclipse uden et Groovy-plugin.
Hvis man højreklikker på Groovy-filen for at redigere den, vil en popup-menu tilbyde følgende valgmuligheder: Teksteditor, systemeditor, in-place-editor, eller standardeditor. Da der ikke medfølger nogen hjælp til denne liste, er valget baseret på rent gætværk. Og herfra går det kun nedad.
Hvis man klikker på systemeditor, forsøger Eclipse at køre scriptet frem for at lade brugeren redigere det. Kort sagt, så må Eclipse-brugere stole på deres hårdt tjente erfaringer med udviklingsmiljøets kringelkroge frem for at navigere intuitivt gennem dets funktioner.
Og for at lære disse kringelkroge at kende er man som bruger kraftigt afhængig af hjælpesystemet, som dog også er blevet væsentligt forbedret i løbet af årene, selvom det stadig har mangler.
Herudover er de falske fejlrapporter, som i tidligere versioner har været ret almindeligt forekommende, stort set blevet udryddet.
Dette udviklingsmiljø bliver afgjort bedre for hver udgivelse, men det har brug for, hvad NetBeans fik for nogle få år siden: Omarbejdning og omdesign af de grundlæggende redigeringsfunktioner.
Læs også: Her er de gode værktøjer til Java-programmering
Eclipse giver endeløse muligheder
Læs også: Her er de gode værktøjer til Java-programmering
Jeg bør her tilføje, at Eclipses design hovedsageligt er et problem på Java-området, hvor udviklingsmiljøet står overfor stærk konkurrence, der får ulemperne til at stå tydeligere frem.
På andre områder såsom C-udvikling, hvor der er færre gode udviklingsmiljøer, er Eclipse populær og i langt mindre modvind. For eksempel er Eclipse sandsynligvis det primære miljø til udvikling i C/C++ på Linux.
På trods af disse bekymringer får man, når man bruger Eclipse, en følelse af næsten uudtømmelige muligheder og enorm skalerbarhed.
Mange plugins
De tilsyneladende endeløse muligheder er i store træk et resultat af den meget lange række plugins. Dette er delvist, fordi mange plugin-udviklere understøtter Eclipse som det første.
Mange leverandører porterer faktisk aldrig deres produkter til andre platforme. Selv meget populære plugins såsom det fremragende program til opgavestyring Mylin findes ofte kun til Eclipse.
Tidligere var håndteringen af plugins i Eclipse et problem for brugerne, da et plugin ofte var afhængig af andre plugins med et helt bestemt versionsnummer.
Eclipse har dog stødt arbejdet på at løse disse problemer. Med udgivelsen i år af Eclipse MarketPlace, er det også blevet lettere at finde frem til de plugins, man har brug for.
Følg med i de kommende dage på Computerworld, hvor de fire Java-værktøjer gennemgås i detaljer.
Oversat af Thomas Bøndergaard.
