I juni 1995, da jeg første gang hørte at Borland skulle lage et Java-verktøy, var jeg ganske fornøyd. Borland var det eneste selskapet som satte en stopper i Visual Basic-serien som Microsoft hadde opprettet. Videre anses Borlands utviklingsmiljø i Delphi av mange (inkludert meg selv) som det beste verktøyet for rask applikasjonsutvikling (RAD) på markedet. Så det var med stor spenning at jeg kjøpte Borland C ++ 5.0 med Java-støtte sent i '95.
Dessverre overlot Borland-innsatsen mye å være ønsket. En av produktets største ulemper var at Java-støtten var en tilleggsmodul til C ++, i stedet for å være et verktøy i seg selv. Problemet med denne tilnærmingen er at Java ikke var så mye som C ++ når det gjelder kompileringsenheter, objektfiler og kompileringsmål. I Java kompilerer du en klassefil til et objekt som du umiddelbart kan starte med andre objekter som allerede er på systemet. Det er ingen ".exe" og ".dll" mål, som er modellen som brukes av den generiske C ++ IDE. Dermed var bygningsklasser tungvint, dokumentasjonen var nesten fraværende, og opplevelsen var fullstendig utilfredsstillende. C ++ - kompilatoren fungerte bra.
På hælene til C ++ -tilleggsproduktet kom ord raskt ut om "Latte", kodenavnet for et IDE-miljø som ingeniørene fra Delphi-gruppen skulle jobbe med, og som ble skrevet helt i Java. Det ambisiøse prosjektet ble utsatt for forsinkelser; den demoer på den første JavaOne Developer Conference i San Francisco i 1996 og deretter igjen på JavaOne '97. Endelig har den blitt utgitt som JBuilder.
En rask omvisning på JBuilder
JBuilder deler mange vanlige temaer med Delphi-verdenen og føles lik nok Symantec Visual Cafe-verktøyene. Så det var lett for meg å komme i gang med JBuilder - selv uten å lese den medfølgende dokumentasjonen. (Når jeg gjorde har et spørsmål, dokumentasjonen var ganske fullstendig med hensyn til å beskrive de tilgjengelige alternativene.)
Miljøet består av en "kontrollpanel", som er et flytende verktøylinjevindu, et "surfevindu" med en lagdelt trekontroll til venstre og et visningsvindu til høyre. Det er bare en kontrollinje, men flere nettleservinduer kan være åpne.
Kontrolllinjen, vist nedenfor, består av standard menykommandoer øverst, en palett med verktøy til venstre som gir snarveier til menyelementene, og en samling komponenter (JavaBeans) som er tilgjengelige for bruk i det visuelle programmet eller applet. Under verktøypaletten og komponentene er en statuslinje som oppdateres med hvilken aktivitet som foregår på det nåværende tidspunktet.
Nettleservinduet vises nedenfor. Dette vinduet er der du samhandler med kildekoden, enten HTML eller Java. Over dette er kontrollpanelet, som lar deg starte handlinger (for eksempel en ombygging) og holder samlingene dine av JavaBeans til bruk i dine egne applikasjoner. Videre kan hvert nettleservindu vise et prosjekt som foregår i det, så hvis du jobber med flere prosjekter - for eksempel en ny JavaBean og et program som bruker det - kan du ha begge prosjektene åpne samtidig og enkelt flytte mellom dem . Denne muligheten imponerte meg da den støtter den vanligste formen for Java-utvikling, og endrer flere forskjellige brikker samtidig. I et nettleservindu kan det være et prosjekt med verktøyklasser, i en annen nettleser appleten som bruker disse klassene, og i en tredje et sett med HTML-sider som bruker appleten.
Nettleservinduet er delt vertikalt - med filtreet til venstre og betrakteren til høyre. Den vertikale splittelsen kalles "gardinen". Borlands brukergrensesnitt lar deg fjerne gardinen når du vil ha fullskjermvisning av kildekoden du jobber med. Under hver halvdel av nettleservinduet er det kontrollfaner som endrer semantikken i selve visningen.
Når du ser på Java-kildekode, er kategoriene på visningshalvdelen av nettleseren merket kilde, design og dokument.
Kildefanen viser deg bare kildekoden, og du kan redigere den ved hjelp av den medfølgende redigeringsprogrammet for syntaksutheving.
Fanen design viser et visuelt arbeidsområde der det finnes informasjon om brukergrensesnittet du har definert. Så for eksempel, hvis kildekoden din hadde paneldefinisjoner, knapper og så videre, er dette panelet dra-og-slipp-området der du kan komponere den informasjonen.
- Dokumentfanen viser deg HTML-dokumentet som genereres fra de nestede kommentarene i kildekoden. HTML-dokumentet kan trekkes ut ved hjelp av JavaDoc, men det er ingen automatisert måte jeg kunne finne på å generere dette dokumentet.
Kanskje en av de mest smarte aspektene ved nettleserimplementeringen er at når du blar gjennom en klassefil, leser nettleseren i klassefilen og dekompilerer den nok til å vise strukturen til kildekoden. Dette kan være veldig nyttig hvis du er vant til å lese kilde, i stedet for å se på et objektdiagram. Videre, når du velger noen av Java-standardklassene eller Borland-tilpassede klasser, vil du klikke på doc-fanen for å returnere JavaDoc-siden for den klassen. Dette lar deg gjøre ting som: fremheve en systemklasse, velge "bla gjennom valgt symbol", og se både den rekonstruerte kilden eller dokumentasjonen for klassen. Jeg foretrekker denne metoden, som bevarer HTML-formateringen som er innebygd i JavaDoc-dataene, framfor systemer som konverterer Java-dokumentasjonen til Microsoft "hjelp" -filer.
JBuilder-feilsøkingsprogrammet
Selvfølgelig er det enkelt å skrive kode. Det får det til å fungere som er vanskelig. Kanskje den viktigste funksjonen for enhver IDE er feilsøkingsprogrammet. Heldigvis skuffer ikke Borland JBuilder-feilsøkingsprogrammet. Et skjermbilde av feilsøkingsprogrammet er vist nedenfor.
Når du feilsøker, blir nettleservinduet konfigurert på nytt for å se på klassens status. Trestrukturerte filvisningen er delt inn i et øvre vindu som inneholder trådstatus og et nedre vindu som inneholder informasjon om aktive variabler. Den venstre halvdelen av nettleseren får også noen ekstra fanekontroller nederst som styrer feilsøkingsdriften.
I tillegg vil popup-vinduer vise verdien til en variabel i kildevinduet på omtrent samme måte som Symantecs feilsøkingsprogram fungerer. Alle standard feilsøkingsfunksjoner er til stede: enkelt trinn, overvåkningspunkter, bruddpunkter, betingede bruddpunkter, og så videre. Merket er trådstøtten, som er enestående. I trådvinduet i øvre venstre hjørne kan du klikke på den nåværende kjørende linjen til en hvilken som helst kode i en hvilken som helst tråd, og kildevinduet vil komme til det stedet i koden. Videre vil vinduet nederst til venstre vise enhver lokal og global tilstand som er synlig for den tråden. JBuilders feilsøkingsprogram representerer definitivt den nye standarden som andre Java-feilsøkere vil bli målt mot.
Langs venstre side av kildevinduet indikerer små prikker linjer der brytepunkter kan installeres. Ved å klikke på prikken fremheves linjen, og brytpunktsymbolet vises. En annen nyttig funksjon er "løp til markør" - for de gangene du ikke vil gå ett trinn gjennom hver iterasjon av en til Løkke. Bare klikk på linjen, velg "løp til markør", og utførelsen stopper akkurat der.
Håndtering av utdata
Et siste område der jeg syntes JBuilder var spesielt nyttig, var håndteringen av utdataene fra å utføre et Java-program. Utførelsesloggen er et vindu som inneholder alle dataene som sendes til System.out fra den nåværende løpeturen. Når flere prosjekter er åpne, opprettholder imidlertid utførelsesloggen separate faner for hvert prosjekt! Et eksempel på dette er vist nedenfor.
Som du kan se på bildet er det to faner, en for "eksempel" og en for "BASIC", det nåværende prosjektet. Denne separasjonen er viktig når du bygger flere klassebiblioteker samtidig, fordi det hindrer deg i å blande utdataene fra de to prosjektene.
Hva jeg liker med JBuilder
Noen ganger er det de små tingene. Jeg egentlig slik at man kan skrive ut Java kildekode til en fargeskriver og få den til å komme ut med skrifttyper og syntaks utheving intakt. Hvis jeg kunne tilpasse sidehode og bunntekst og spesifisere en "to-opp" -utgang (to sider med kildekode skrevet ut side om side på en liggende utdata-side), ville det være perfekt.
Støtten for Java 1.1 er veldig fin. Mens JDK 1.1 har vært ute en stund, og Symantec har hatt beta-støtte for 1.1, er det ingenting som å ha en IDE som er designet fra grunnen av for å fungere med 1.1.
Som jeg sa tidligere, er feilsøkingsprogrammet veldig hyggelig også: Det gir en stor mengde informasjon på en lettfattelig måte. Mye av feilsøkingen er "pek-og-skyt" -stil, som noen brukere liker (jeg gjør) og andre ikke (tror at "gdb" står for Guds DeBugger). Jeg tror det er tilstrekkelig å finne selv de vanskeligste trådlåsingsfeilene.
Det jeg ikke liker med JBuilder
JBuilders konfigurerbare IDE kan faktisk ikke konfigureres på to viktige måter:
For det første kan du ikke angi standard bakgrunns- og forgrunnsfarger i skjermen. I stedet må du først sette dem for hele skrivebordet ditt, og JBuilder vil merke endringene. Du kan imidlertid angi dem ved å bruke noen av deres "hermetiske" fargevalg.
- Den andre alvorlige feilen er at du ikke kan tilpasse redaktørens tastetrykk. Mine to favorittredaktører i denne forbindelse er EMACS og programmererens filredigerer (PFE). JBuilders redigeringsfane for redigering består av å kunne velge noen forhåndspakkede nøkkeltilordninger - standard, kort, klassisk og Epsilon er inkludert - og å kunne velge hvordan ting som automatisk innrykk, utheving og omslag fungerer. Jeg ser fremdeles etter redaktøren som lar deg definere makropakker i Java.
I presentasjonsområdet lider JBuilder av noen enkle feil som jeg forventer vil bli løst i den første oppdateringen eller så. For eksempel, hvis skrivebordet ditt har valgt "Store skrifttyper" (som Microsoft insisterer betyr å ta Arial 10 og "multiplisere" det med en eller annen faktor), brytes beregningen av hvor mye plass som trengs av verktøylinjen, og komponentbibliotekets ikoner blir kuttet av. Hvis du derimot angir skriftens utseende eksplisitt i "Utseende" -delen av skrivebordsegenskapene dine, for eksempel 14-punkts Arial, blir komponentlinjen gjengitt riktig. Det er tydelig at det er en Microsoft-bogositet (hvor en 10pt-skrift ikke alltid gjengis som en 10pt-font), men folkene i Borland trenger å håndtere det.
Et annet område som jeg ikke liker om alle IDEer for Java, er avhengigheten av deres egen "tilpassede" Java virtuelle maskin for utvikling. Jeg håper at IDEene i fremtiden vil være brukbare med standard Java Runtime Environment (JRE) og noen få tilpassede biblioteker. Ingen har gjort denne riktig ennå.
Det jeg skulle ønske det hadde
Selvfølgelig er det ikke noe produkt som passer perfekt for alle, så det jeg vil se kan betraktes som støy fra andre mennesker. Men i ånden for å si fra, er dette de tre beste tingene jeg ønsker å se i JBuilder (eller en hvilken som helst solid IDE for den saks skyld):
Finere IDE-konfigurasjonskontroll - nøkkelkartlegginger, skjermfarger og layout
Profileringsstøtte i feilsøkingsprogrammet - anropssporing / timing, haugbruk, søppelkart og så videre
- Kildekodekontroll - dette er et område der Java er svak (versjonskontroll), og et smart kontrollsystem som noterte seg når kontrakten endret seg (inkompatibel klasseendring) og hva som endret seg, ville være en skikkelig godbit
Innpakning
JBuilder-verktøyet er en veldig dyktig inngang til det stadig mer overfylte IDE-markedet. Det gir ekstraordinær evne noen steder - for eksempel JavaBeans, feilsøking, flere prosjekter og brukergrensesnittdesign. Denne utgivelsen av JBuilder har noen grove kanter rundt presentasjonen og konfigurerbarheten til IDE, men dette er å forvente i en 1.0-utgivelse. Støtten til Java 1.1 er også overlegen. Min oppfatning er at for første gang har gutta og jentene på Symantec noen alvorlig konkurranse med Visual Cafe Pro-produktet.
Chuck McManis er for tiden direktør for systemprogramvare i FreeGate Corp., en venturefinansiert oppstart som utforsker muligheter på internettmarkedet. Før han begynte i FreeGate, var Chuck medlem av Java Group. Han ble med i Java-gruppen like etter dannelsen av FirstPerson Inc. og var medlem av den bærbare OS-gruppen (gruppen som er ansvarlig for OS-delen av Java). Senere, da FirstPerson ble oppløst, ble han hos gruppen gjennom utviklingen av alfa- og betaversjonene av Java-plattformen. Han opprettet den første "hele Java" -siden på Internett da han programmerte Java-versjonen av Sun-hjemmesiden i mai 1995. Han utviklet også et kryptografisk bibliotek for Java og versjoner av Java-klasselaster som kunne skjerme klasser. basert på digitale signaturer. Før han begynte på FirstPerson, jobbet Chuck i operativsystemområdet til SunSoft og utviklet nettverksapplikasjoner, der han gjorde den første designen av NIS +. Sjekk ut hjemmesiden hans.
