نام (NAME)

javac - تعاریف کلاس‌ها و رابط‌های جاوا را می‌خواند و آن‌ها را به بایت‌کد و فایل‌های کلاس کامپایل می‌کند

خلاصه دستور (SYNOPSIS)

javac [ options ] [ sourcefiles ] [ classes] [ @argfiles ]

آرگومان‌ها می‌توانند به هر ترتیبی قرار گیرند:

options

گزینه‌های خط فرمان؛ بخش گزینه‌ها (OPTIONS) را ببینید.

sourcefiles

یک یا چند فایل منبع برای کامپایل شدن (مانند MyClass.java).

classes

یک یا چند کلاس برای پردازش حاشیه‌نویسی (مانند MyPackage.MyClass).

@argfiles

یک یا چند فایل حاوی فهرست گزینه‌ها و فایل‌های منبع. گزینه‌های -J در این فایل‌ها مجاز نیستند؛ بخش فایل‌های آرگومان خط فرمان را ببینید.

توضیحات (DESCRIPTION)

دستور javac تعاریف کلاس‌ها و رابط‌ها را که به زبان برنامه‌نویسی جاوا نوشته شده‌اند می‌خواند و آن‌ها را به فایل‌های کلاس بایت‌کد کامپایل می‌کند. دستور javac همچنین می‌تواند حاشیه‌نویسی‌ها (annotations) را در فایل‌های منبع و کلاس‌های جاوا پردازش کند.

دو روش برای ارسال نام فایل‌های کد منبع به javac وجود دارد:

•

برای تعداد کمی از فایل‌های منبع، نام فایل‌ها را در خط فرمان فهرست کنید.

•

برای تعداد زیادی از فایل‌های منبع، نام فایل‌ها را در فایلی فهرست کنید که نام‌ها با فاصله یا شکست خط از هم جدا شده باشند. نام فایل فهرست را با پیشوند علامت اَت (@) همراه با دستور javac به کار ببرید.

نام فایل‌های کد منبع باید دارای پسوند .java و نام فایل‌های کلاس باید دارای پسوند .class باشند و هر دو فایل منبع و کلاس باید نام ریشه‌ای متناظر با کلاس داشته باشند. برای مثال، کلاسی به نام MyClass در یک فایل منبع به نام MyClass.java نوشته شده و به یک فایل کلاس بایت‌کد به نام MyClass.class کامپایل می‌شود.

تعاریف کلاس‌های داخلی فایل‌های کلاس اضافی تولید می‌کنند. این فایل‌های کلاس دارای نام‌هایی هستند که نام کلاس درونی و بیرونی را ترکیب می‌کند، مانند MyClass$MyInnerClass.class.

فایل‌های منبع را در یک ساختار درختی دایرکتوری مرتب کنید که بازتاب‌دهنده درخت بسته (package) آن‌ها باشد. برای نمونه، اگر همه فایل‌های منبع شما در /workspace قرار دارند، کد منبع مربوط به com.mysoft.mypack.MyClass را در /workspace/com/mysoft/mypack/MyClass.java قرار دهید.

به‌طور پیش‌فرض، کامپایلر هر فایل کلاس را در همان دایرکتوری فایل منبع مربوطه قرار می‌دهد. می‌توانید با گزینه -d یک دایرکتوری مقصد جداگانه تعیین کنید.

گزینه‌ها (OPTIONS)

کامپایلر دارای مجموعه‌ای از گزینه‌های استاندارد است که در محیط توسعه جاری پشتیبانی می‌شوند. مجموعه‌ای اضافی از گزینه‌های غیراستاندارد نیز وجود دارد که مختص ماشین مجازی جاری و پیاده‌سازی‌های کامپایلر هستند و ممکن است در آینده دستخوش تغییر شوند. گزینه‌های غیراستاندارد با پیشوند -X آغاز می‌شوند.

•

