Kapitel 12 100% pure Java

Java er designet med det formål at være platformsuafhængigt. Alligevel indeholder sproget masser af muligheder for at bryde denne uafhængighed. For eksempel kan man bruge JNI, der kalder programmer, som er kompileret til maskinkode.

For at man kan adskille de programmer, der virkeligt er platformsuafhængige, fra de andre, har Sun indført begrebet 100% Pure Java. Programmer, der bærer dette logo, er fuldstændigt portable.

Du læser en gammel bog
Den bog, du læser her, er fra 1998, og mange ting kan have ændret sig siden da.
Vi håber, at du stadig kan finde relevant information i den.
Hvis du vil læse aktuelle oplysninger om de avancerede dele af Java, anbefaler vi
bogen Core Java – Advanced Features

Det er imidlertid ikke nok at love Sun, at ens program er platformsuafhængigt. Man skal igennem en længere certificeringsproces. I dette kapitel vil denne proces blive beskrevet, ligesom forskellige punkter, der kræver særlig opmærksomhed, vil blive gennemgået.

 

Certificeringsprocessen

 

Certificeringsprocessen består overordnet af to faser:

 

  • Undersøgelsesfasen, der foretages af udvikleren.
  • Kontrolfasen, der udføres af et uafhængigt certificeringscenter.

 

I undersøgelsesfasen gennemgår udvikleren en række tests for at se, om programmet opfylder kravene til 100% Pure Java. Er der punkter i programmet, som kan tyde på overtrædelse af bestemmelserne for 100% Pure Java, skal udvikleren enten ændre disse punkter eller dokumentere, at de ikke giver problemer.

 

Herefter skal programmet samt dokumentationen sendes til det uafhængige certificeringscenter. Her kan man – som dansker – enten vælge det amerikanske KeyLabs eller det hollandske Telefication. Der findes også certificeringscentre i Japan og Kina.

 

Prisen for en certificering er cirka 1.000 dollars, hvad enten produktet bliver godkendt eller ej.

 

Undersøgelsesfasen

 

I undersøgelsesfasen er der fem opgaver, der skal udføres:

 

  1. Registrer ved et registreringscenter.
  2. Installer undersøgelsespakken.
  3. Foretag en statisk kontrol af programmet.
  4. Foretag en dynamisk kontrol af programmet.
  5. Forbered produktet til afsendelse.
  6. Send produktet til certificeringscentret.

 

 

Man kan registrere på certificeringscentrenes hjemmeside. Her skal man udover navn og adresse angive hvilken type produkt, man ønsker at få certificeret. Man kan vælge mellem en applet, en applikation, en applikation med grafisk brugergrænsflade, en klassesamling eller en JavaBean. Man skal også angive hvilken kategori, der bedst beskriver produktet. Man kan vælge mellem følgende kategorier:

 

  • Regnskab
  • Handel
  • Kommunikation
  • Grafik
  • Database
  • Undervisning
  • Underholdning
  • Økonomi
  • Internet
  • Multimedie
  • Netværk
  • PDA-software
  • Kalender mv.
  • Programmeringsværktøjer
  • Systemsoftware
  • Tekstbehandling og regneark
  • Andet.

Når alle oplysninger er indtastet, kan prisen regnes ud. Ved Telefication koster certificering af et spil med en grafisk brugergrænseflade 2.585 gylden svarende til cirka 8.700 danske kroner. Når registreringen er indsendt og betalingen registreret, vil man modtage et brugernavn og et kodeord, der gør det muligt at hente undersøgelsespakken.

Når man har hentet undersøgelsespakken, kan man installere den. Inkluderet i pakken er en række eksempler, der viser, hvordan man sætter systemet op til certificering. For at programmerne i undersøgelsespakken kan afvikles, skal man have JDK 1.1 installeret. Man behøver dog ikke kompilere sin egen applikation med JDK 1.1.

Den statiske kontrol af ens applikation sker ved hjælp af programmet Java Pure Check (JPC). Dette program findes i en grafisk version og i en version, der kan afvikles fra kommandolinien. Inden JPS startes, skal man dog lægge den jar-fil, der indeholder JPC, i sin class-path. Den grafiske version startes med kommandoen

Java JavaPureCheck

Herefter vises et skærmbillede som det i figur 12.1. Her kan man vælge hvilke filer, der skal kontrolleres. Man kan også angive, hvilken JDK-version, programmet skal testes under, ligesom man kan angive hvilken fil, resultatet skal gemmes i.

Fig. 12.1 – Java Pure Check.

 

 

 

 

 

 

 

 

 

 

 

 

 

