Java Language
Java-kommandot - 'java' och 'javaw'

Syntax

• java [ <opt> ... ] <class-name> [ <argument> ... ]

• java [ <opt> ... ] -jar <jar-file-pathname> [ <argument> ... ]

Anmärkningar

Kör en körbar JAR-fil

Exekverbara JAR-filer är det enklaste sättet att samla Java-kod i en enda fil som kan köras. * (Redaktionell anmärkning: Skapandet av JAR-filer bör täckas av ett separat ämne.) *

Antagande att du har en körbar JAR-fil med söknamnet <jar-path> , borde du kunna köra den enligt följande:

java -jar <jar-path>

Om kommandot kräver kommandoradsargument, lägg till dem efter <jar-path> . Till exempel:

java -jar <jar-path> arg1 arg2 arg3

Om du måste tillhandahålla ytterligare JVM-alternativ på java kommandoraden måste de gå före -jar alternativet. Observera att -cp / -classpath ignoreras om du använder -jar . Applikationens klassväg bestäms av JAR-filmanifestet.

Köra Java-applikationer via en "huvudklass"

När en applikation inte har paketerats som en körbar JAR måste du ange namnet på en startpunktsklass på kommandoraden java .

Kör HelloWorld-klassen

Exemplet "HelloWorld" beskrivs i Skapa ett nytt Java-program . Den består av en enda klass som heter HelloWorld som uppfyller kraven för en startpunkt.

Förutsatt att filen (kompilerad) "HelloWorld.class" finns i den aktuella katalogen, kan den startas enligt följande:

java HelloWorld

Några viktiga saker att notera är:

• Vi måste ange klassens namn: inte sökvägen för filen ".klass" eller ".java".
• Om klassen deklareras i ett paket (som de flesta Java-klasser är), måste klassnamnet vi tillhandahåller java kommandot vara hela klassnamnet. Om till exempel SomeClass deklareras i paketet com.example , kommer hela klassnamnet att vara com.example.SomeClass .

Ange en klassväg

Om vi inte använder kommandosyntaxen java -jar java kommandot efter klassen som ska laddas genom att söka på klassvägen; se The Classpath . Ovanstående kommando förlitar sig på att standardklassvägen är (eller inkluderar) den aktuella katalogen. Vi kan vara mer tydliga om detta genom att ange klassvägen som ska användas med alternativet -cp .

java -cp . HelloWorld

Detta säger att göra den aktuella katalogen (vilket är vad "." Hänvisar till) till den enda posten på klassvägen.

-cp är ett alternativ som behandlas av java kommandot. Alla alternativ som är avsedda för java kommandot bör vara före klassnamnet. Något efter klassen kommer att behandlas som en kommandorad argument för Java-applikationen, och kommer att skickas till applikationen i String[] som skickas till den main metoden.

(Om inget -cp alternativ tillhandahålls, kommer java att använda den klassväg som ges av CLASSPATH miljövariabeln. Om den variabeln är inställd eller tom använder java "." Som standardklassväg.)

Anmälningspunkt klasser

Ett Java ingångspunkts klass har en main med följande signaturen och modifierare:

public static void main(String[] args)

Sidotecken: på grund av hur matriser fungerar kan det också vara (String args[])

När java kommandot startar den virtuella maskinen, laddar den de angivna startpunktsklasserna och försöker hitta main . Om det lyckas konverteras argumenten från kommandoraden till Java String objekt och samlas i en array. Om main anropas så här kommer matrisen inte att vara null och kommer inte att innehålla några null .

En giltig ingångsmetodsklassmetod måste göra följande:

• Utnämnas till main (skiftlägeskänslig)
• Var public och static
• Har en void returtyp
• Har ett enda argument med en matris String[] . Argumentet måste vara närvarande och inte mer än ett argument är tillåtet.
• Var generisk: typparametrar är inte tillåtna.
• Har en icke-generisk högklassig (inte kapslad eller inre) inneslutande klass

Det är vanligt att förklara klassen som public men detta är inte strikt nödvändigt. Från Java 5 och framåt, det main kan metoden argument typ vara en String varargs i stället för en sträng array. main kan valfritt kasta undantag, och dess parameter kan namnges vad som helst, men konventionellt är det args .

JavaFX-ingångspunkter

Från Java 8 och framåt kan java kommandot också direkt starta en JavaFX-applikation. JavaFX är dokumenterat i JavaFX- taggen, men en JavaFX-startpunkt måste göra följande:

• javafx.application.Application
• Var public och inte abstract
• Var inte generisk eller kapslad
• Ha en uttrycklig eller implicit public konstruktion utan argumentering

Felsökning av "java" -kommandot