همچنین بخش «گزینه‌های کامپایل متقابل (Cross-Compilation Options)» را ببینید

•

همچنین بخش «گزینه‌های غیراستاندارد (Nonstandard Options)» را ببینید

فعال یا غیرفعال کردن هشدارها با گزینه -XLINT (ENABLE OR DISABLE WARNINGS WITH THE -XLINT OPTION)

هشدار name را با گزینه -Xlint:name فعال کنید، که در آن name یکی از نام‌های هشدار زیر است. توجه داشته باشید که می‌توانید یک هشدار را با گزینه -Xlint:-name غیرفعال کنید.

cast

درباره تبدیل نوع‌های (cast) غیرضروری و اضافی هشدار می‌دهد، برای مثال:

String s = (String) "Hello!"

classfile

درباره مسائل مربوط به محتویات فایل کلاس هشدار می‌دهد.

deprecation

درباره استفاده از موارد منسوخ‌شده هشدار می‌دهد، برای مثال:

java.util.Date myDate = new java.util.Date();
int currentDay = myDate.getDay();

متد java.util.Date.getDay از زمان JDK 1.1 منسوخ شده است.

dep-ann

درباره مواردی که با کامنت Javadoc حاوی @deprecated مستند شده‌اند اما فاقد حاشیه‌نویسی @Deprecated هستند هشدار می‌دهد، برای مثال:

/**
  * @deprecated As of Java SE 7, replaced by {@link #newMethod()}
  */
public static void deprecatedMethod() { }
public static void newMethod() { }

divzero

درباره تقسیم بر عدد صحیح ثابت 0 هشدار می‌دهد، برای مثال:

int divideByZero = 42 / 0;

empty

درباره دستورات خالی پس از دستورات if هشدار می‌دهد، برای مثال:

class E {
    void m() {
         if (true) ;
    }
}

fallthrough

بلوک‌های switch را برای حالت‌های افتادن (fall-through) بررسی می‌کند و در صورت وجود هشدار می‌دهد. حالت‌های fall-through مواردی در یک بلوک switch به جز آخرین مورد هستند که کد آن‌ها شامل دستور break نیست و اجازه می‌دهد اجرای کد از آن حالت به حالت بعدی بیفتد. برای مثال، کد پس از برچسب case 1 در این بلوک switch با دستور break پایان نمی‌یابد:

switch (x) {
case 1:
  System.out.println("1");
  // No break statement here.
case 2:
  System.out.println("2");
}

اگر هنگام کامپایل این کد از گزینه -Xlint:fallthrough استفاده شده باشد، کامپایلر هشداری درباره افتادن احتمالی به case همراه با شماره خط مورد نظر صادر می‌کند.

finally

درباره بندهای finally که نمی‌توانند به‌طور عادی خاتمه یابند هشدار می‌دهد، برای مثال:

public static int m() {
  try {
     throw new NullPointerException();
  }  catch (NullPointerException e) {
     System.err.println("Caught NullPointerException.");
     return 1;
   } finally {
     return 0;
   }
  }

کامپایلر برای بلوک finally در این مثال هشدار تولید می‌کند. هنگام فراخوانی متد int، مقدار 0 برگردانده می‌شود. بلوک finally هنگام خروج از بلوک try اجرا می‌شود. در این مثال، هنگامی که کنترل به بلوک catch منتقل می‌شود، متد خارج می‌شود؛ با این حال، بلوک finally باید اجرا شود، بنابراین حتی اگر کنترل به خارج از متد منتقل شده باشد، اجرا می‌گردد.

options

درباره مسائل مربوط به استفاده از گزینه‌های خط فرمان هشدار می‌دهد. بخش «گزینه‌های کامپایل متقابل» را ببینید.

overrides

درباره مسائل مربوط به بازنویسی (override) متدها هشدار می‌دهد. برای نمونه، دو کلاس زیر را در نظر بگیرید:

