I juni 1995, da jeg første gang hørte, at Borland skulle lave et Java-værktøj, var jeg meget tilfreds. Borland var det eneste firma, der satte en bule i Visual Basic-franchisen, som Microsoft havde oprettet. Desuden betragtes Borlands Delphi-udviklingsmiljø af mange (inklusive mig selv) for at være det bedste værktøj til hurtig applikationsudvikling (RAD) på markedet. Så det var med stor spænding, at jeg købte Borland C ++ 5.0 med Java-support sent i '95.
Desværre overlod Borland-indsatsen meget at ønske. En af produktets største ulemper var, at Java-understøttelsen var et tilføjelsesmodul til C ++, snarere end at være et værktøj i sig selv. Problemet med denne tilgang er, at Java ikke var så meget lig C ++ med hensyn til dens kompileringsenheder, objektfiler og kompileringsmål. I Java kompilerer du en klassefil til et objekt, som du straks kan instantiere med andre objekter, der allerede findes på systemet. Der er ingen mål ".exe" og ".dll", som er den model, der bruges af det generiske C ++ IDE. Således var bygningsklasser besværlige, dokumentationen var næsten fraværende, og oplevelsen var helt utilfredsstillende. C ++ compileren fungerede dog godt.
På hælene på C ++ add-on-produktet kom ordet hurtigt ud om "Latte", kodenavnet for et IDE-miljø, som ingeniørerne fra Delphi-gruppen skulle arbejde på, og som blev skrevet fuldstændigt i Java. Det ambitiøse projekt blev udsat for forsinkelser; det demoerede ved den første JavaOne Developer Conference i San Francisco i 1996 og derefter igen på JavaOne '97. Endelig er den frigivet som JBuilder.
En hurtig rundvisning i JBuilder
JBuilder deler mange almindelige temaer med Delphi-verdenen og føles ens nok til Symantec Visual Cafe-værktøjerne. Så det var let for mig at komme i gang med JBuilder - selv uden at læse den medfølgende dokumentation. (Når jeg gjorde har et spørgsmål, var dokumentationen ret komplet med hensyn til at beskrive de tilgængelige muligheder.)
Miljøet består af en "kontrolbjælke", som er et flydende værktøjslinjevindue, et "gennemsøgningsvindue" med en lagdelt trækontrol til venstre og et visningsvindue til højre. Der er kun en kontrollinje, men flere browservinduer kan være åbne.
Kontrolbjælken, vist nedenfor, består af standardmenukommandoer øverst, en palet med værktøjer til venstre, der giver genveje til menupunkterne, og en samling af komponenter (JavaBeans), der er tilgængelige til brug i din visuelle applikation eller applet. Under værktøjspaletten og komponenterne er en statuslinje, der opdateres med den aktivitet, der finder sted på det aktuelle tidspunkt.
Browservinduet vises nedenfor. Dette vindue er hvor du interagerer med din kildekode, enten HTML eller Java. Over dette er kontrolbjælken, som lader dig starte handlinger (såsom en genopbygning) og opbevarer dine samlinger af JavaBeans til brug i dine egne applikationer. Yderligere kan hvert browservindue vise et projekt, der foregår i det, så hvis du arbejder på flere projekter - såsom en ny JavaBean og en applikation, der bruger det - kan du have begge projekter åbne på én gang og let skifte mellem dem . Denne mulighed imponerede mig, da den understøtter den mest almindelige form for Java-udvikling, der ændrer flere forskellige stykker på én gang. I et browservindue kan der være et projekt med hjælpeklasser, i en anden browser den applet, der bruger disse klasser, og i en tredje et sæt HTML-sider, der bruger appleten.
Browservinduet er opdelt lodret - med filtrævisningen til venstre og fremviseren til højre. Den lodrette opdeling kaldes "gardinet". Borlands brugergrænseflade giver dig mulighed for at fjerne gardinet, når du vil have en fuldskærmsvisning af den kildekode, du arbejder på. Under hver halvdel af browservinduet findes kontrolfaner, der ændrer semantikken i selve visningen.
Når du ser Java-kildekode, er fanerne i visningshalvdelen af browseren mærket kilde, design og doc.
Kildefanen viser dig blot kildekoden, og du kan redigere den ved hjælp af den medfølgende syntaksfremhævelseseditor.
Fanen design viser et visuelt arbejdsområde, hvor der findes enhver brugergrænsefladeinformation, du har defineret. Så hvis din kildekode for eksempel havde paneldefinitioner, knapper osv., Er dette panel træk-og-slip-området, hvor du kan komponere disse oplysninger.
- Fanen doc viser dig det HTML-dokument, der genereres ud fra de indlejrede kommentarer i kildekoden. HTML-dokumentet kan udvindes ved hjælp af JavaDoc, men der er ingen automatiseret måde, jeg kunne finde på at generere dette dokument.
Måske er et af de mest kloge aspekter af browserimplementeringen, at når du gennemser en klassefil, læser browseren i klassefilen og dekompilerer den nok til at vise dig kildekodens struktur. Dette kan være meget nyttigt, hvis du er vant til at læse kilde snarere end at se på et objektdiagram. Når du vælger en af Java-standardklasser eller Borland-tilpassede klasser, returnerer JavaDoc-siden for denne klasse, når du klikker på doc-fanen. Dette giver dig mulighed for at gøre ting som: fremhæve en systemklasse, vælge "gennemse det valgte symbol" og se både den rekonstruerede kilde eller dokumentationen til klassen. Jeg foretrækker denne metode, som bevarer HTML-formateringen, der er indlejret i JavaDoc-data, frem for systemer, der konverterer Java-dokumentationen til Microsoft "hjælp" -filer.
JBuilder-fejlfindingsprogrammet
Selvfølgelig er det let at skrive kode. Det får det til at arbejde hårdt. Måske er den vigtigste funktion for enhver IDE dens debugger. Heldigvis skuffer ikke Borland JBuilder-fejlfinderen. Et skærmbillede af debuggeren er vist nedenfor.
Ved fejlretning konfigureres browservinduet til at understøtte at se på din klasses status. Træstruktureret filvisning er opdelt i et øvre vindue, der indeholder trådstatus, og et nedre vindue, der indeholder oplysninger om aktive variabler. Også den venstre halvdel af browseren får nogle ekstra fanebladskontrol i bunden, der styrer fejlfindingsfunktionen.
Derudover viser pop op-vinduer en variabels værdi i kildevinduet på samme måde som Symantecs debugger fungerer. Alle standardfejlfindingsfunktioner er til stede: enkelt trin, overvågningspunkter, brudpunkter, betingede brudpunkter osv. Det bemærkelsesværdige er trådstøtten, som er fremragende. I trådvinduet i øverste venstre hjørne kan du klikke på den aktuelt udførte linje for ethvert stykke kode i en hvilken som helst tråd, og kildevinduet vises til det sted i koden. Desuden viser vinduet nederst til venstre enhver lokal og global tilstand, der er synlig for den tråd. JBuilders debugger repræsenterer bestemt den nye standard, som andre Java-debuggere måles mod.
Langs venstre side af kildevinduet angiver små prikker linjer, hvor breakpoints kan installeres. Ved at klikke på prikken fremhæves linjen, og brydepunktsymbolet vises. En anden nyttig funktion er "kør til markør" - til de tidspunkter, hvor du ikke ønsker at gå et trin gennem hver iteration af en til løkke. Klik blot på linjen, vælg "kør til markør", og udførelsen stopper lige der.
Håndtering af output
Et sidste område, hvor jeg fandt JBuilder særlig nyttig, var dens håndtering af output fra udførelse af en Java-applikation. Udførelsesloggen er et vindue, der indeholder alle de data, der sendes til System.out fra det aktuelle løb. Men når flere projekter er åbne, opretholder eksekveringsloggen separate faner for hvert projekt! Et eksempel på dette er vist nedenfor.
Som du kan se på billedet er der to faner, en til "eksempel" og en til "BASIC", det aktuelle projekt. Denne adskillelse er vigtig, når du opbygger flere klassebiblioteker på samme tid, fordi det forhindrer dig i at blande output fra de to projekter.
Hvad jeg kan lide ved JBuilder
Nogle gange er det de små ting. jeg virkelig sådan kan man udskrive Java-kildekode til en farveprinter og få den til at komme ud med dens skrifttyper og syntaks fremhævning intakt. Hvis jeg kunne tilpasse sidehoveder og sidefødder og angive en "to-op" -output (to sider med kildekode udskrevet side om side på en liggende outputside), ville det være perfekt.
Support til Java 1.1 er meget flot. Mens JDK 1.1 har været ude i et stykke tid, og Symantec har haft beta-understøttelse til 1.1, er der intet som at have en IDE, der er designet fra bunden til at arbejde med 1.1.
Som jeg sagde tidligere, er fejlfinderen også meget flot: Den giver en stor mængde information på en letforståelig måde. Meget af debugging er "peg-og-skyde" -stil, som nogle brugere kan lide (jeg gør) og andre ikke (i tro på at "gdb" står for Guds DeBugger). Jeg tror, det er tilstrækkeligt at finde selv de sværeste trådlåsebugs.
Hvad jeg ikke kan lide ved JBuilder
JBuilders konfigurerbare IDE kan faktisk ikke konfigureres på to vigtige måder:
For det første kan du ikke indstille standard baggrunds- og forgrundsfarver på skærmen. I stedet skal du først indstille dem til hele dit skrivebord, og så vil JBuilder bemærke ændringerne. Du kan dog indstille dem ved hjælp af nogle af deres "dåse" farveskemaer.
- Den anden alvorlige fejl er, at du ikke kan tilpasse redaktørens tastetryk. Mine to foretrukne redaktører i denne henseende er EMACS og programmørens fileditor (PFE). JBuilders editor-tilpasningsfane består i at være i stand til at vælge nogle færdigpakkede nøgletilknytninger - standard, Kort, Klassisk og Epsilon er inkluderet - og at være i stand til at vælge, hvordan ting som automatisk indrykning, fremhævning og wrap-around fungerer. Jeg leder stadig efter redaktøren, der lader dig definere makropakker i Java.
I præsentationsområdet lider JBuilder af nogle enkle fejl, som jeg forventer vil blive rettet i den første patchudgivelse eller deromkring. For eksempel, hvis dit skrivebord har "Store skrifttyper" valgt (som Microsoft insisterer betyder at tage Arial 10 og "multiplicere" det med en eller anden faktor), bryder beregningen af, hvor meget plads der er brug for i værktøjslinjen, og komponentbiblioteksikonerne klipper af. Hvis du derimod indstiller skrifttypens udseende eksplicit i afsnittet "Udseende" på dine skrivebordsegenskaber, såsom 14-punkts Arial, gengives komponentbjælken korrekt. Det er klart, at det er en Microsoft-bogositet (hvor en 10pt-skrifttype ikke altid gengives som en 10pt-font), men folk på Borland har brug for at håndtere det.
Et andet område, som jeg ikke kan lide ved alle IDE'er til Java, er afhængigheden af deres egen "brugerdefinerede" Java virtuelle maskine til udvikling. Jeg håber, at IDE'erne i fremtiden kan bruges med standard Java Runtime Environment (JRE) og et par brugerdefinerede biblioteker. Ingen har gjort denne rigtige endnu.
Hvad jeg ønsker det havde
Naturligvis passer intet produkt perfekt til alle, så det, jeg gerne vil se, kan betragtes som støj fra andre mennesker. Men i ånden til at tale ud er dette de tre øverste ting, jeg gerne vil se i JBuilder (eller enhver solid IDE for den sags skyld):
Finer IDE-konfigurationskontrol - nøgletilknytninger, skærmfarver og layout
Profileringsstøtte i debuggeren - opkaldssporing / timing, brug af bunker, affaldskort osv
- Kildekodekontrol - dette er et område, hvor Java er svag (versionskontrol), og et smart kontrolsystem, der bemærkede, da kontrakten blev ændret (inkompatibel klasseændring), og hvad der ændrede sig, ville være en reel godbid
Afslutter
JBuilder-værktøjet er en meget dygtig adgang til det stadig mere overfyldte IDE-marked. Det leverer ekstraordinær kapacitet nogle steder - såsom JavaBeans, fejlretning, flere projekter og design af brugergrænseflader. Denne udgivelse af JBuilder har nogle uslebne kanter omkring præsentationen og konfigurerbarheden af IDE, men det kan forventes i en 1.0-udgivelse. Dens understøttelse af Java 1.1 er også overlegen. Min opfattelse er, at fyre og gals på Symantec for første gang har en seriøs konkurrence med deres Visual Cafe Pro-produkt.
Chuck McManis er i øjeblikket direktør for systemsoftware hos FreeGate Corp., en venturefinansieret start-up, der udforsker muligheder på internetmarkedet. Før han kom til FreeGate, var Chuck medlem af Java Group. Han sluttede sig til Java-gruppen lige efter dannelsen af FirstPerson Inc. og var medlem af den bærbare OS-gruppe (den gruppe, der er ansvarlig for OS-delen af Java). Senere, da FirstPerson blev opløst, blev han hos gruppen gennem udviklingen af alfa- og betaversionerne af Java-platformen. Han oprettede den første "hele Java" -side på Internettet, da han programmerede Java-versionen af Sun-hjemmesiden i maj 1995. Han udviklede også et kryptografisk bibliotek til Java og versioner af Java-klasselæsseren, der kunne screene klasser. baseret på digitale signaturer. Før han kom til FirstPerson, arbejdede Chuck i SunSoft-operativsystemområdet og udviklede netværksapplikationer, hvor han lavede det oprindelige design af NIS +. Tjek hans startside.