I dette eksempel er det programmet ArrayPrint fra Java Native Interface-kapitlet, der bliver testet. Dette program indeholder naturligvis kald af native metoder og er derfor ikke 100% Pure. Som en naturlig følge, finder JPC fejl i programmet. Disse rapporteres – som det ses i figur 12.2 – i et skærmbillede, hvor man nederst har mulighed for at begrunde fejlen. Denne begrundelse vil automatisk blive indsat i rapportfilen, der skal sendes til certificeringscentret.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Når Java Pure Check finder en fejl, har man mulighed for at forklare den.

 

Bruger man derimod programmet fra kommandolinien, skal man lære følgende syntaks.

 

Java JavaPureCheck [-d version] [-h] [-o output] input …

 

Parametren –d angiver, hvilken version af JDK der anvendes. Dette kan enten være JDK102 eller JDK11. Hvis man angiver –h, vil man få resultatet som HTML-dokumenter. –o kan bruges til at angive et andet filnavn til rapporten end den vanlige results.jpc og results.ser.

 

 

Som input til programmet kan gives en blanding af klassefiler, jar-filer og biblioteker. Disse filer behøver ikke være inkluderet i class-path, da programmet aldrig bliver udført – JPC læser dem blot som datafiler.

 

Når JPC bruges fra kommandolinien, har man ikke mulighed for at indtaste forklaringer på de forskellige fejl og advarsler. I stedet må man redigere rapportfilen og indtaste dem manuelt, før rapporten sendes til certificeringscentret. Rapportfilen kan se således ud:

 

###################### JavaPureCheck Report ##########################

#

#      Generated on          : 1. august 1998 16:51:20 GMT+02:00

#      System Model Version  : jdk11

#      JavaPureCheck Version : 3.15

#      Rule Base Version     : 1.92

#

#      Summary:

#

#      PURE: 0        WARNING: 0            ERROR: 1

#

#      Final Result   :  ERROR

#

######################################################################

 

Class: ArrayPrint

Error: method reference: java.lang.System.loadLibrary(java.lang.String)

Note: Requires explanation; see Variance number 5

Explanation:          <Explanation required>

Error: native method: ArrayPrint.print(int[])

Note: Defines a native method

Explanation:          <Explanation required>

Status: ERROR

 

Final Result   :  ERROR

 

 

 

 

Udvikleren er ansvarlig for at forklare alle fejl og advarsler, der opstår under afviklingen af JPC. Det gælder også, selvom problemerne findes i klasser, der er leveret af tredjepart.

 

Senere i kapitlet vil de forskellige fejl og advarsler blive gennemgået, ligesom mulige forklaringer på problemet vil blive foreslået.

 

Det næste skridt i undersøgelsesfasen er den dynamiske kontrol af programmet. Denne kontrol foretages ved hjælp af testscripts. Formålet med afviklingen af testscriptene er at vise, at programmet ikke er afhængig af implementeringen af en specifik Java VM i et operativsystem eller browser. Programmet skal afvikles på mindst tre forskellige platforme, før det kan indsendes.

 

Hvilke platforme, der godkendes, er op til certificeringscentrene. Nedenstående tabel viser hvilke platforme, der efteråret 1998 anvendes til certificering af applikationer, klassesamlinger og JavaBeans.

 

 

 

Operativsystem Udvikler af Java VM JDK-version
Win95/NT Sun Microsystems 1.0 og 1.1
Solaris Sun Microsystems 1.0 og 1.1
MacOS Apple Computer 1.0 og 1.1
OS/2 Warp IBM 1.0 og 1.1
AIX IBM 1.0 og 1.1
Network Station IBM 1.0 og 1.1
HP UX Hewlett Packard 1.0 og 1.1
JavaStation Sun Microsystems 1.1

 

Hvis man ønsker at få en applet certificeret, er reglerne lidt anderledes. Appletten skal afvikles på tre forskellige operativsystemer, og minimum to forskellige browsere skal anvendes. Nedenstående tabel viser, hvilke browsere og operativsystemer, der kan anvendes.

 

Browser Operativsystem Udvikler JDK-version
Navigator 3.x Win95/NT Netscape 1.0
Navigator 3.x Solaris Netscape 1.0
Navigator 3.x MacOS Netscape 1.0
Navigator 3.x OS/2 Warp Netscape 1.0
Navigator 3.x AIX Netscape 1.0
Navigator 3.x HP UX Netscape 1.0
Internet Explorer 3.x Win95/NT Microsoft 1.0
Internet Explorer 3.x MacOS Microsoft 1.0
Internet Explorer 3.x MaxOS (IE for MRJ 1) Apple Computer 1.0
HotJava Browser 1.1 Win95/NT Sun Microsystems 1.1
HotJava Browser 1.1 Solaris Sun Microsystems 1.1
HotJava Views 1.0 JavaStation Sun Microsystems 1.1
Internet Explorer 3.x MacOS (IE for MRJ 2) Apple Computer 1.1
Internet Explorer 4.x MaxOS (IE for MRJ 2) Apple Computer 1.1
Internet Explorer 4.x Win 95/NT Microsoft 1.1
Navigator 4.x Win95/NT Netscape 1.1

 

 