public class ClassWithVarargsMethod {
  void varargsMethod(String... s) { }
}
public class ClassWithOverridingMethod extends ClassWithVarargsMethod {
   @Override
   void varargsMethod(String[] s) { }
}

کامپایلر هشداری مشابه زیر تولید می‌کند:

warning: [override] varargsMethod(String[]) in ClassWithOverridingMethod 
overrides varargsMethod(String...) in ClassWithVarargsMethod; overriding
method is missing '...'

هنگامی که کامپایلر با یک متد varargs روبرو می‌شود، پارامتر رسمی varargs را به یک آرایه تبدیل می‌کند. در متد ClassWithVarargsMethod.varargsMethod، کامپایلر پارامتر رسمی String... s را به پارامتر رسمی String[] s تبدیل می‌کند که با پارامتر رسمی متد ClassWithOverridingMethod.varargsMethod مطابقت دارد. در نتیجه این مثال کامپایل می‌شود.

path

درباره عناصر نامعتبر و دایرکتوری‌های ناموجود در مسیرهای خط فرمان (مسیر کلاس، مسیر منبع و سایر مسیرها) هشدار می‌دهد. چنین هشدارهایی را نمی‌توان با حاشیه‌نویسی @SuppressWarnings سرکوب کرد، برای مثال:

javac -Xlint:path -classpath /nonexistentpath Example.java

processing

درباره مسائل مربوط به پردازش حاشیه‌نویسی هشدار می‌دهد. کامپایلر این هشدار را زمانی تولید می‌کند که کلاسی دارای حاشیه‌نویسی باشد و از یک پردازنده حاشیه‌نویسی استفاده کنید که نمی‌تواند آن استثنا یا حاشیه‌نویسی را مدیریت کند. برای نمونه، پردازنده حاشیه‌نویسی ساده زیر را در نظر بگیرید:

فایل منبع AnnoProc.java:

import java.util.*;
import javax.annotation.processing.*;
import javax.lang.model.*;
import javax.lang.model.element.*;
@SupportedAnnotationTypes("NotAnno")
public class AnnoProc extends AbstractProcessor {
  public boolean process(Set<? extends TypeElement> elems, RoundEnvironment renv){
     return true;
  }
  public SourceVersion getSupportedSourceVersion() {
     return SourceVersion.latest();
   }
}

فایل منبع AnnosWithoutProcessors.java:

@interface Anno { }
@Anno
class AnnosWithoutProcessors { }

دستورات زیر ابتدا پردازنده حاشیه‌نویسی AnnoProc را کامپایل می‌کنند و سپس آن را در برابر فایل منبع AnnosWithoutProcessors.java اجرا می‌کنند:

javac AnnoProc.java
javac -cp . -Xlint:processing -processor AnnoProc -proc:only AnnosWithoutProcessors.java

هنگامی که کامپایلر پردازنده حاشیه‌نویسی را در برابر فایل منبع AnnosWithoutProcessors.java اجرا می‌کند، هشدار زیر را تولید می‌کند:

warning: [processing] No processor claimed any of these annotations: Anno

برای حل این مشکل، می‌توانید حاشیه‌نویسی تعریف‌شده و استفاده‌شده در کلاس AnnosWithoutProcessors را از Anno به NotAnno تغییر نام دهید.

rawtypes

درباره عملیات کنترل‌نشده روی نوع‌های خام (raw types) هشدار می‌دهد. عبارت زیر یک هشدار rawtypes ایجاد می‌کند:

void countElements(List l) { ... }

مثال زیر هشدار rawtypes ایجاد نمی‌کند:

void countElements(List<?> l) { ... }

نوع List یک نوع خام است؛ در حالی که List<?> یک نوع پارامتری‌شده با نویسه عام نامحدود (unbounded wildcard) است. از آنجا که List یک رابط پارامتری‌شده است، همیشه آرگومان نوع آن را مشخص کنید. در این مثال، آرگومان رسمی List با یک نویسه عام نامحدود (?) به عنوان پارامتر نوع رسمی تعیین شده است، به این معنی که متد countElements می‌تواند هر نمونه‌سازی از رابط List را بپذیرد.