Detta exempel täcker vanliga fel med att använda kommandot 'java'.

"Kommando inte hittat"

Om du får ett felmeddelande som:

java: command not found

när du försöker köra java kommandot betyder det att det inte finns något java kommando på ditt skals kommandosökväg. Orsaken kan vara:

• du har inte någon Java JRE eller JDK installerad alls,
• du har inte uppdaterat PATH miljövariabeln (korrekt) i din skalinitieringsfil, eller
• du har inte "anskaffat" den relevanta initialiseringsfilen i det aktuella skalet.

Se "Installera Java" för de steg du behöver vidta.

"Kunde inte hitta eller ladda huvudklass"

Detta felmeddelande matas ut av java kommandot om det inte har kunnat hitta / ladda den ingångspunktsklass som du har angett. I allmänna termer finns det tre stora skäl till att detta kan hända:

• Du har angett en startpunktsklass som inte finns.
• Klassen finns, men du har angett den felaktigt.
• Klassen finns och du har angett den korrekt, men Java kan inte hitta den eftersom klassvägen är felaktig.

Här är en procedur för att diagnostisera och lösa problemet:

1. Ta reda på det fullständiga namnet på startpunktsklassen.

   • Om du har källkod för en klass består det fulla namnet av paketnamnet och det enkla klassnamnet. Instansen klassen "Main" deklareras i paketet "com.example.myapp" då dess fulla namn är "com.example.myapp.Main".
   • Om du har en sammanställd klassfil kan du hitta javap genom att köra javap på den.
   • Om klassfilen finns i en katalog kan du avlägsna hela klassnamnet från katalognamnen.
   • Om klassfilen finns i en JAR- eller ZIP-fil kan du dra slutsatsen från klassens sökväg i JAR- eller ZIP-filen.

2. Titta på felmeddelandet från java kommandot. Meddelandet bör avslutas med det fullständiga klassnamnet som java försöker använda.

   • Kontrollera att det exakt matchar det fullständiga klassnamnet för startpunktsklassen.
   • Det bör inte sluta med ".java" eller ".klass".
   • Det bör inte innehålla snedstreck eller något annat tecken som inte är lagligt i en Java-identifierare ¹ .
   • Höljet på namnet ska exakt matcha det fullständiga klassnamnet.

3. Om du använder rätt klassnamn, se till att klassen faktiskt finns på klassvägen:

   • Räkna ut bannamnet som klassnamnet kartlägger till; se Kartlägga klassnamn till sökväg
   • Ta reda på vad klassvägen är; se detta exempel: Olika sätt att specificera klassvägen
   • Titta på var och en av JAR- och ZIP-filerna på klassvägen för att se om de innehåller en klass med önskat söknamn.
   • Titta på varje katalog för att se om söknamnet löses till en fil i katalogen.

Om kontrollen av klassvägen för hand inte hittade problemet, kan du lägga till -Xdiag och -XshowSettings . Den förstnämnda listar alla klasser som laddas och den senare skriver ut inställningar som inkluderar den effektiva klassvägen för JVM.

Slutligen finns det några oklara orsaker till detta problem:

• En körbar JAR fil med en Main-Class -attribut som anger en klass som inte existerar.
• En körbar JAR-fil med ett felaktigt Class-Path attribut.
• Om du krossar ² alternativen före klassnamnet kan java kommandot försöka tolka ett av dem som klassnamn.
• Om någon har ignorerat Java-stilregler och använt paket- eller klassidentifierare som endast skiljer sig i bokstäver och du kör på en plattform som behandlar bokstäver i filnamn som icke-betydande.
• Problem med homoglyfer i klassnamn i koden eller på kommandoraden.

"Huvudmetod hittades inte i klass <namn>"

Det här problemet inträffar när java kommandot kan hitta och ladda klassen som du nominerade, men då inte kan hitta en startpunktsmetod.

Det finns tre möjliga förklaringar:

• Om du försöker köra en körbar JAR-fil, har JAR: s manifest ett felaktigt "huvudklass" -attribut som anger en klass som inte är en giltig ingångsklasse.
• Du har sagt till java kommandot en klass som inte är en ingångspunkt.
• Ingångspunktsklassen är felaktig; se klasser för inträde för mer information.

Andra resurser

• Vad betyder "Kunde inte hitta eller ladda huvudklass"?
• http://docs.oracle.com/javase/tutorial/getStarted/problems/index.html

^{1 - Från Java 8 och senare kommer java kommandot användbart att kartlägga en filnamnsavskiljare ("/" eller "") till en period ("."). Detta beteende är dock inte dokumenterat på de manuella sidorna.}