Navigator 4.x Solaris Netscape 1.1
Navigator 4.x MacOS Netscape 1.1
Navigator 4.x OS/2 Warp Netscape 1.1
Navigator 4.x AIX Netscape 1.1
Navigator 4.x HP UX Netscape 1.1

 

De punkter, der skal omfattes af testscriptet, er de centrale punkter i programmet. Disse skal således identificeres og placeres på en funktionsliste – feature list. Når funktionslisten er skrevet, skal der skrives et testscript, der udfører punkterne på funktionslisten.

 

Testscriptet kan enten være en liste over ting, der skal udføres manuelt af den person, som tester programmet, eller et program, der tester applikationens funktioner. Hvis man skriver et automatisk program, skal dette naturligvis være platformsuahængigt. Det anbefales i øvrigt, at testprogrammer skrives i Java.

 

Hver platform, man tester sit produkt på, skal nævnes i opførselsrapporten. Denne rapport beskriver, hvordan applikationen opfører sig på de forskellige platforme. Det er især vigtigt at beskrive punkter, hvor applikationen opfører sig forskelligt på forskellige platforme, og forklare, hvorfor dette ikke skal opfattes som et problem i forhold til certificeringen. Hvis man under sin test finder en fejl i den Java VM, man tester på, skal man sende en fejlrapport til udvikleren af den pågældende Java VM. Kopier af disse fejlrapporter skal inkluderes i opførselsrapporten.

 

Når alle udviklerens test er gennemført succesfuldt, skal der oprettes en kontrolpakke, indeholdende produktet og resultatet af de forskellige test, samt en instruktion i, hvordan produktet skal benyttes.

 

Denne instruktion skal skrives i en fil ved navn howto.txt. Denne fil skal indeholde følgende fire sektioner:

 

  1. Setup
    I setup-sektionen anføres produktets krav til hardware og software. Endvidere angives, hvilken Java-version, der skal testes under.
  2. Install
    I installationssektionen beskrives de opgaver, der skal udføres for at installere produktet. Hvis der er forskellige fremgangsmåder for forskellige platforme, skal dette også anføres. Man skal også angive det nøjagtige indhold af variablerne path og classpath.
  3. Install Check
    I installationskontrolsektionen skrives en måde, hvorpå testeren kan afgøre om produktet er korrekt installeret.
  4. Product Documentation
    Denne sektion angiver placeringen af al dokumentation vedrørende produktet. Dette kan være inkluderet i den pakke, der sendes til certificeringscentret, i elektronisk eller trykt form, eller det kan gøres tilgængeligt på Internet.

 

Pakken er nu klar til afsendelse. Det sker ved at informere certificeringscentret om, at man er klar til at indsende sit produkt til kontrol. Herefter kan man sende pakken til certificeringscentret – det gøres fra centrets hjemmeside.

 

Kontrolfasen

 

Når produktet er indsendt til certificeringscentret, begynder kontrolfasen. Fra certificeringscentrets hjemmeside vil det – ved hjælp af brugernavn og kodeord – være muligt at følge produktets forløb gennem kontrolfasen. Normalt vil et program komme gennem kontrolfasen på fem hverdage.

 

I kontrolfasen gennemgår produktet følgende punkter:

 

  • Undersøgelse af kontrolpakken
  • Statisk kontrol af produktet
  • Dynamisk kontrol af produktet
  • Afgørelse af, om produktet dumper eller består.

 

Så snart certificeringscentret modtager kontrolpakken, bliver den undersøgt. Hvis den ikke indeholder de elementer, der er beskrevet i forrige afsnit, vil udvikleren blive informeret via e-mail. Er der mangler i pakken, skal den genindsendes. Normalt koster det ikke ekstra at genindsende en pakke. Man skal dog være opmærksom på, at kontrollen ikke vil begynde, før en komplet pakke er modtaget.

 

Certificeringscentret vil udføre den statiske kontrol ved hjælp af Java Pure Check-programmet. Herefter kontrolleres det, at alle fejl og advarsler, der opstår, er begrundet af udviklerne.

 

Når den statiske kontrol er gennemført, vil programmet blive testet på flere forskellige platforme i henhold til testscriptene. Det er ikke usædvanligt, at certificeringscentret har spørgsmål om scriptet eller installationen af produktet – disse spørgsmål vil blive stillet via e-mail.