serial

درباره تعاریف مفقود serialVersionUID در کلاس‌های قابل سریال‌سازی (serializable) هشدار می‌دهد، برای مثال:

public class PersistentTime implements Serializable
{
  private Date time;
   public PersistentTime() {
     time = Calendar.getInstance().getTime();
   }
   public Date getTime() {
     return time;
   }
}

کامپایلر هشدار زیر را تولید می‌کند:

warning: [serial] serializable class PersistentTime has no definition of
serialVersionUID

اگر یک کلاس قابل سریال‌سازی صراحتاً فیلدی به نام serialVersionUID تعریف نکند، محیط زمان اجرای سریال‌سازی بر اساس جنبه‌های مختلف کلاس، یک مقدار پیش‌فرض serialVersionUID برای آن محاسبه می‌کند، همان‌طور که در مشخصات سریال‌سازی اشیاء جاوا شرح داده شده است. با این حال، اکیداً توصیه می‌شود که همه کلاس‌های قابل سریال‌سازی صراحتاً مقادیر serialVersionUID را اعلام کنند، زیرا فرآیند پیش‌فرض محاسبه آن به شدت به جزئیات کلاس وابسته است که می‌تواند بر اساس پیاده‌سازی‌های کامپایلر متفاوت باشد و در نتیجه ممکن است منجر به خطای غیرمنتظره InvalidClassExceptions در حین واچینی (deserialization) شود.

static

درباره مسائل مربوط به استفاده از موارد ایستا (static) هشدار می‌دهد، برای مثال:

class XLintStatic {
    static void m1() { }
    void m2() { this.m1(); }
}

کامپایلر هشدار زیر را تولید می‌کند:

warning: [static] static method should be qualified by type name, 
XLintStatic, instead of by an expression

برای حل این مشکل، می‌توانید متد ایستای m1 را به صورت زیر فراخوانی کنید:

XLintStatic.m1();

یا اینکه می‌توانید کلمه کلیدی static را از اعلان متد m1 حذف کنید.

try

درباره مسائل مربوط به استفاده از بلوک‌های try، از جمله دستورات try-with-resources هشدار می‌دهد. برای نمونه، در عبارت زیر هشدار ایجاد می‌شود زیرا منبع ac تعریف‌شده در بلوک try استفاده نشده است:

try ( AutoCloseable ac = getResource() ) {    // do nothing}

unchecked

جزئیات بیشتری را برای هشدارهای تبدیل نوع کنترل‌نشده (unchecked conversion) که طبق مشخصات زبان جاوا الزامی است ارائه می‌دهد، برای مثال:

List l = new ArrayList<Number>();
List<String> ls = l;       // unchecked warning

در طول پاک‌سازی نوع (type erasure)، نوع‌های ArrayList<Number> و List<String> به ترتیب به ArrayList و List تبدیل می‌شوند. متغیر ls دارای نوع پارامتری‌شده List<String> است. هنگامی که شیء List مورد ارجاع توسط l به ls منتسب می‌شود، کامپایلر یک هشدار unchecked صادر می‌کند. در زمان کامپایل، کامپایلر و JVM نمی‌توانند تشخیص دهند که آیا l به نوع List<String> ارجاع دارد یا خیر. در نتیجه، وضعیت آلودگی هیپ (heap pollution) رخ می‌دهد.

آلودگی هیپ زمانی اتفاق می‌افتد که شیء l از نوع List با نوع ایستا List<Number>، به شیء دیگری ls با نوع ایستای متفاوت List<String> منتسب شود. با این حال، کامپایلر همچنان این انتساب را مجاز می‌داند تا سازگاری رو به عقب با نگارش‌های فاقد پشتیبانی از جنریک‌ها در Java SE حفظ شود. به دلیل پاک‌سازی نوع، هر دو نوع به List تبدیل می‌شوند و کامپایلر انتساب را مجاز می‌شمارد.

varargs

درباره استفاده‌های ناامن از متدهای با تعداد آرگومان متغیر (varargs)، به‌ویژه آن‌هایی که حاوی آرگومان‌های غیرقابل‌تحقق (non-reifiable) هستند هشدار می‌دهد، برای مثال:

public class ArrayBuilder {
  public static <T> void addToList (List<T> listArg, T... elements) {
    for (T x : elements) {
      listArg.add(x);
    }
  }
}

نکته: نوع غیرقابل‌تحقق نوعی است که اطلاعات نوع آن در زمان اجرا کاملاً در دسترس نیست.

کامپایلر برای تعریف متد ArrayBuilder.addToList هشدار زیر را تولید می‌کند:

warning: [varargs] Possible heap pollution from parameterized vararg type T

هنگامی که کامپایلر با یک متد varargs مواجه می‌شود، پارامتر رسمی varargs را به یک آرایه تبدیل می‌کند. با این حال، زبان جاوا ایجاد آرایه‌هایی از نوع‌های پارامتری‌شده را مجاز نمی‌داند. در متد ArrayBuilder.addToList، کامپایلر پارامتر رسمی T... را به آرایه T[] تبدیل می‌کند؛ اما به دلیل پاک‌سازی نوع، کامپایلر آن را به Object[] تبدیل می‌کند و در نتیجه احتمال آلودگی هیپ به وجود می‌آید.

فایل‌های آرگومان خط فرمان (COMMAND-LINE ARGUMENT FILES)

برای کوتاه‌کردن یا ساده‌سازی دستور javac، می‌توانید یک یا چند فایل حاوی آرگومان‌های دستور javac (به‌جز گزینه‌های -J) را مشخص کنید. این امکان به شما اجازه می‌دهد دستورات javac با هر طولی را روی هر سیستم‌عاملی ایجاد کنید.

یک فایل آرگومان می‌تواند شامل گزینه‌های javac و نام فایل‌های منبع در هر ترکیبی باشد. آرگومان‌های درون فایل را می‌توان با فاصله یا نویسه‌های خط جدید جدا کرد. اگر نام فایلی حاوی فاصله‌های درونی است، کل نام فایل را درون علامت نقل‌قول دوتایی قرار دهید.

نام فایل‌های درون یک فایل آرگومان نسبت به دایرکتوری جاری سنجیده می‌شوند، نه نسبت به مکان فایل آرگومان. نویسه‌های عام (*) در این فهرست‌ها مجاز نیستند (مانند تعیین *.java). استفاده از علامت اَت (@) برای تفسیر بازگشتی فایل‌ها پشتیبانی نمی‌شود. گزینه‌های -J پشتیبانی نمی‌شوند زیرا به راه‌انداز ارسال می‌شوند که از فایل‌های آرگومان پشتیبانی نمی‌کند.

هنگام اجرای دستور javac، مسیر و نام هر فایل آرگومان را با پیشوند علامت اَت (@) ارسال کنید. هنگامی که دستور javac با آرگومانی مواجه می‌شود که با علامت اَت (@) شروع می‌شود، محتویات آن فایل را در فهرست آرگومان‌ها باز می‌کند.

مثال ۱: فایل آرگومان تکی

می‌توانید از یک فایل آرگومان تکی به نام argfile برای نگهداری تمام آرگومان‌های javac استفاده کنید:

javac @argfile

این فایل آرگومان می‌تواند شامل محتویات هر دو فایل نشان‌داده‌شده در مثال ۲ باشد.

مثال ۲: دو فایل آرگومان

می‌توانید دو فایل آرگومان ایجاد کنید: یکی برای گزینه‌های javac و دیگری برای نام فایل‌های منبع. توجه داشته باشید که فهرست‌های زیر فاقد نویسه‌های ادامه‌دهنده خط هستند.

فایلی به نام options ایجاد کنید که شامل موارد زیر باشد:

-d classes
-g
-sourcepath /java/pubs/ws/1.3/src/share/classes

فایلی به نام classes ایجاد کنید که شامل موارد زیر باشد:

MyClass1.java
MyClass2.java
MyClass3.java

سپس دستور javac را به صورت زیر اجرا کنید:

javac @options @classes

مثال ۳: فایل‌های آرگومان دارای مسیر

فایل‌های آرگومان می‌توانند مسیر داشته باشند، اما هر نام فایلی درون آن‌ها نسبت به دایرکتوری کاری جاری سنجیده می‌شود (نه نسبت به path1 یا path2):

javac @path1/options @path2/classes

پردازش حاشیه‌نویسی (ANNOTATION PROCESSING)

دستور javac پشتیبانی مستقیمی از پردازش حاشیه‌نویسی فراهم می‌کند و نیاز به دستور مجزای پردازش حاشیه‌نویسی apt را برطرف می‌سازد.

واسط برنامه‌نویسی (API) پردازنده‌های حاشیه‌نویسی در بسته‌ها و زیربسته‌های javax.annotation.processing و javax.lang.model تعریف شده است.

جستجو برای انواع (SEARCHING FOR TYPES)

برای کامپایل یک فایل منبع، کامپایلر اغلب نیاز به اطلاعاتی درباره یک نوع (type) دارد که تعریف آن در فایل‌های منبع مشخص‌شده در خط فرمان موجود نیست. کامپایلر به اطلاعات نوع برای هر کلاس یا رابطی که در فایل منبع استفاده، گسترش (extend) یا پیاده‌سازی (implement) شده است نیاز دارد. این شامل کلاس‌ها و رابط‌هایی که صراحتاً در فایل منبع ذکر نشده‌اند اما اطلاعات را از طریق وراثت فراهم می‌کنند نیز می‌شود.

برای نمونه، هنگامی که زیرکلاسی از java.applet.Applet ایجاد می‌کنید، از کلاس‌های والد آن یعنی java.awt.Panel، java.awt.Container، java.awt.Component و java.lang.Object نیز استفاده می‌کنید.

هنگامی که کامپایلر به اطلاعات نوع نیاز دارد، به دنبال فایل منبع یا فایل کلاسی می‌گردد که آن نوع را تعریف می‌کند. کامپایلر ابتدا در کلاس‌های بوت‌استرپ و افزونه‌ها و سپس در مسیر کلاس کاربر (که به‌طور پیش‌فرض دایرکتوری جاری است) جستجو می‌کند. مسیر کلاس کاربر با تنظیم متغیر محیطی CLASSPATH یا با استفاده از گزینه -classpath تعیین می‌شود.

اگر گزینه -sourcepath را تنظیم کنید، کامپایلر مسیر указаشده را برای فایل‌های منبع جستجو می‌کند؛ در غیر این صورت، مسیر کلاس کاربر را برای هر دو فایل کلاس و فایل‌های منبع جستجو می‌کند.

می‌توانید کلاس‌های بوت‌استرپ یا افزونه متفاوت را با گزینه‌های -bootclasspath و -extdirs تعیین کنید. بخش «گزینه‌های کامپایل متقابل» را ببینید.

یک جستجوی موفق نوع ممکن است یک فایل کلاس، یک فایل منبع یا هر دو را تولید کند. اگر هر دو یافت شوند، می‌توانید با گزینه -Xprefer به کامپایلر بگویید کدام‌یک را استفاده کند. اگر newer مشخص شود، فایل جدیدتر انتخاب می‌شود (پیش‌فرض). اگر source مشخص شود، فایل منبع استفاده می‌شود.

اگر جستجوی نوع یک فایل منبع پیدا کند، کامپایلر فایل منبع را برای دریافت اطلاعات مورد نیازش می‌خواند. به‌طور پیش‌فرض کامپایلر آن فایل منبع را نیز کامپایل می‌کند. با گزینه -implicit می‌توانید رفتار آن را تنظیم کنید: با none هیچ فایل کلاسی تولید نمی‌شود و با class فایل‌های کلاس تولید می‌شوند.

ممکن است کامپایلر نیاز به برخی اطلاعات نوع را تا پس از تکمیل پردازش حاشیه‌نویسی تشخیص ندهد. هنگامی که اطلاعات نوع در یک فایل منبع یافت شود و گزینه -implicit تعیین نشده باشد، کامپایلر هشدار می‌دهد که فایل بدون قرار گرفتن تحت پردازش حاشیه‌نویسی در حال کامپایل است. برای غیرفعال کردن هشدار، فایل را در خط فرمان مشخص کنید یا از گزینه -implicit استفاده کنید.

رابط برنامه‌نویسی (PROGRAMMATIC INTERFACE)

دستور javac از API جدید کامپایلر جاوا که توسط کلاس‌ها و رابط‌های موجود در بسته javax.tools تعریف شده است پشتیبانی می‌کند.

JavaCompiler javac = ToolProvider.getSystemJavaCompiler();

public static int compile(String[] args);
public static int compile(String[] args, PrintWriter out);

مثال‌ها (EXAMPLES)

مثال ۱: کامپایل یک برنامه ساده

این مثال نحوه کامپایل فایل منبع Hello.java را در دایرکتوری greetings نشان می‌دهد. کلاس تعریف‌شده در Hello.java به نام greetings.Hello است. دایرکتوری greetings دایرکتوری بسته برای هر دو فایل منبع و فایل کلاس است و زیر دایرکتوری جاری قرار دارد. این امر استفاده از مسیر کلاس پیش‌فرض کاربر را امکان‌پذیر می‌سازد و نیازی به تعیین یک دایرکتوری مقصد جداگانه با گزینه -d ندارد.

کد منبع در Hello.java:

package greetings;
public class Hello {
    public static void main(String[] args) {
        for (int i=0; i < args.length; i++) {
            System.out.println("Hello " + args[i]);
        }
    }
}

کامپایل greetings.Hello:

javac greetings/Hello.java

اجرای greetings.Hello:

java greetings.Hello World Universe Everyone
Hello World
Hello Universe
Hello Everyone

مثال ۲: کامپایل چندین فایل منبع

این مثال فایل‌های منبع Aloha.java، GutenTag.java، Hello.java و Hi.java را در بسته greetings کامپایل می‌کند.

% javac greetings/*.java
% ls greetings
Aloha.class         GutenTag.class      Hello.class         Hi.class
Aloha.java          GutenTag.java       Hello.java          Hi.java

مثال ۳: تعیین مسیر کلاس کاربر

پس از تغییر یکی از فایل‌های منبع در مثال قبلی، آن را مجدداً کامپایل کنید:

pwd
/examples
javac greetings/Hi.java

از آنجا که greetings.Hi به کلاس‌های دیگر در بسته greetings ارجاع دارد، کامپایلر باید بتواند این کلاس‌های دیگر را پیدا کند. مثال قبلی به این دلیل کار می‌کند که مسیر پیش‌فرض کلاس کاربر همان دایرکتوری حاوی دایرکتوری بسته است. اگر می‌خواهید این فایل را بدون توجه به اینکه در کدام دایرکتوری قرار دارید مجدداً کامپایل کنید، دایرکتوری examples را با تنظیم CLASSPATH به مسیر کلاس کاربر اضافه کنید. این مثال از گزینه -classpath استفاده می‌کند:

javac -classpath /examples /examples/greetings/Hi.java

اگر greetings.Hi را طوری تغییر دهید که از یک ابزار بنر استفاده کند، آن ابزار نیز باید از طریق مسیر کلاس کاربر در دسترس باشد:

javac -classpath /examples:/lib/Banners.jar \
            /examples/greetings/Hi.java

برای اجرای یک کلاس در بسته greetings، برنامه نیاز به دسترسی به بسته greetings و کلاس‌هایی دارد که کلاس‌های greetings از آن‌ها استفاده می‌کنند:

java -classpath /examples:/lib/Banners.jar greetings.Hi

مثال ۴: تفکیک فایل‌های منبع و فایل‌های کلاس

مثال زیر از javac برای کامپایل کدی استفاده می‌کند که روی JVM 1.7 اجرا می‌شود:

javac -source 1.7 -target 1.7 -bootclasspath jdk1.7.0/lib/rt.jar \ 
-extdirs "" OldCode.java

گزینه -source 1.7 مشخص می‌کند که نگارش 1.7 (یا 7) زبان برنامه‌نویسی جاوا برای کامپایل OldCode.java استفاده شود. گزینه -target 1.7 تضمین می‌کند که فایل‌های کلاس تولیدشده با JVM 1.7 سازگار هستند. توجه داشته باشید که در بیشتر موارد، مقدار گزینه -target برابر با مقدار گزینه -source است؛ در این مثال می‌توانید گزینه -target را حذف کنید.

شما باید گزینه -bootclasspath را برای تعیین نگارش صحیح کلاس‌های بوت‌استرپ (کتابخانه rt.jar) مشخص کنید. در غیر این صورت کامپایلر یک هشدار تولید می‌کند:

javac -source 1.7 OldCode.java
warning: [options] bootstrap class path not set in conjunction with 
-source 1.7

اگر نگارش صحیح کلاس‌های بوت‌استرپ را مشخص نکنید، کامپایلر از قوانین زبان قدیمی (در این مثال نگارش 1.7 جاوا) همراه با کلاس‌های جدید بوت‌استرپ استفاده می‌کند که می‌تواند منجر به فایل‌های کلاسی شود که روی پلتفرم قدیمی‌تر (در این مورد Java SE 7) کار نکنند، زیرا ممکن است ارجاع به متدهای ناموجود در آن گنجانده شود.

مثال ۵: کامپایل متقابل

این مثال از javac برای کامپایل کدی استفاده می‌کند که روی JVM 1.7 اجرا می‌شود:

javac -source 1.7 -target 1.7 -bootclasspath jdk1.7.0/lib/rt.jar \
            -extdirs "" OldCode.java

گزینه -source 1.7 مشخص می‌کند که نگارش 1.7 (یا 7) زبان برنامه‌نویسی جاوا برای کامپایل OldCode.java استفاده شود. گزینه -target 1.7 تضمین می‌کند که فایل‌های کلاس تولیدشده با JVM 1.7 سازگار هستند.

شما باید گزینه -bootclasspath را برای تعیین نگارش صحیح کلاس‌های بوت‌استرپ (کتابخانه rt.jar) مشخص کنید؛ در غیر این صورت کامپایلر هشدار تولید می‌کند:

javac -source 1.7 OldCode.java
warning: [options] bootstrap class path not set in conjunction with -source 1.7

اگر نگارش صحیح کلاس‌های بوت‌استرپ را مشخص نکنید، کامپایلر از قوانین زبان قدیمی همراه با کلاس‌های بوت‌استرپ جدید استفاده می‌کند. این ترکیب می‌تواند منجر به تولید فایل‌های کلاسی شود که روی پلتفرم قدیمی‌تر کار نکنند زیرا ممکن است ارجاع به متدهای ناموجود در آن وارد شود. در این مثال، کامپایلر از نگارش 1.7 زبان جاوا استفاده می‌کند.

همچنین ببینید (SEE ALSO)

•

java(1)

•

jdb(1)

•

javadoc(1)

•

jar(1)

•

jdb(1)