^{2 - Ett riktigt otydligt fall är om du kopierar och klistrar in ett kommando från ett formaterat dokument där textredigeraren har använt en "lång bindestreck" istället för en vanlig bindestreck.}

Köra en Java-applikation med biblioteksberoende

Detta är en fortsättning av exemplen "huvudklass" och "körbara JAR" .

Typiska Java-applikationer består av en applikationsspecifik kod och olika återanvändbara bibliotekskoder som du har implementerat eller som har implementerats av tredje part. De senare benämns vanligtvis biblioteksberoende och förpackas vanligtvis som JAR-filer.

Java är ett dynamiskt bundet språk. När du kör en Java-applikation med biblioteksberoende måste JVM veta var beroenden är så att den kan ladda klasser efter behov. I stort sett finns det två sätt att hantera detta:

• Applikationen och dess beroenden kan packas om till en enda JAR-fil som innehåller alla klasser och resurser som krävs.

• JVM kan berättas var man kan hitta beroende JAR-filer via runtime klassvägen.

För en körbar JAR-fil specificeras runtime klassvägen av attributet "Class-Path". (Redaktionell anmärkning: Detta ska beskrivas i ett separat ämne i kommandot för jar .) Annars måste runtime classpath levereras med alternativet -cp eller med hjälp av CLASSPATH miljövariabeln.

Anta till exempel att vi har en Java-applikation i "myApp.jar" -filen vars ingångsklass är com.example.MyApp . Anta också att applikationen beror på bibliotekets JAR-filer "lib / bibliotek1.jar" och "lib / bibliotek2.jar". Vi kan starta applikationen med hjälp av java kommandot enligt följande i en kommandorad:

$ # Alternative 1 (preferred)
$ java -cp myApp.jar:lib/library1.jar:lib/library2.jar com.example.MyApp

$ # Alternative 2
$ export CLASSPATH=myApp.jar:lib/library1.jar:lib/library2.jar
$ java com.example.MyApp

(I Windows skulle du använda ; istället för : som klassvägsavskiljare och du ställer in (lokal) CLASSPATH variabeln med set istället för export .)

Även om en Java-utvecklare skulle vara bekväm med det, är det inte "användarvänligt". Så det är vanligt att skriva ett enkelt skalskript (eller Windows-batchfil) för att dölja informationen som användaren inte behöver veta om. Om du till exempel lägger följande skalskript i en fil som heter "myApp", gjorde det körbart och placerade det i en katalog på kommandosökvägen:

#!/bin/bash
# The 'myApp' wrapper script

export DIR=/usr/libexec/myApp
export CLASSPATH=$DIR/myApp.jar:$DIR/lib/library1.jar:$DIR/lib/library2.jar
java com.example.MyApp

då kan du köra det enligt följande:

$ myApp arg1 arg2 ...

Alla argument på kommandoraden kommer att skickas till Java-applikationen via "$@" -utvidgningen. (Du kan göra något liknande med en Windows-filfil, men syntaxen är annorlunda.)

Mellanslag och andra specialtecken i argument

Först och främst är problemet med att hantera mellanslag i argument INTE faktiskt ett Java-problem. Det är snarare ett problem som måste hanteras av kommandoskalet som du använder när du kör ett Java-program.

Låt oss som exempel anta att vi har följande enkla program som skriver ut filstorleken:

import java.io.File;

public class PrintFileSizes {
    
    public static void main(String[] args) {
        for (String name: args) {
            File file = new File(name);
            System.out.println("Size of '" + file + "' is " + file.size());
        }
    }
}

Anta nu att vi vill skriva ut storleken på en fil vars söknamn har mellanslag i den; t.ex. /home/steve/Test File.txt . Om vi kör kommandot så här:

$ java PrintFileSizes /home/steve/Test File.txt

skalet vet inte att /home/steve/Test File.txt egentligen är ett söknamn. Istället kommer det att skicka två distinkta argument till Java-applikationen, som kommer att försöka hitta deras respektive filstorlekar och misslyckas eftersom filer med dessa sökvägar (förmodligen) inte finns.

Lösningar med ett POSIX-skal

POSIX skalen inkluderar sh samt derivat såsom bash och ksh . Om du använder en av dessa skal kan du lösa problemet genom att citera argumentet.

$ java PrintFileSizes "/home/steve/Test File.txt"

Dubbelcitationerna runt sökvägen säger skalet att det ska skickas som ett enda argument. Citat tas bort när detta händer. Det finns ett par andra sätt att göra detta:

$ java PrintFileSizes '/home/steve/Test File.txt'

Enstaka (raka) citat behandlas som dubbla citat förutom att de också undertrycker olika utvidgningar inom argumentet.

$ java PrintFileSizes /home/steve/Test\ File.txt