Certificeringscentret afsætter otte timer til at gennemgå den dynamiske kontrol. Hvis det ikke er muligt at gennemgå kontrollen indenfor det afsatte tidsrum på grund af fejl og mangler, der skal udbedres, stoppes certificeringsprocessen, og udvikleren kontaktes for at aftale ny betaling.

Hvis testscriptet ikke kan gennemføres, vil programmet ikke blive certificeret, før problemet er løst. Problemer med at fuldføre afviklingen af et testscript kan opdeles i tre kategorier:

  • En fejl i programmet
    Hvis der er en fejl i programmet, skal denne udbedres, og programmet skal genindsendes.
  • En fejl i Java-platformen
    Hvis problemet skyldes en fejl i den underliggende Java-platform, skal der indsendes en nøjagtig fejlbeskrivelse til udvikleren af den pågældende Java-platform. En kopi sendes til certificeringsinstituttet.
  • En fejl et uafklaret sted
    Hvis det ikke kan afgøres, om en fejl ligger i programmet eller Java-platformen, vil den blive behandlet som en fejl i Java-platformen. Det vil sige, at man skal indsende en fejlrapport til platformsudvikleren.

 

 

Når programmet har gennemgået den statiske og dynamiske kontrol, vil udvikleren modtage en godkendelsesrapport. Sun vil blive informeret om, at produktet er blevet certificeret, og man vil modtage sin 100% Pure Java licens. Af denne fremgår det, hvordan man må benytte 100% Pure Java-logoet.

 

Udvikling af et 100% Pure Java-produkt

 

Indtil videre har dette kapitel koncentreret sig om, hvordan man kontrollerer, om ens produkt lever op til de krav, der stilles til et 100% Pure Java-produkt. Det er imidlertid lettere at lave programmet rigtigt første gang i stedet for at skulle implementere ændringerne, efterhånden som fejlene opdages. Derfor vil resten af kapitlet koncentrere sig om, hvilke råd og retningslinier man bør følge, når man udvikler et 100% Pure Java-program.

Formålet med 100% Pure Java er at certificere programmer, der er platformsuafhængige (portable). Mange vil definere et program som platformsuafhængigt, hvis det producerer det samme resultat på alle platforme. Som nedenstående klasse viser, er denne definition ikke helt korrekt.

 

public class VisOS

{

public static final void main (String args[])

{

try

{

System.out.println (System.getProperty (“os.name”));

}

catch (RuntimeException re)

{

re.printStackTrace();

System.exit(1);

}

}

 

}

 

De fleste vil nok kunne enes om, at dette program er platformsuafhængigt, selvom det giver et forskelligt resultat på forskellige platforme. Nedenstående program minder særdeles meget om klassen VisOS, men som det ses, vil dette program ikke afvikles på alle platforme.

public class CheckOS

{

public static final void main (String args[])

{

try

{

String os = System.getProperty(“os.name”);

if (os.equals (“Windows 95”))

{

throw new RuntimeException();

}

}

 

 

catch (RuntimeException re)

{

re.printStackTrace();

System.exit(1);

}

}

}

 

Forskellen på de to programmer er ikke den måde, de bruger Java-platformen på. Det er den funktionalitet, de implementerer.

 

Selvom mange mener, at pure og portabelt er det samme, er det ikke tilfældet. Hvor man ikke uden videre kan se, om et program er portabelt, kan man kontrollere om det er pure. Programmer, der er pure, er sandsynligvis også portable – hvis de ikke er det, skyldes det en bevidst programmering af platformsafhængighed.

Regler for 100% Pure Java-programmer

For at få et program, der er 100% Pure Java, er der fire  regler, man skal overholde:

  • Brug ikke native metoder.
  • Brug kun Java’s API.
  • Brug ikke platformsafhængige konstanter.
  • Følg retningslinierne for anvendelsen af API’et.

I dette afsnit vil det blive gennemgået, hvordan man overholder disse regler.

Den første regel siger, at man ikke må anvende native metoder. Dette skyldes, at native metoder er kompileret til maskinkode, der er specifik for de forskellige operativsystemer. Da native metoder også er skrevet i et andet programmeringssprog end Java, mister man mange af de fordele, Java giver – eksempelvis sikkerhed og garbage collection.

 

Reglen om ingen brug af native metoder betyder også, at det ikke er alle metoder i klassen java.lang.Runtime, der må anvendes. Mange af disse metoder, giver adgang til hardware, og selvom metoderne ofte er anvendelige, er de ganske afgjort ikke portable. Metoden Runtime.exec er et særtilfælde, idet den gerne må bruges under visse omstændigheder. Der stilles følgende krav til anvendelsen af Runtime.exec:

 

  • Udførslen af metoden skal skyldes en handling foretaget af brugeren. Brugeren skal således være klar over, at det er et separat program, der bliver udført.
  • Brugeren skal kunne vælge, hvilket program der startes. Dette kan enten ske under installationen, ved konfigurering eller lige før programmet udføres.
  • Alle fejl, der opstår ved udførsel af Runtime.exec, skal håndteres. Dette gælder i særlig grad den fejl, der opstår, hvis programmet ikke findes.

 

