Java-programmeringsspråkkompilatoren (javac) levert av Oracle (og tidligere av Sun) har flere ikke-standardiserte alternativer som ofte er nyttige. En av de mest nyttige er settet med ikke-standardalternativer som skriver ut advarsler som oppstod under kompilering. Dette settet med alternativer er gjenstand for dette innlegget.
Javac-sideseksjonen på ikke-standardalternativlister og gir korte detaljer om hvert av disse alternativene. Følgende er det aktuelle utdraget fra den siden.
En liste over disse alternativene er også tilgjengelig fra kommandolinjen (forutsatt at Java SDK er installert) med kommandoen: javac -help -X. Dette er kortere enn eksempelet på mansiden / nettsiden som er vist ovenfor, og vises neste.
Som forrige øyeblikksbilde fra å kjøre javac -hjelp -X indikerer at de ti spesifikke forholdene Xlint-advarsler eksisterer for er (i alfabetisk rekkefølge): rollebesetning, avskrivning, divzero, tømme, faller gjennom, endelig, overstyrer, sti, seriell, og ukontrollert. Jeg ser kort på hver av disse og gir et kodebit som fører til at denne advarselen oppstår når Xlint er slått på. Merk at man-siden for javac og Java SE 6 javac-siden begge bare viser halvparten av disse Xlint-alternativene (dokumentasjon er tilsynelatende ikke like oppdatert som javac-bruk / hjelp). Det er en nyttig NetBeans Wiki-oppføring som oppsummerer alle de ti alternativene.
Javac-kompilatoren tillater at alle eller ingen av Xlint-advarslene aktiveres. Hvis Xlint ikke er spesifisert i det hele tatt av alternativet -Xlint: none er eksplisitt spesifisert, er atferden å ikke vise de fleste advarslene. Interessant, utdataene gir en advarsel om avvikling og ukontrollerte advarsler og anbefaler at du kjører javac med -Xlint aktivert for å se detaljene om disse to typer advarsler.
Før slutten av dette innlegget vil jeg demonstrere Java-kode som fører til 13 rapporterte totalt Xlint-advarsler som dekker alle ti alternativene som er diskutert ovenfor. Uten Xlint er imidlertid utdataene vist som vist på neste skjermbilde.
Som bildet ovenfor indikerer, enten Xlint ikke er spesifisert i det hele tatt eller er spesifisert spesifisert med "ingen", er resultatet det samme: flertallet av advarslene vises ikke, men det er enkle referanser til avskrivningen og ukontrollerte advarsler med anbefalinger å kjøre javac med henholdsvis -Xlint: avvikling og -Xlint: ikke merket for ytterligere detaljer. Kjører javac med -Xlint: alle eller -Xlint uten andre alternativer vil vise alle advarsler og vil fungere for å se detaljene angående utdaterte, ukontrollerte og alle andre aktuelle Xlint-aktiverte advarsler. Dette vil vises etter å ha gått gjennom kildekoden og hver Xlint-advarsel individuelt.
-Xlint: rollebesetning
Dette alternativet kan brukes til å få kompilatoren til å advare utvikleren om at en redundant rollebesetning blir laget. Her er et kodebit som vil bli flagget hvis -Xlint, -Xlint: all eller -Xlint: cast ble gitt til javac når du kompilerer kilden.
/ ** * Demonstrerer -Xlint: cast advarsel om en overflødig rollebesetning. * / privat statisk ugyldighet demonstrere CastWarning () {final Set people = new HashSet (); folk.add (fred); people.add (wilma); people.add (barney); for (endelig personperson: mennesker) {// Redundant rollebesetning fordi generisk type eksplisitt er Person out.println ("Person:" + ((Person) person) .getFullName ()); }} I koden ovenfor er det ikke behov for å kaste personobjektet inne i for-sløyfen til Person og -Xlint: rollebesetning vil advare om denne unødvendige og overflødige rollebesetningen med en melding om noe som:
src \ dustin \ eksempler \ Main.java: 37: advarsel: [cast] redundant cast to dustin.examples.Person out.println ("Person:" + ((Person) person) .getFullName ()); ^ -Xlint: avskrivning
Som omtalt ovenfor ble Xlint-avskrivningsvarselen åpenbart ansett som viktig nok til å rettferdiggjøre at den ble annonsert, selv når Xlint ikke kjøres eksplisitt. Denne advarselen oppstår når en avviklet metode påkalles. Følgende kodeeksempel viser en slik sak.
/ ** * Årsak -Xlint: utskrivning for å skrive ut advarsel om bruk av utdatert metode. * / private static void demonstrDeprecationWarning () {out.println ("Freds fulle navn er" + fred.getName ()); } Du kan ikke fortelle uten kildekoden for Person-klassen (hvorav "fred" er en forekomst), men at getName () -metoden blir utfaset i Person. Følgende utdata fra å kjøre javac med -Xlint, -Xlint: all eller -Xlint: avvik bekrefter det (eller påpeker det hvis utvikleren savnet det).
src \ dustin \ eksempler \ Main.java: 47: advarsel: [deprecation] getName () i dustin.examples.Person er utfaset out.println ("Freds fulle navn er" + fred.getName ()); ^ -Xlint: divzero
Divzero Xlint-alternativet indikerer når integrert divisjon deles med et bokstavelig null. Et kodeeksempel som vil demonstrere dette vises neste:
/ ** * Demonstrer -Xlint: divzero i aksjon ved å dele en int med en bokstavelig null. * / privat statisk tomrom demonstrereDivideByZeroWarning () {out.println ("To delt med null er" + divIntegerByZeroForLongQuotient (2)); } / ** * Del den oppgitte deleren i det oppgitte utbyttet, og returner den * resulterende kvoten. Det foretas ingen kontroller for å sikre at skillelinjen ikke er null. * * @param dividend Heltall som skal deles. * @return Kvotient på divisjon av utbytte med bokstavelig null. * / private static long divideIntegerByZeroForLongQuotient (final int dividend) {// Hardkodet divisor på null vil føre til advarsel. Hadde divisoren blitt // sendt inn som en parameter med nullverdi, ville dette ikke føre til // den advarselen. returutbytte / 0; } Resultatet fra javac når det ovennevnte er samlet, vises nå.
src \ dustin \ eksempler \ Main.java: 231: advarsel: [divzero] divisjon med null returutbytte / 0; ^ Da jeg forsettlig prøvde å tvinge denne advarselen, så det ut til å bare fungere for en hardkodet (bokstavelig) nulldeler. Dessuten markerer den ikke dobbeltdeling fordi Infinity kan returneres som et gyldig svar i så fall uten å kaste et unntak.
-Xlint: tom
Meningen med -Xlint: tom er å varsle utvikleren om at en "tom" hvis betinget er i koden. Fra testene mine ser dette ut til å bare gjelde for tilfellet med den tomme "hvis" -blokken. NetBeans gir "tips" (de gule understrekede advarslene som også er merket i høyre marg i kildekodeeditoren) for flere typer tomme utsagn, men -Xlint: tom ser ut til å bare flagge de tomme "hvis" uttalelsene. Jeg inkluderte de andre som NetBeans flagg sammen med den ene -Xlint: tom flagg i neste kildekodeeksempel.
/ ** * Denne metoden demonstrerer hvordan javacs -Xlint: tom fungerer. Merk at javacs * -Xlint: tom bare vil flagge den tomme setningen som er involvert i "if" -blokken, * men ikke markere de tomme utsagnene som er knyttet til gjør-mens-sløyfen, * mens-sløyfen, for-sløyfen eller hvis -ellers. NetBeans markerer disse hvis * passende "tips" er slått på. * / privat statisk tomrom demonstrere EmptyWarning () {int [] heltall = {1, 2, 3, 4, 5}; hvis (heltall.lengde! = 5); out.println ("Ikke fem?"); hvis (heltall.lengde == 5) out.println ("Fem!"); ellers; out.println ("Ikke fem!"); gjøre; mens (heltall.lengde> 0); for (int heltall: heltall); out.println ("Et annet heltall funnet!"); int teller = 0; mens (teller <5); out.println ("Ekstra semikolon.") ;;;; } Koden ovenfor er fylt med problematisk plassering av semikolon som nesten helt sikkert ikke er det utvikleren ønsket. Denne koden vil kompilere, men utvikleren blir advart om disse mistenkelige situasjonene hvis -Xlint, -Xlint: alt, eller -Xlint: tom brukes med javac. Advarselsmeldingene som skrives ut i den ellers vellykkede samlingen, vises neste.
src \ dustin \ eksempler \ Main.java: 197: advarsel: [tom] tom uttalelse etter if if (heltall.lengde! = 5); ^ Bare den tomme "hvis" utsagnsklausulen er flagget; de andre blir ikke rapportert av -Xlint: tom.
-Xlint: gjennombrudd
En fristende, men kontroversiell bekvemmelighet Java gir, er muligheten til å "slå igjennom" vanlige uttrykk i en bytte om uttalelse for å anvende den samme logikken på flere integrerte verdier med ett stykke kode. Hvis alle de integrerte verdiene med den delte funksjonaliteten er tomme, bortsett fra den endelige som faktisk utfører funksjonaliteten og gir en gå i stykker, den -Xlint: gjennombrudd vil ikke bli aktivert. Imidlertid, hvis noen av de sak uttrykk utfører sin egen logikk i tillegg til den vanlige gjennombruddslogikken, er denne advarselen produsert. Et eksempel som viser dette vises neste.
/ ** * Årsak -Xlint: gjennomgang for å skrive ut advarsel om bruk av bryter / sak * gjennomgang. * / private static void demonstrFallthroughWarning () {out.print ("Wilmas favorittfarge er"); out.print (wilma.getFavoriteColor () + ", som er"); // sjekk for å se om "kunstnerisk" primærfarge // MERK: Denne vil ikke føre til -Xlint: gjennombrudd som markerer en advarsel // fordi ingen funksjonalitet er inkludert i noen av saksuttalelsene // som ikke har sin egen gå i stykker. switch (wilma.getFavoriteColor ()) {case BLUE: case GUL: case RED: out.print ("en primærfarge for kunstneriske anstrengelser"); gå i stykker; sak BLACK: sak BRUN: sak CORAL: sak EGGSHELL: sak GRØNN: sak MAUVE: sak ORANGE: sak ROSE: sak Lilla: sak TAN: sak HVIT: standard: out.print ("IKKE en primær kunstnerisk farge"); } out.print ("og er"); // sjekk for å se om 'additiv' primærfarge // MERKNAD: Denne bryteren VIL føre til -Xlint: gjennombrudd med en advarsel // fordi det utføres noe funksjonalitet i et tilfelle // uttrykk som ikke har sin egen pauseuttalelse . switch (wilma.getFavoriteColor ()) {case BLUE: case GREEN: out.println ("(det er ikke lett å være grønn!)"); case RED: out.println ("en primærfarge for tilsetningsarbeid."); gå i stykker; sak SVART: sak BRUN: sak KORALL: sak EGGSHELL: sak MAUVE: sak ORANGE: sak ROSE: sak Lilla: sak TAN: sak GUL: sak HVIT: standard: out.println ("IKKE en primær additivfarge."); }} Ovennevnte kodeeksempel viser med vilje begge tilfeller (ordspill beregnet) på bryteren / saken som vil og ikke vil føre til en advarsel takket være -Xlint: gjennombrudd. Utgangen, med bare en advarsel, vises neste.
src \ dustin \ eksempler \ Main.java: 95: advarsel: [gjennomgang] mulig gjennomslag i sak RED: ^ De sak som ble flagget var den RØDE sak etter det GRØNNE sak som gjorde noe av sin egen logikk før de falt til den RØDE logikken.
-Xlint: endelig
Mer enn én person har advart: "Ikke kom tilbake i en endelig klausul." Faktisk er "Java's return ikke alltid" i The Java Hall of Shame. En Java-utvikler kan advares om denne skumle situasjonen ved å bruke -Xlint, -Xlint: alt, eller -Xlint: endelig. Et stykke kildekode som viser hvordan denne advarselen kan genereres, vises neste.
/ ** * Demonstrer -Xlint: genererer endelig advarsel når en {@code finally} * -blokk ikke kan slutte normalt. * / private static void demonstrFinallyWarning () {try {final double quotient = divideIntegersForDoubleQuotient (10, 0); out.println ("Kvotienten er" + kvotient); } catch (RuntimeException uncheckedException) {out.println ("Fanget unntaket:" + uncheckedException.toString ()); }} / ** * Del den oppdelte deleren i det oppgitte utbyttet og returner * den resulterende kvotienten. Det foretas ingen kontroller for å sikre at skillelinjen ikke er null. * * @param dividend Heltall som skal deles. * @param divisor Heltall hvor utbytte blir delt. * @return Kvotient for deling av utbytte etter divisor. * / privat statisk dobbel divisjonIntegersForDoubleQuotient (final int dividend, final int divisor) {double quotient = 0.0; prøv {if (divisor == 0) {throw new ArithmeticException ("Divisjon med null ikke tillatt: kan ikke utføre" + dividend + "/" + divisor); } // Dette ville ikke ha ført til Xlint: divzero advarsel hvis vi kom hit // med en bokstavelig nulldeler fordi Infinity rett og slett hadde blitt // returnert i stedet for implisitt kasting av ArithmeticException. kvotient = (dobbelt) utbytte / divisor; } til slutt {returkvotient; }} Ovennevnte er feil og er sannsynligvis ikke det utvikleren hadde til hensikt. Den aktuelle advarselen javac gir når Xlint er aktivert, vises neste.
src \ dustin \ eksempler \ Main.java: 159: advarsel: [endelig] kan endelig punkt ikke fullføres normalt} ^ -Xlint: overstyrer