Ett backstopp undgår följande utrymme och gör att det inte tolkas som en argumentavskiljare.

För mer omfattande dokumentation, inklusive beskrivningar av hur man hanterar andra specialtecken i argument, hänvisar du till det citerande ämnet i Bash- dokumentationen.

Lösning för Windows

Det grundläggande problemet för Windows är att på OS-nivå överförs argumenten till en underordnad process som en enda sträng ( källa ). Detta innebär att det ultimata ansvaret för att analysera (eller analysera) kommandoraden faller på antingen program eller dess runtime-bibliotek. Det finns massor av inkonsekvens.

I Java-fallet, för att klippa en kort historia:

• Du kan lägga dubbelcitationstecken runt ett argument i ett java kommando, och det gör att du kan skicka argument med mellanslag i dem.

• Uppenbarligen analyserar själva java kommandot kommandosträngen, och det blir mer eller mindre rätt

• Men när du försöker kombinera detta med användning av SET och variabel substitution i en batchfil blir det riktigt komplicerat huruvida dubbla citat tas bort.

• cmd.exe skalet har uppenbarligen andra undkommande mekanismer; t.ex. att fördubbla dubbelcitationstecken och använda ^ flykt.

Mer information finns i dokumentationen för batchfil .

Java-alternativ

java kommandot stöder ett brett utbud av alternativ:

• Alla alternativ börjar med en enda bindestreck eller minustecken ( - ): GNU / Linux-konventionen om att använda -- för "långa" alternativ stöds inte.

• Alternativ måste visas före <classname> eller -jar <jarfile> -argumentet för att kunna identifieras. Eventuella argument efter dem kommer att behandlas som argument som ska skickas till den Java-app som körs.

• Alternativ som inte börjar med -X eller -XX är standardalternativ. Du kan lita på alla Java-implementationer ^{1 för} att stödja alla standardalternativ.

• Alternativ som börjar med -X är icke-standardalternativ och kan dras tillbaka från en Java-version till nästa.

• Alternativ som börjar med -XX är avancerade alternativ och kan också dras tillbaka.

Ställa in systemegenskaper med -D

-D<property>=<value> används för att ställa in en egenskap i objektets Properties . Denna parameter kan upprepas för att ställa in olika egenskaper.

Alternativ för minne, stack och sopor

De viktigaste alternativen för att kontrollera högen och stackstorlekarna dokumenteras i Ställa in högen, PermGen och Stack-storlekarna . (Redaktionell anmärkning: Alternativ för avfallssamlare ska beskrivas i samma ämne.)

Aktivera och inaktivera påståenden

-ea respektive -da aktiverar och inaktiverar Java- assert :

• All påstående kontroll är inaktiverad som standard.
• -ea möjligt att kontrollera alla påståenden
• Den -ea:<packagename>... möjligt att kontrollera påståenden i ett paket och alla underpaket .
• Den -ea:<classname>... möjligt att kontrollera påståenden i en klass.
• Alternativet -da inaktiverar kontroll av alla påståenden
• The -da:<packagename>... inaktiverar kontroll av påståenden i ett paket och alla underpaket .
• -da:<classname>... inaktiverar kontroll av påståenden i en klass.
• -esa möjligt att kontrollera efter alla systemklasser.
• -dsa inaktiverar kontrollen för alla systemklasser.

Alternativen kan kombineras. Till exempel.

$ # Enable all assertion checking in non-system classes 
$ java -ea -dsa MyApp

$ # Enable assertions for all classes in a package except for one.
$ java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat MyApp

Observera att aktivering av en Java-programmering kan förändra beteendet hos en Java-programmering.

• Det är ansvarigt att ansökan blir långsammare i allmänhet.
• Det kan leda till att specifika metoder tar längre tid att köra, vilket kan ändra tidpunkten för trådar i en flertrådad applikation.
• Det kan införa serendipitösa händelser innan förhållanden som kan orsaka minnesavvikelser att försvinna.
• En felaktigt genomfört assert uttalande kan ha oönskade bieffekter.

Välja VM-typ

-client och -server låter dig välja mellan två olika former av HotSpot VM:

• Formuläret "klient" är inställt för användarapplikationer och erbjuder snabbare start.
• Formuläret "server" är inställt för applikationer med lång drift. Det tar längre tid att fånga statistik under JVM-uppvärmningen, vilket gör att JIT-kompilatorn kan göra ett bättre jobb med att optimera den inbyggda koden.

Som standard körs JVM i 64bit-läge om möjligt, beroende på plattformens funktioner. -d32 och -d64 låter dig välja läget uttryckligen.

^{1 - Kontrollera den officiella manualen för java kommandot. Ibland beskrivs ett standardalternativ som "kan ändras".}