Overholder man disse regler, er det tilladt at afvikle andre programmer. Eksempler på lovlig adfærd kan være:

 

 

 

  • Start af Java-compileren, hvis brugeren selv kan vælge navnet på compileren.
  • Udførsel af en kommando brugeren indtaster – en shell eller en dos-prompt.

 

Den eneste undtagelse for reglen om ingen anvendelse af native metoder er brug af alternative implementeringer af standard interfaces. Mange af metoderne i Java API’et er native, men da disse skal findes på alle platforme, er det tilladt at bruge disse.

 

Reglen om, at man kun må bruge Javas API, bunder i, at programmer skal være komplette, før de kan certificeres som 100% Pure Java. Det vil sige, at de ikke må indeholde referencer til eksterne biblioteker eller interfaces, som ikke er en del af Java-standarden. Det er naturligvis tilladt at bruge komponenter fra tredjepart, når blot disse leveres med programmet.

 

Reglen omfatter også, at man ikke må bruge udokumenterede funktioner i Java API’et. Mange af klasserne i API’et gør selv brug af disse funktioner, men det er ikke tilladt for andre programmer at gøre det. Det skyldes, at Sun forbeholder sig ret til at ændre i de udokumenterede funktioner. Det er herefter op til de, der har licenseret Java, at sørge for, at de dokumenterede dele af API’et stadigvæk fungerer. Grunden til, at funktionerne ikke er dokumenterede, er netop, at de ikke er beregnet til at blive brugt af applikationsprogrammøren.

 

Hele pakken java.awt.peer er omfattet af denne regel. De interfaces og klasser, der befinder sig i denne pakke, er dokumenteret som ”anvendes af AWT-implementører”. Et platformsuafhængigt program vil gøre brug af AWT fremfor at implementere det.

 

Den tredje regel siger, at der ikke må anvendes platformsafhængige konstanter. Dette udtryk er lidt kryptisk, men det dækker blot over, at man ikke må bruge konstanter, der ikke er konstante på alle platforme. Eksempelvis bruger Windows 95 og Unix ikke det samme tegn til at adskille elementer i en sti, og der kan også være forskel på, hvilken tegnkombination som bruges til at angive linieskift.

 

Den sidste regel siger, at man skal overholde de retningslinier, der gælder for brug af API’et. Gør man ikke dette, er det muligt at skrive programmer, der er syntaktisk korrekte, men som alligevel ikke vil være portable.

 

Et eksempel på dette kan være en klasse, der overskriver java.lang.Object’s equals-metode. Denne klasse skal også redefinere metoden hashCode for at opretholde den invariant, at objekter, der er ens, har den samme hashkode.

 

Det er svært at kontrollere, om reglen bliver overholdt, og det er ikke sikkert, at alle brud på den vil blive opdaget af certificeringscentret.

 

Almindelige fejl

 

Reglerne for et 100% Pure Java-program er ret abstrakte. Det kan være svært at sige, om en specifik fremgangsmåde er tilladt eller ej. I dette afsnit vil forskellige almindelige fejl blive gennemgået, ligesom det vil blive forklaret, hvordan man kan opnå den samme funktionalitet på en pure måde.

Tråde

Tråde håndteres forskelligt på forskellige platforme. Der er ingen garanti for, at den samme scheduleringsmetode anvendes i alle implementeringer af Java. Derfor må man ikke i sit program opstille forventninger om, hvor meget processortid de forskellige tråde tildeles. Hvis man bruger denne fremgangsmåde til at sikre, at der ikke er flere tråde, som tilgår det samme objekt samtidigt, er ens program ikke portabelt.

 

Dette problem er et kompliceret problem, og det ikke nemt at se, om det eksisterer i ens kode. Det er heller ikke nemt at løse problemet. En drastisk løsning er at markere alle metoder som synkroniserede (synchronized). På den måde kan man fange en del af synkroniseringsproblemerne, men ikke dem alle. Den eneste universelle løsning er at programmere efter nogle sikre retningslinier. Disse er forklaret i adskillige lærebøger om parallel programmering.

 

Native metoder

 

I visse situationer kan det synes nødvendigt at bruge native metoder. Dette kan enten være for at give adgang til specielle systemressourcer eller for at optimere en tung del af et program.

 

