نام (NAME)

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

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

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

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

options

گزینه‌های خط فرمان. بخش «گزینه‌ها» را ببینید.

sourcefiles

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

classes

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

@argfiles

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

توضیحات (DESCRIPTION)

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

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

•

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

•

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

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

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

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

به‌طور پیش‌فرض، کامپایلر هر فایل کلاس را در همان دایرکتوری فایل مبدأ آن قرار می‌دهد. شما می‌توانید با استفاده از گزینهٔ -d یک دایرکتوری مقصد مجزا مشخص کنید..SH "گزینه‌ها (OPTIONS)" کامپایلر مجموعه‌ای از گزینه‌های استاندارد دارد که در محیط توسعه کنونی پشتیبانی می‌شوند. مجموعه دیگری از گزینه‌های غیراستاندارد وجود دارند که مختص پیاده‌سازی‌های کنونی ماشین مجازی و کامپایلر هستند و ممکن است در آینده تغییر کنند. گزینه‌های غیراستاندارد با گزینه -X آغاز می‌شوند.

•

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

•

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

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

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

cast

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

String s = (String) "Hello!"

classfile

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

deprecation

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

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 deprecatedMethood() { }

public static void newMethod() { }

divzero

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

int divideByZero = 42 / 0;

empty

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

class E {

    void m() {

         if (true) ;

    }

}

fallthrough

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

switch (x) {

case 1:

  System.out.println("1");

  // No break statement here.

case 2:

  System.out.println("2");

}

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

finally

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

public static int m() {

  try {

     throw new NullPointerException();

  }  catch (NullPointerException(); {

     System.err.println("Caught NullPointerException.");

     return 1;

   } finally {

     return 0;

   }

  }

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

options

درباره مسائل مربوط به استفاده از گزینه‌های خط فرمان هشدار می‌دهد. بخش Cross-Compilation Options را ببینید.

overrides

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

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، کامپایلر پارامتر صوری varargs به صورت String... s را به پارامتر صوری String[] s، یعنی یک آرایه ترجمه می‌کند که با پارامتر صوری متد ClassWithOverridingMethod.varargsMethod مطابقت دارد. در نتیجه، این مثال کامپایل می‌شود.

path

درباره مؤلفه‌های نامعتبر مسیر و دایرکتوری‌های ناموجود مسیر در خط فرمان (با توجه به مسیر کلاس (class path)، مسیر مبدا (source path) و سایر مسیرها) هشدار می‌دهد. چنین هشدارهایی را نمی‌توان با استفاده از یادداشت @SuppressWarnings نادیده گرفت، برای مثال:

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

processing

درباره مسائل مربوط به پردازش یادداشت‌ها (annotation processing) هشدار می‌دهد. کامپایلر این هشدار را زمانی صادر می‌کند که کلاسی دارای یک یادداشت باشد و از پردازشگر یادداشتی استفاده کنید که نمی‌تواند آن نوع استثنا را پردازش کند. برای مثال، کد زیر یک پردازشگر یادداشت ساده است:

فایل مبدا AnnocProc.java:

import java.util.*;

import javax.annotation.processing.*;

import javax.lang.model.*;

import.javaz.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 یک نوع خام (raw type) است. با این حال، List<?> یک نوع پارامتری‌شده با نویسه عام نامحدود (unbounded wildcard parameterized type) است. از آنجا که List یک رابط (interface) پارامتری‌شده است، همیشه آرگومان نوع آن را مشخص کنید. در این مثال، آرگومان صوری 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 را بر اساس جنبه‌های مختلف کلاس، همان‌طور که در Java Object Serialization Specification شرح داده شده است، برای آن کلاس محاسبه می‌کند. با این حال، اکیداً توصیه می‌شود که همه کلاس‌های قابل سریال‌سازی مقادیر serialVersionUID را به طور صریح اعلان کنند، زیرا فرایند پیش‌فرض محاسبه مقادیر serialVersionUID به شدت به جزئیات کلاس وابسته است که می‌تواند بسته به پیاده‌سازی‌های کامپایلر متفاوت باشد، و در نتیجه ممکن است باعث ایجاد یک InvalidClassExceptions غیرمنتظره در حین دیسریال‌سازی شود. برای تضمین یک مقدار serialVersionUID سازگار در بین پیاده‌سازی‌های مختلف کامپایلر Java، یک کلاس قابل سریال‌سازی باید یک مقدار صریح برای serialVersionUID اعلان کند.

static

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

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

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

XLintStatic.m1();

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

try

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

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

unchecked

جزئیات بیشتری درباره هشدارهای تبدیل بررسی‌نشده (unchecked conversion warnings) که توسط Java Language Specification الزامی شده‌اند ارائه می‌دهد، برای مثال:

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 warning) تولید می‌کند. در زمان کامپایل، کامپایلر و JVM نمی‌توانند تشخیص دهند که آیا l به نوع List<String> ارجاع دارد یا خیر. در این حالت، l به نوع List<String> ارجاع ندارد. در نتیجه، آلودگی هیپ (heap pollution) رخ می‌دهد.

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