Der findes to løsninger på dette problem:

 

  • Definer en simpel protokol, der giver adgang til den ønskede ressource, og skriv et 100% Pure Java-program som en klient af den protokol.
  • Omskriv den native metode i Java.

 

En tredje løsning kunne være at begrænse alle native metoder til en enkelt klasse, og så levere en implementering af denne klasse til alle platforme, der understøtter Java. Denne løsning er imidlertid ikke gyldig, da antallet af platforme, der undersøtter Java, stiger konstant. Derudover skal man tænke på, at det ikke er alle platforme, der kan afvikle kompileret kode. Det gælder eksempelvis JavaStation.

 

Skærmopsætning

Som nævnt tidligere bruger forskellige platforme forskellige tegn til at angive et linieskift. Det er også forskelligt, hvilke opløsninger og systemfarver der kan bruges på de forskellige platforme.

Java indeholder forskellige metoder til at få informationer om det system, programmet afvikles på. Hvis man anvender disse, behøver man ikke skrive informationerne direkte i programmet.

Hvis man vil have at vide, hvilke tegn der bruges som linieskift, kan man kalde System.getProperty (“line.seperator”). Vil man have størrelsen af skærmen, kan man bruge de getSize-metoder, der findes i AWT, mens systemfarverne kan findes i java.awt.SystemColor. Generelt kan det anbefales at benytte layout-managere i stedet for at angive størrelsen af de forskellige komponenter i programmet. Man skal også være opmærksom på, at de forskellige komponenter i AWT og Swing kan have forskellige størrelse på forskellige platforme.

 

 

 

Reflections

 

Reflections er en særdeles stærk facilitet – desværre gør den det også sværere at forudsige, hvordan programmer vil opføre sig. Man kan eksempelvis kalde Method.invoke på enhver metode – også metoder der gør, at programmet ikke er 100% Pure Java. Reflections skal derfor bruges med stor forsigtighed.

 

System.exit

 

Metoden System.exit medfører, at programmet afsluttes omgående. Dette medfører, at alle tråde i den virtuelle maskine bliver stoppet. Dette kan medføre, at vinduer bliver lukket, uden at brugeren får en mulighed for at gemme indholdet af dem.

Generelt bør man ikke benytte System.exit til at stoppe programmet. Metoden er forbeholdt de tilfælde, hvor en fejl gør, at programmet simpelthen ikke kan fortsætte. System.exit kan også anvendes, hvis programmet skal anvendes i et script eller en batchfil, hvor programmets fejlkode er vigtig.

Filnavne

Hvis man angiver en komplet sti til et filnavn – for eksempel data\data.dat – gør man programmet uportabelt. Det er nemlig ikke alle platforme, der bruger det samme tegn til at adskille elementer i en sti.

Der findes generelt tre portable måder at oprette et filnavn på:

  • Brug File (File, String) til at opbygge stien.
  • Brug system properties til at finde ud af hvilke tegn, der bruges til at adskille stier og filnavne. Det gøres ved hjælp af System.getProperties (“file.separator”) og SystemGetProperties (“path.separator”).
  • Brug en dialogboks til at bede brugeren angive filnavnet.

JDBC

Det JDBC-interface, der ligger i java.sql-pakken, giver fleksibilitet i indlæsningen af JDBC-driverne. Denne fleksibilitet gør det muligt at skifte mellem flere forskellige JDBC-drivere uden at skulle ændre programmet.

Denne fleksibilitet gives af klassen DriverManager. Der findes to måder at fortælle denne klasse, hvilke drivere der er tilgængelige.

  • De kan nævnes i jdbc.drivers-property’en.
  • De kan indlæses ved hjælp af metoden java.lang.Class.forName.

Dette kan medføre et portabilitetsproblem, da JDBC-driverne ikke nødvendigvis er ligeså portable som resten af programmet. Hvis man angiver et specifikt navn på en JDBC-driver i sin kode, er programmet ikke mere portabelt end denne driver.

 

Løsningen på dette problem er at give brugeren mulighed for at konfigurere, hvilken JDBC-driver der skal anvendes. Det kan man gøre ved at læse

 

fra properties eller ved at lade brugeren selv angive det filnavn, der bruges i Class.forName-metoden. Man kan også lade udvælgelsen af driveren være op til DriverManager-klassen. Hvis man gør det, skal man være opmærksom på følgende:

 

  • Drivere forsøges indlæst i den rækkefølge, de er blevet registreret. Det vil sige, at tidlige drivere vil have prioritet over drivere, der er registreret senest. De drivere, der er angivet i jdbc.drivers, vil have den højeste prioritet.
  • En driver, der inkluderer native kode, vil ikke kunne indlæses på andre platforme end den, den blev skrevet for. Derfor må programmet håndtere muligheden for en ClassNotFoundException.
  • En driver med native kode må ikke registrere sig i DriverManager, før den er sikker på, at den er indlæst.
  • En driver med native kode er ikke omfattet af Javas sikkerhedsmodel og kan derfor udgøre en sikkerhedsrisiko.

 

Kommandolinie

 

Programmer, der kun bruger kommandolinien til at interagere med brugeren, er ikke portable. Det er nemlig ikke alle platforme, der har en kommandolinie. Hvis man kun bruger System.in, System.out eller System.err, bør man overveje at lave en grafisk brugergrænseflade – i det mindste som et alternativ.

 

Et andet problem, der er relateret til kommandolinien, er, hvordan parametre skal fortolkes. Den mest portable fremgangsmåde er at lade være med at anvende kommandolinieparametre, men det er ikke en mulighed, hvis programmet skal bruges fra et script eller en batchfil. Hvis man er nødt til at lade sit program acceptere parametre, bør man som minimum understøtte POSIX-standarden, hvor parametre indledes med en bindestreg (dash). Det er meget almindeligt, at både bindestreg og skråstreg (slash) kan anvendes til at angive parametre. Som alternativ bør man inkludere en grafisk brugergrænseflade eller muligheden for at indlæse parametre fra en property-fil.

 

Event-håndtering

 

Eventhåndteringen blev ændret fra JDK version 1.0.2 til version 1.1. Programmer, der gør brug af eventhåndteringsmekanismen, kan afvikles på en version 1.1-platform, men programmer, der bruger en kombination af de to fremgangsmåder, er ikke sikre på at kunne afvikles. Selvom programmet ser ud til at virke på én platform, er der ingen garanti for, at den virker på en anden.

 

Løsningen på dette problem er naturligvis at vælge, hvilken model man vil bruge. Hvis man konverterer et program fra version 1.0.2 til version 1.1, skal man gøre dette på en gang – man skal ikke konvertere små dele af programmet.

 

 

 

Ukurante  metoder

 

Dokumentationen af Javas API angiver, at nogle metoder ikke længere er gængse – de er blevet markeret som deprecated. Det vil sige, at metoderne stadig understøttes, men vil blive fjernet på et senere tidspunkt. Hvis man bruger en forældet metode, får man det at vide, når man kompilerer sit program. Det er generelt et godt råd at ændre sit program i så fald, da der sikkert er en grund til, at metoden er blevet markeret som ukurant.

 

Man kan få yderligere oplysninger om forældede metoder ved at tilføje parametren –deprecation til kaldet af javac. Der gives også oplysninger om forældede metoder i specifikationerne af Java API’et.

Installation

Der kan opstå mange problemer i forbindelse med installation af produktet. Nogle platforme har en begrænsning i længden af filnavne, og det er ofte begrænset, hvilke tegn der må anvendes i filnavne. Dette kan give problemer, da virtuelle Java-maskiner gør brug af en simpel fortolkning fra klassenavn til filnavn.

De restriktioner, der kan give problemer, er:

  • Begrænsning af længden af filnavne. Dette er især et problem med indre klasser, der gives forholdsvis lange filnavne.
  • Store og små bogstaver. Nogle platforme (eksempelvis Windows) behandler store og små bogstaver ens. Hvis man har to klasser eller pakker, eller en klasse og en pakke, der har det samme navn blot med forskellig blanding af store og små bogstaver, vil programmet ikke kunne afvikles på disse platforme.
  • Manglende understøttelse af Unicode. Klassers navne kan indholde Unicode-tegn, der ikke kan bruges som filnavne på alle platforme.
  • Specielle filnavne. Nogle platforme giver specielle filnavne en speciel betydning. Det gælder for eksempel navne som LPT og con. Disse navne kan ikke bruges som navne på pakker eller klasser på disse platforme.

Løsningen på dette problem er at lægge alle filerne i en JAR-pakke. Det vil løse problemerne med begrænsninger i længden på filnavne og også problemerne med store og små bogstaver. JAR er implementeret i Java fra og med version 1.1. Hvis man bruger JDK version 1.0, er zip-filer et godt alternativ.

Internetadresser

 

Man skal være opmærksom på, at den streng, der returneres af java.net.InetAddress.getHostName, er platformsafhængig. På nogle platforme returneres et komplet domænenavn, mens andre kun returnerer host-delen af navnet.

 

Oftest vil dette ikke være noget problem, da begge tekststrenge kan bruges til at oprette en forbindelse. Hvis man imidlertid har brug for at overføre navnet på host’en til andre computere, er den bedste fremgangsmåde at overføre IP-nummer. Man kan finde IP-nummeret ved at kalde metoden getAddress.

 

 

 

Gode råd

 