varargs

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

public class ArrayBuilder {

  public static <T> void addToList (List<T> listArg, T... elements) {

    for (T x : elements) {

      listArg.add(x);

  }

}

نکته: یک نوع غیرقابل بازنمایی (non-reifiable)، نوعی است که اطلاعات نوع آن در زمان اجرا به طور کامل در دسترس نیست.

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

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

هنگامی که کامپایلر با یک متد varargs مواجه می‌شود، پارامتر رسمی varargs را به یک آرایه ترجمه می‌کند. با این حال، زبان برنامه‌نویسی Java ساخت آرایه‌هایی از نوع‌های پارامتری (parameterized types) را مجاز نمی‌داند. در متد ArrayBuilder.addToList، کامپایلر پارامتر رسمی varargs با عنوان T... elements را به پارامتر رسمی T[] elements، که یک آرایه است، ترجمه می‌کند. با این وجود، به دلیل پاک‌سازی نوع (type erasure)، کامپایلر پارامتر رسمی varargs را به Object[] elements تبدیل می‌نماید. در نتیجه، امکان آلودگی هیپ (heap pollution) وجود دارد.

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

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

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

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

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

مثال ۱: تک‌فایل آرگومان (Example 1 Single Argument File)

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

javac @argfile

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

مثال ۲: دو فایل آرگومان (Example 2 Two Argument Files)

می‌توانید دو فایل آرگومان بسازید: یکی برای گزینه‌های 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

مثال ۳: فایل‌های آرگومان دارای مسیر (Example 3 Argument Files with Paths)

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

javac @path1/options @path2/classes

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

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

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

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

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

اگر گزینه -sourcepath را تنظیم کنید، کامپایلر مسیر مشخص‌شده را برای یافتن فایل‌های مبدأ جستجو می‌کند. در غیر این صورت، کامپایلر مسیر کلاس کاربر را هم برای فایل‌های کلاس و هم برای فایل‌های مبدأ بررسی می‌کند.

می‌توانید کلاس‌های راه‌اندازی یا الحاقی متفاوتی را با گزینه‌های -bootclasspath و -extdirs تعیین کنید. به «گزینه‌های همگردانی متقابل (Cross-Compilation Options)» مراجعه کنید.

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

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

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

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

دستور javac از رابط برنامه‌نویسی جدید کامپایلر جاوا (Java Compiler 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 را تغییر دهید تا از یک ابزار اعلان (banner utility) استفاده کند، آنگاه آن ابزار نیز باید از طریق مسیر کلاس کاربر قابل دسترسی باشد. 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 مشخص می‌کند که برای کامپایل OldCode.java از نگارش 1.7 (یا 7) زبان برنامه‌نویسی جاوا استفاده شود. گزینهٔ -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 مشخص می‌کند که برای کامپایل OldCode.java از نگارش 1.7 (یا 7) زبان برنامه‌نویسی جاوا استفاده شود. گزینهٔ -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

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

•

java(1)

•

jdb(1)

•

javah(1)

•

javadoc(1)

•

jar(1)

•

jdb(1)