Det forrige afsnit har beskrevet forskellige almindelige problemer, og hvordan disse undgås. Dette afsnit vil give nogle gode, generelle råd om, hvordan man udvikler programmer, der kan opnå 100% Pure Java-certificeringen.

Appletter

Det er forholdsvis kompliceret at skrive portable appletter. Når en applets portablitet skal vurderes, ser man ikke kun på selve klassen, men også på den side, der indeholder apletten, den HTML-kode, som indelæser programmet, og den security-manager og applet context, der anvendes på brugerens browser.

I HTML-dokumentet skal indholdet af <applet>-kommandoen overholde følgende krav:

  • Alle parametre (<param>) skal forekomme, før det alternative indhold.
  • Det alternative indhold skal angives, som var det i et afsnit (<p>). Det betyder, at der ikke må være <p>-kommandoer i den alternative tekst.

Næsten alle appletter bliver afviklet under en sikkerhedsmanager (security manager). Der er imidlertid ikke nogen standard for sikkerhedsmanagere. Brugeren kan indstille sin sikkerhedsmanager efter forgodtbefindende og kan således afvise alle mulige former for funktioner. Den bedste måde at håndtere dette problem på er at håndtere alle opståede SecurityExceptions på en fornuftig måde.

Ligeledes definerer Java-standarden ikke hvilke protokoller, der kan anvendes fra appletter. Generelt er protokollerne http, ftp og file sikre. Det samme gælder mime-typerne image/jpeg og image/gif. Igen gælder det, at man skal være parat på at håndtere eventuelle fejl.

Sikkerhed

Hvis ens program bliver afviklet under en sikkerhedsmanager, kan der opstå en SecurityException. Dette er en af de exceptions, der er unchecked. Det vil sige, at den kan opstå, selvom den ikke er defineret i en metodes throws-sætning. Da brugeren har mulighed for selv at indstille sikkerhedsmanageren, er det svært at sige, hvornår en SecurityException kan opstå. Derfor anbefales det, at alle programmer håndterer eventuelle SecurityExceptions på en fornuftig måde. Det betyder ikke, at man behøver at kontrollere, om der er opstået en SecurityException efter hvert eneste metodekald. Man kan blot gøre det i main-metoden, da en unhåndteret SecurityException i sidste ende vil ende her.

 

Fejl

 

Visse implementeringer af Java-platformen indeholder fejl. For at gøre sit program så portabelt som muligt, bør man skrive sit program, så det undgår kendte fejl i Java-implementeringer. Hvis man ved hvilke Java-implementeringer,

 

der indeholder en given fejl, kan man kontrollere om man befinder sig på den pågældende platform ved at kalde metoden System.getProperty(“java.maker”).

 

Undgå risikofyldte metoder

 

Der er en række metoder, som automatisk giver fejl i Java Pure Check, og som kan gøre, at ens program ikke kan certificeres. Der findes en oversigt over disse metoder og de fejl de giver i appendiks C.

 

Sammenfatning

 

I dette kapitel er det blevet gennemgået, hvordan man kan få sine Java-programmer certificeret som 100% Pure Java. Der er også blevet givet gode råd – såvel generelle råd som råd om, hvordan man undgår at begå de mest almindelige fejl.

 

FAQ

 

Hvorfor skal man bruge tid og penge på få sine produkter certificerede?

Ved at benytte 100% Pure Java-logoet kan man forsikre sine kunder om, at ens produkt er platformsuafhængigt. Derudover giver certificeringen også adgang til en række markedsføringsprogrammer i samarbejde med andre certificerede produkter og Sun.

 

Skal produktet certificeres igen, hvis man ændrer programmet for at rette en fejl?

Nej. Hvis man kun retter fejl, kan man nøjes med at sende Sun en skriftlig erklæring om, at ændringen ikke har indflydelse på portabiliteten af produktet.

 

Skal produktet certificeres igen, hvis det udkommer i en ny version?

Ja. Hvis produktet indeholder funktionalitet, der ikke tidligere er blevet testet, skal produktet certificeres igen.

 

Kan certificeringen tilbagekaldes?

Ja. Sun forbeholder sig ret til at tilbagekalde certificeringen, hvis kravene til at være certificeret ikke er opfyldt, selvom certificeringsprocessen er gennemgået. Dette kan eksempelvis ske, hvis en producent af et certificeret produkt offentligt siger, at produktet ikke opfylder kravene til certificeringen – for eksempel ved ikke at være certificeret.

Du læser en gammel bog
Den bog, du læser her, er fra 1998, og mange ting kan have ændret sig siden da.
Vi håber, at du stadig kan finde relevant information i den.
Hvis du vil læse aktuelle oplysninger om de avancerede dele af Java, anbefaler vi
bogen Core Java – Advanced Features

Comments are closed.