.\" Automatically generated by Pandoc 3.10.2
.\"
.TH "JAVAC" "1" "2026" "JDK 26.0.2.1" "JDK Commands"
.SH "نام (NAME)"
javac \- کامپایلر رسمی زبان جاوا (نسخه ۲۶)
.SH "خلاصه دستور (SYNOPSIS)"
\f[CR]javac\f[R] [\f[I]گزینه‌ها\f[R]]
[\f[I]فایل‌های‌منبع\-یا\-نام‌های‌کلاس\f[R]]
.TP
\f[I]گزینه‌ها\f[R]
گزینه‌های خط فرمان.
.TP
\f[I]فایل‌های‌منبع\-یا\-نام‌های‌کلاس\f[R]
فایل‌های منبعی که باید کامپایل شوند (برای مثال، \f[CR]Shape.java\f[R]) یا نام کلاس‌های از پیش کامپایل‌شده برای پردازش حاشیه‌نویسی‌ها (برای مثال، \f[CR]geometry.MyShape\f[R]).
.SH "توضیحات (DESCRIPTION)"
دستور \f[CR]javac\f[R] فایل‌های منبع حاوی تعاریف ماژول، بسته و نوع نوشته‌شده به زبان برنامه‌نویسی جاوا را می‌خواند و آن‌ها را به \f[I]فایل‌های کلاس\f[R] که روی ماشین مجازی جاوا (JVM) اجرا می‌شوند، کامپایل می‌کند.
.PP
دستور \f[CR]javac\f[R] همچنین می‌تواند \f[B]حاشیه‌نویسی‌ها (annotations)\f[R] را در فایل‌های منبع و کلاس‌های جاوا پردازش کند.
.PP
فایل‌های منبع باید پسوند نام فایل \f[CR].java\f[R] داشته باشند.
فایل‌های کلاس دارای پسوند نام فایل \f[CR].class\f[R] هستند.
هر دو فایل منبع و کلاس معمولاً دارای نام‌هایی هستند که محتوای آن‌ها را مشخص می‌کند.
برای مثال، کلاسی به نام \f[CR]Shape\f[R] در یک فایل منبع به نام \f[CR]Shape.java\f[R] تعریف شده و به یک فایل کلاس به نام \f[CR]Shape.class\f[R] کامپایل می‌شود.
.PP
دو روش برای تعیین فایل‌های منبع برای \f[CR]javac\f[R] وجود دارد:
.IP \(bu 2
برای تعداد کمی از فایل‌های منبع، می‌توانید نام فایل‌های آن‌ها را مستقیماً در خط فرمان فهرست کنید.
.IP \(bu 2
برای تعداد زیادی از فایل‌های منبع، می‌توانید از گزینه
\f[B]\f[CB]\(at\f[B]\f[BI]filename\f[B]\f[R]
در خط فرمان برای تعیین یک \f[I]فایل آرگومان\f[R] که نام فایل‌ها در آن فهرست شده است، استفاده کنید.
برای توضیحات این گزینه به \f[B]گزینه‌های استاندارد\f[R] و برای توضیحات فایل‌های آرگومان \f[CR]javac\f[R] به بخش \f[B]فایل‌های آرگومان خط فرمان\f[R] مراجعه کنید.
.PP
ترتیب فایل‌های منبع تعیین‌شده در خط فرمان یا در فایل آرگومان اهمیتی ندارد.
دستور \f[CR]javac\f[R] فایل‌ها را با هم و به صورت یک گروه کامپایل می‌کند و به طور خودکار هرگونه وابستگی بین تعاریف موجود در فایل‌های منبع مختلف را حل‌وفصل می‌نماید.
.PP
دستور \f[CR]javac\f[R] انتظار دارد که فایل‌های منبع در یک یا چند ساختار سلسله‌مراتبی دایرکتوری روی سیستم فایل مرتب شده باشند، همان‌طور که در بخش \f[B]آرایش و ساختار کد منبع\f[R] شرح داده شده است.
.PP
برای کامپایل یک فایل منبع، \f[CR]javac\f[R] باید اعلان هر کلاس یا رابطی (interface) را که توسط کدهای درون فایل منبع استفاده، گسترش (extend) یا پیاده‌سازی (implement) شده است، پیدا کند.
این کار به \f[CR]javac\f[R] امکان می‌دهد بررسی کند که آیا کد دسترسی لازم به آن کلاس‌ها و رابط‌ها را دارد یا خیر.
به جای تعیین صریح فایل‌های منبع آن کلاس‌ها و رابط‌ها، می‌توانید از گزینه‌های خط فرمان استفاده کنید تا به \f[CR]javac\f[R] بگویید کجا به دنبال فایل‌های منبع آن‌ها بگردد.
اگر آن فایل‌های منبع را قبلاً کامپایل کرده‌اید، می‌توانید با استفاده از گزینه‌ها به \f[CR]javac\f[R] بگویید کجا به دنبال فایل‌های کلاس مربوطه بگردد.
این گزینه‌ها که همگی نام‌هایی با پسوند \(dqpath\(dq دارند، در بخش \f[B]گزینه‌های استاندارد\f[R] و همچنین در بخش‌های \f[B]پیکربندی کامپایل\f[R] و \f[B]جستجوی تعاریف ماژول، بسته و نوع\f[R] شرح داده شده‌اند.
.PP
به طور پیش‌فرض، \f[CR]javac\f[R] هر فایل منبع را به یک فایل کلاس در همان دایرکتوری فایل منبع کامپایل می‌کند.
با این حال، توصیه می‌شود با استفاده از گزینه
\f[B]\f[CB]\-d\f[B]\f[R]
یک دایرکتوری مقصد جداگانه تعیین کنید.
.PP
\f[B]گزینه‌های\f[R] خط فرمان و \f[B]متغیرهای محیطی\f[R] نیز نحوه انجام وظایف مختلف توسط \f[CR]javac\f[R] را کنترل می‌کنند:
.IP \(bu 2
کامپایل کد برای اجرا روی نگارش‌های قدیمی‌تر JDK.
.IP \(bu 2
کامپایل کد برای اجرا تحت دیباگر.
.IP \(bu 2
بررسی مسائل نگارشی و سبکی در کد منبع جاوا.
.IP \(bu 2
بررسی مشکلات موجود در کامنت‌های \f[CR]javadoc\f[R]
(\f[CR]/** ... */\f[R]).
.IP \(bu 2
پردازش حاشیه‌نویسی‌ها در فایل‌های منبع و فایل‌های کلاس.
.IP \(bu 2
ارتقا و وصله‌زدن ماژول‌ها در محیط زمان کامپایل.
.PP
دستور \f[CR]javac\f[R] از \f[B]کامپایل برای نگارش‌های قبلی پلتفرم\f[R] پشتیبانی می‌کند و همچنین می‌تواند از داخل کد جاوا با استفاده از چندین \f[B]رابط برنامه‌نویسی (API)\f[R] فراخوانی شود.
.SH "گزینه‌ها (OPTIONS)"
دستور \f[CR]javac\f[R] شامل \f[B]گزینه‌های استاندارد\f[R] و \f[B]گزینه‌های اضافی\f[R] است که یا غیراستاندارد هستند یا برای استفاده‌های پیشرفته در نظر گرفته شده‌اند.
.PP
برخی از گزینه‌ها یک یا چند آرگومان می‌پذیرند.
اگر آرگومانی حاوی فاصله یا نویسه‌های فاصله‌ساز دیگر باشد، مقدار آن باید بر اساس قواعد محیط مورد استفاده برای فراخوانی javac درون علامت نقل‌قول قرار گیرد.
اگر گزینه با یک خط تیره تکی (\f[CR]\-\f[R]) شروع شود، بسته به گزینه، آرگومان باید بلافاصله پس از نام گزینه بیاید، یا با دونقطه (\f[CR]:\f[R]) یا فاصله جدا شود.
اگر گزینه با دو خط تیره (\f[CR]\-\-\f[R]) شروع شود، آرگومان می‌تواند با فاصله یا با نویسه مساوی (\f[CR]=\f[R]) بدون هیچ فاصله اضافی جدا شود.
برای مثال:
.IP
.EX
\-Aname=\(dqJ. Duke\(dq
\-proc:only
\-d myDirectory
\-\-module\-version 3
\-\-module\-version=3
.EE
.PP
در فهرست‌های گزینه‌های زیر، آرگومان \f[I]path\f[R] نشان‌دهنده یک مسیر جستجو است که از فهرستی از مکان‌های سیستم فایل تشکیل شده و با نویسه جداکننده مسیر پلتفرم جدا می‌شوند (نقطه‌ویرگول \f[CR];\f[R] در ویندوز، یا دونقطه \f[CR]:\f[R] در سایر سیستم‌ها).
بسته به گزینه، مکان‌های سیستم فایل می‌توانند دایرکتوری‌ها، فایل‌های JAR یا فایل‌های JMOD باشند.
.SS "گزینه‌های استاندارد (Standard Options)"
.TP
\f[CR]\(at\f[R]\f[I]filename\f[R]
گزینه‌ها و نام فایل‌ها را از یک فایل می‌خواند.
برای کوتاه‌تر یا ساده‌تر کردن دستور \f[CR]javac\f[R]، می‌توانید یک یا چند فایل حاوی آرگومان‌های دستور \f[CR]javac\f[R] (به جز گزینه‌های \f[B]\f[CB]\-J\f[B]\f[R]) را مشخص کنید.
این کار به شما امکان می‌دهد در هر سیستم‌عاملی دستورات \f[CR]javac\f[R] با هر طولی بسازید.
بخش \f[B]فایل‌های آرگومان خط فرمان\f[R] را ببینید.
.TP
\f[CR]\-A\f[R]\f[I]key\f[R][\f[CR]=\f[R]\f[I]value\f[R]]
گزینه‌هایی را برای ارسال به پردازشگرهای حاشیه‌نویسی مشخص می‌کند.
این گزینه‌ها مستقیماً توسط \f[CR]javac\f[R] تفسیر نمی‌شوند، بلکه برای استفاده در اختیار تک‌تک پردازشگرها قرار می‌گیرند.
مقدار \f[I]key\f[R] باید یک یا چند شناسه باشد که با نقطه (\f[CR].\f[R]) جدا شده‌اند.
.TP
\f[CR]\-\-add\-modules\f[R] \f[I]module\f[R]\f[CR],\f[R]\f[I]module\f[R]
ماژول‌های ریشه را برای حل‌وفصل علاوه بر ماژول‌های اولیه، یا در صورت قرار دادن \f[CR]ALL\-MODULE\-PATH\f[R] برای \f[I]module\f[R]، تمام ماژول‌های موجود در مسیر ماژول را مشخص می‌کند.
.TP
\f[CR]\-\-boot\-class\-path\f[R] \f[I]path\f[R] یا \f[CR]\-bootclasspath\f[R] \f[I]path\f[R]
محل فایل‌های کلاس bootstrap را رونویسی (override) می‌کند.
.RS
\f[B]نکته:\f[R] این گزینه فقط در زمان کامپایل برای نگارش‌های پیش از JDK 9 قابل استفاده است.
برای جزئیات بیشتر به توضیحات \f[B]\f[CB]\-\-release\f[B]\f[R]، \f[B]\f[CB]\-source\f[B]\f[R] یا \f[B]\f[CB]\-target\f[B]\f[R] مراجعه کنید.
برای JDK 9 و جدیدتر، به \f[B]\f[CB]\-\-system\f[B]\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-\-class\-path\f[R] \f[I]path\f[R]، \f[CR]\-classpath\f[R] \f[I]path\f[R] یا \f[CR]\-cp\f[R] \f[I]path\f[R]
محل جستجو برای فایل‌های کلاس کاربر و پردازشگرهای حاشیه‌نویسی را مشخص می‌کند.
این مسیر کلاس جایگزین مسیر کلاس کاربر در متغیر محیطی \f[CR]CLASSPATH\f[R] می‌شود.
.RS
.IP \(bu 2
اگر گزینه‌های \f[CR]\-\-class\-path\f[R]، \f[CR]\-classpath\f[R] یا \f[CR]\-cp\f[R] تعیین نشده باشند، مسیر کلاس کاربر مقدار متغیر محیطی \f[CR]CLASSPATH\f[R] (در صورت تنظیم بودن) یا دایرکتوری جاری خواهد بود.
.IP \(bu 2
اگر کد برای ماژول‌ها کامپایل نمی‌شود و گزینه \f[B]\f[CB]\-\-source\-path\f[B]\f[R] یا \f[CR]\-sourcepath\f[R] تعیین نشده باشد، مسیر کلاس کاربر برای فایل‌های منبع نیز جستجو می‌شود.
.IP \(bu 2
اگر گزینه \f[B]\f[CB]\-processorpath\f[B]\f[R] تعیین نشده باشد، مسیر کلاس برای پردازشگرهای حاشیه‌نویسی نیز جستجو می‌شود.
.RE
.TP
\f[CR]\-d\f[R] \f[I]directory\f[R]
دایرکتوری مقصد (یا \f[I]دایرکتوری خروجی کلاس\f[R]) را برای فایل‌های کلاس تعیین می‌کند.
اگر کلاسی بخشی از یک بسته باشد، \f[CR]javac\f[R] فایل کلاس را در یک زیردایرکتوری متناسب با نام ماژول (در صورت وجود) و نام بسته قرار می‌دهد.
این دایرکتوری و زیردایرکتوری‌های لازم در صورت عدم وجود به طور خودکار ساخته خواهند شد.
.RS
اگر گزینه \f[CR]\-d\f[R] تعیین نشود، \f[CR]javac\f[R] هر فایل کلاس را در همان دایرکتوری فایل منبعی که از آن تولید شده است قرار می‌دهد.
به جز در مواردی که کد برای چندین ماژول کامپایل می‌شود، محتویات دایرکتوری خروجی کلاس در یک ساختار سلسله‌مراتبی بسته مرتب خواهند شد.
هنگام کامپایل کد برای چندین ماژول، محتویات دایرکتوری خروجی در یک سلسله‌مراتب ماژول سازمان‌دهی می‌شوند و محتویات هر ماژول در یک زیردایرکتوری جداگانه قرار می‌گیرد که هر کدام به صورت سلسله‌مراتب بسته سازمان‌دهی شده‌اند.
\f[B]نکته:\f[R] هنگام کامپایل کد برای یک یا چند ماژول، دایرکتوری خروجی کلاس به طور خودکار هنگام جستجو برای کلاس‌های از پیش کامپایل‌شده بررسی می‌شود.
هنگامی که برای ماژول‌ها کامپایل نمی‌کنید، برای سازگاری عقبروی، این دایرکتوری به طور خودکار برای کلاس‌های از پیش کامپایل‌شده بررسی \f[I]نمی‌شود\f[R]؛ بنابراین توصیه می‌شود دایرکتوری خروجی کلاس را به عنوان یکی از مکان‌های موجود در مسیر کلاس کاربر با استفاده از گزینه \f[CR]\-\-class\-path\f[R] یا اشکال جایگزین آن مشخص کنید.
.RE
.TP
\f[CR]\-deprecation\f[R]
توضیحاتی در مورد هر مورد استفاده یا بازنویسی (override) یک عضو یا کلاس منسوخ‌شده (deprecated) نمایش می‌دهد.
بدون گزینه \f[CR]\-deprecation\f[R]، دستور \f[CR]javac\f[R] خلاصه‌ای از فایل‌های منبعی را که از اعضا یا کلاس‌های منسوخ‌شده استفاده یا آن‌ها را بازنویسی کرده‌اند، نمایش می‌دهد.
گزینه \f[CR]\-deprecation\f[R] معادل کوتاه‌شده \f[CR]\-Xlint:deprecation\f[R] است.
.TP
\f[CR]\-\-enable\-preview\f[R]
قابلیت‌های پیش‌نمایش زبان را فعال می‌کند.
همچنین دسته lint مربوط به \f[CR]preview\f[R] را غیرفعال می‌کند.
همراه با \f[B]\f[CB]\-source\f[B]\f[R] یا \f[B]\f[CB]\-\-release\f[B]\f[R] استفاده می‌شود.
.TP
\f[CR]\-encoding\f[R] \f[I]encoding\f[R]
رمزگذاری نویسه مورد استفاده توسط فایل‌های منبع را مشخص می‌کند، مانند EUC\-JP و UTF\-8.
اگر گزینه \f[CR]\-encoding\f[R] مشخص نشده باشد، از مبدل پیش‌فرض پلتفرم استفاده می‌شود.
.TP
\f[CR]\-endorseddirs\f[R] \f[I]directories\f[R]
محل مسیر استانداردهای تاییدشده (endorsed standards) را رونویسی می‌کند.
.RS
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های قبل از JDK 9 قابل استفاده است.
برای جزئیات به توضیحات گزینه‌های \f[B]\f[CB]\-\-release\f[B]\f[R]، \f[B]\f[CB]\-source\f[B]\f[R] یا \f[B]\f[CB]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-extdirs\f[R] \f[I]directories\f[R]
محل افزونه‌های نصب‌شده را رونویسی می‌کند.
\f[CR]directories\f[R] فهرستی از دایرکتوری‌ها است که با جداکننده مسیر پلتفرم (\f[CR];\f[R] در ویندوز و \f[CR]:\f[R] در سایر سیستم‌ها) جدا شده‌اند.
هر فایل JAR در دایرکتوری‌های مشخص‌شده برای یافتن فایل‌های کلاس جستجو می‌شود.
تمام فایل‌های JAR پیدا شده بخشی از مسیر کلاس می‌شوند.
.RS
اگر برای نگارشی از پلتفرم کامپایل می‌کنید که از مکانیزم افزونه‌ها (Extension Mechanism) پشتیبانی می‌کند، این گزینه دایرکتوری‌های حاوی کلاس‌های افزونه را مشخص می‌کند.
بخش [کامپایل برای نگارش‌های دیگر پلتفرم] را ببینید.
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های قبل از JDK 9 قابل استفاده است.
برای جزئیات به توضیحات گزینه‌های \f[B]\f[CB]\-\-release\f[B]\f[R]، \f[B]\f[CB]\-source\f[B]\f[R] یا \f[B]\f[CB]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-g\f[R]
تمامی اطلاعات خطایابی (دیباگ) از جمله متغیرهای محلی را تولید می‌کند.
به طور پیش‌فرض، فقط اطلاعات مربوط به شماره خطوط و فایل‌های منبع تولید می‌شود.
.TP
\f[CR]\-g:\f[R][\f[CR]lines\f[R], \f[CR]vars\f[R], \f[CR]source\f[R]]
فقط انواع اطلاعات دیباگ تعیین‌شده در فهرست کلیدواژه‌های جداشده با کاما را تولید می‌کند.
کلیدواژه‌های معتبر عبارتند از:
.RS
.TP
\f[CR]lines\f[R]
اطلاعات دیباگ شماره خطوط.
.TP
\f[CR]vars\f[R]
اطلاعات دیباگ متغیرهای محلی.
.TP
\f[CR]source\f[R]
اطلاعات دیباگ فایل منبع.
.RE
.TP
\f[CR]\-g:none\f[R]
هیچ‌گونه اطلاعات دیباگی تولید نمی‌کند.
.TP
\f[CR]\-h\f[R] \f[I]directory\f[R]
محل قرارگیری فایل‌های هدر محلی (native header files) تولیدشده را مشخص می‌کند.
.RS
هنگامی که این گزینه را مشخص می‌کنید، یک فایل هدر محلی برای هر کلاسی که حاوی متدهای بومی (native) است یا یک یا چند ثابت علامت‌گذاری‌شده با حاشیه‌نویسی \f[B]\f[CB]java.lang.annotation.Native\f[B]\f[R] دارد، تولید می‌شود.
اگر کلاس بخشی از یک بسته باشد، کامپایلر فایل هدر محلی را در یک زیردایرکتوری متناسب با نام ماژول (در صورت وجود) و نام بسته قرار می‌دهد.
این دایرکتوری و زیردایرکتوری‌های لازم در صورت عدم وجود ایجاد خواهند شد.
.RE
.TP
\f[CR]\-\-help\f[R]، \f[CR]\-help\f[R] یا \f[CR]\-?\f[R]
خلاصه‌ای از گزینه‌های استاندارد را چاپ می‌کند.
.TP
\f[CR]\-\-help\-extra\f[R] یا \f[CR]\-X\f[R]
خلاصه‌ای از مجموعه گزینه‌های اضافی را چاپ می‌کند.
.TP
\f[CR]\-\-help\-lint\f[R]
کلیدهای پشتیبانی‌شده برای گزینه \f[CR]\-Xlint\f[R] را چاپ می‌کند.
.TP
\f[CR]\-implicit:\f[R][\f[CR]none\f[R], \f[CR]class\f[R]]
تعیین می‌کند که آیا برای فایل‌های ارجاع‌شده به صورت ضمنی (implicit) فایل کلاس تولید شود یا خیر:
.RS
.IP \(bu 2
\f[CR]\-implicit:class\f[R] \-\-\- فایل‌های کلاس را به طور خودکار تولید می‌کند.
.IP \(bu 2
\f[CR]\-implicit:none\f[R] \-\-\- از تولید فایل کلاس جلوگیری می‌کند.
اگر این گزینه مشخص نشود، مقدار پیش‌فرض تولید خودکار فایل‌های کلاس است.
در این حالت، اگر در حین پردازش حاشیه‌نویسی، فایل کلاسی تولید شود، کامپایلر یک هشدار صادر می‌کند.
وقتی گزینه \f[CR]\-implicit\f[R] به صراحت تنظیم شود، این هشدار صادر نمی‌شود.
به بخش \f[B]جستجوی تعاریف ماژول، بسته و نوع\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-J\f[R]\f[I]option\f[R]
گزینه \f[I]option\f[R] را به سیستم زمان اجرا ارسال می‌کند، که در آن \f[I]option\f[R] یکی از گزینه‌های جاوا است که در دستور \f[B]java\f[R] شرح داده شده است.
برای مثال، \f[CR]\-J\-Xms48m\f[R] حافظه راه‌اندازی را روی ۴۸ مگابایت تنظیم می‌کند.
.RS
\f[B]نکته:\f[R] متغیر محیطی \f[CR]CLASSPATH\f[R]، گزینه \f[CR]\-classpath\f[R]، گزینه \f[CR]\-bootclasspath\f[R] و گزینه \f[CR]\-extdirs\f[R] کلاس‌های مورد استفاده برای اجرای \f[CR]javac\f[R] را مشخص نمی‌کنند.
تلاش برای سفارشی‌سازی پیاده‌سازی کامپایلر با استفاده از این گزینه‌ها و متغیرها خطرناک است و اغلب به نتیجه دلخواه نمی‌رسد.
اگر نیاز به سفارشی‌سازی پیاده‌سازی کامپایلر دارید، از گزینه \f[CR]\-J\f[R] برای ارسال گزینه‌ها به راه‌انداز زیرین جاوا استفاده کنید.
.RE
.TP
\f[CR]\-\-limit\-modules\f[R] \f[I]module\f[R]\f[CR],\f[R]\f[I]module\f[R]*
جهان ماژول‌های قابل مشاهده را محدود می‌کند.
.TP
\f[CR]\-\-module\f[R] \f[I]module\-name\f[R] (\f[CR],\f[R]\f[I]module\-name\f[R])* یا \f[CR]\-m\f[R] \f[I]module\-name\f[R] (\f[CR],\f[R]\f[I]module\-name\f[R])*
آن دسته از فایل‌های منبع در ماژول‌های نام‌برده را کامپایل می‌کند که از فایل‌های متناظر در دایرکتوری خروجی تازه‌تر هستند.
.TP
\f[CR]\-\-module\-path\f[R] \f[I]path\f[R] یا \f[CR]\-p\f[R] \f[I]path\f[R]
محل یافتن ماژول‌های برنامه را مشخص می‌کند.
.TP
\f[CR]\-\-module\-source\-path\f[R] \f[I]module\-source\-path\f[R]
محل یافتن فایل‌های منبع را هنگام کامپایل کد در چندین ماژول مشخص می‌کند.
به بخش \f[B]گزینه مسیر منبع ماژول\f[R] مراجعه کنید.
.TP
\f[CR]\-\-module\-version\f[R] \f[I]version\f[R]
نسخه ماژول‌های در حال کامپایل را مشخص می‌کند.
.TP
\f[CR]\-nowarn\f[R]
فقط هشدارهای اجباری را تولید می‌کند.
.TP
\f[CR]\-parameters\f[R]
متاداده را برای بازتاب (reflection) روی پارامترهای متد تولید می‌کند.
نام‌های پارامترهای صوری سازنده‌ها و متدها را در فایل کلاس تولیدشده ذخیره می‌کند تا متد
\f[CR]java.lang.reflect.Executable.getParameters\f[R]
از API بازتاب بتواند آن‌ها را بازیابی کند.
.TP
\f[CR]\-proc:\f[R][\f[CR]none\f[R], \f[CR]only\f[R], \f[CR]full\f[R]]
کنترل می‌کند که آیا پردازش حاشیه‌نویسی و کامپایل انجام شوند یا خیر.
.RS
.IP \(bu 2
\f[CR]\-proc:none\f[R] به این معنی است که کامپایل بدون پردازش حاشیه‌نویسی انجام می‌شود.
.IP \(bu 2
\f[CR]\-proc:only\f[R] به این معنی است که فقط پردازش حاشیه‌نویسی بدون هیچ‌گونه کامپایل بعدی انجام می‌شود.
.IP \(bu 2
\f[CR]\-proc:full\f[R] به این معنی است که هم پردازش حاشیه‌نویسی و هم کامپایل انجام می‌شوند.
اگر از این گزینه استفاده نشود، در صورتی که حداقل یک گزینه دیگر برای پیکربندی صریح پردازش حاشیه‌نویسی استفاده شده باشد، پردازش حاشیه‌نویسی و کامپایل انجام خواهند شد.
.RE
.TP
\f[CR]\-processor\f[R] \f[I]class1\f[R][\f[CR],\f[R]\f[I]class2\f[R]\f[CR],\f[R]\f[I]class3\f[R]...]
نام پردازشگرهای حاشیه‌نویسی که باید اجرا شوند.
این گزینه فرآیند کشف خودکار و پیش‌فرض را نادیده می‌گیرد.
.TP
\f[CR]\-\-processor\-module\-path\f[R] \f[I]path\f[R]
مسیر ماژول مورد استفاده برای یافتن پردازشگرهای حاشیه‌نویسی را مشخص می‌کند.
.TP
\f[CR]\-\-processor\-path\f[R] \f[I]path\f[R] یا \f[CR]\-processorpath\f[R] \f[I]path\f[R]
محل یافتن پردازشگرهای حاشیه‌نویسی را مشخص می‌کند.
اگر از این گزینه استفاده نشود، مسیر کلاس برای یافتن پردازشگرها جستجو می‌شود.
.TP
\f[CR]\-profile\f[R] \f[I]profile\f[R]
بررسی می‌کند که API مورد استفاده در پروفایل مشخص‌شده در دسترس باشد.
این گزینه منسوخ شده و ممکن است در نگارش‌های آینده حذف شود.
.RS
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های قبل از JDK 9 قابل استفاده است.
برای جزئیات به توضیحات گزینه‌های \f[B]\f[CB]\-\-release\f[B]\f[R]، \f[B]\f[CB]\-source\f[B]\f[R] یا \f[B]\f[CB]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-\-release\f[R] \f[I]release\f[R]
کد منبع را بر اساس قواعد زبان برنامه‌نویسی جاوا برای نگارش مشخص‌شده Java SE کامپایل می‌کند و فایل‌های کلاسی تولید می‌نماید که آن نگارش را هدف قرار می‌دهند.
کد منبع در برابر API ترکیبی Java SE و JDK برای نگارش مشخص‌شده کامپایل می‌شود.
.RS
مقادیر پشتیبانی‌شده برای \f[I]release\f[R] عبارتند از نگارش فعلی Java SE و تعداد محدودی از نگارش‌های قبلی که در راهنمای خط فرمان با جزئیات آمده است.
برای نگارش فعلی، API مربوط به Java SE شامل بسته‌های \f[CR]java.*\f[R]، \f[CR]javax.*\f[R] و \f[CR]org.*\f[R] است که توسط ماژول‌های Java SE در آن نگارش صادر (export) شده‌اند؛ API مربوط به JDK شامل بسته‌های \f[CR]com.*\f[R] و \f[CR]jdk.*\f[R] است که توسط ماژول‌های JDK در آن نگارش صادر شده‌اند، به علاوه بسته‌های \f[CR]javax.*\f[R] که توسط ماژول‌های استاندارد اما غیر Java SE در آن نگارش صادر شده‌اند.
برای نگارش‌های قبلی، API مربوط به Java SE و JDK همان‌طور است که در آن نگارش تعریف شده بود.
\f[B]نکته:\f[R] هنگام استفاده از \f[CR]\-\-release\f[R]، نمی‌توانید همزمان از گزینه‌های \f[B]\f[CB]\-\-source\f[B]\f[R]/\f[CR]\-source\f[R] یا \f[B]\f[CB]\-\-target\f[B]\f[R]/\f[CR]\-target\f[R] استفاده کنید.
\f[B]نکته:\f[R] هنگام استفاده از \f[CR]\-\-release\f[R] برای تعیین نگارشی که از سیستم ماژول پلتفرم جاوا پشتیبانی می‌کند، نمی‌توان از گزینه \f[CR]\-\-add\-exports\f[R] برای گسترش مجموعه بسته‌های صادرشده توسط ماژول‌های Java SE، JDK و ماژول‌های استاندارد در نگارش مشخص‌شده استفاده کرد.
.RE
.TP
\f[CR]\-s\f[R] \f[I]directory\f[R]
دایرکتوری مورد استفاده برای قرار دادن فایل‌های منبع تولیدشده را مشخص می‌کند.
اگر کلاسی بخشی از یک بسته باشد، کامپایلر فایل منبع را در یک زیردایرکتوری متناسب با نام ماژول (در صورت وجود) و نام بسته قرار می‌دهد.
این دایرکتوری و زیردایرکتوری‌های لازم در صورت عدم وجود به طور خودکار ایجاد می‌شوند.
.RS
به جز در مواردی که کد برای چندین ماژول کامپایل می‌شود، محتویات دایرکتوری خروجی منبع در یک ساختار سلسله‌مراتبی بسته سازمان‌دهی خواهند شد.
هنگام کامپایل کد برای چندین ماژول، محتویات دایرکتوری خروجی منبع در یک سلسله‌مراتب ماژول سازمان‌دهی می‌شوند و محتویات هر ماژول در یک زیردایرکتوری جداگانه قرار می‌گیرد که هر کدام به صورت سلسله‌مراتب بسته سازمان‌دهی شده‌اند.
.RE
.TP
\f[CR]\-\-source\f[R] \f[I]release\f[R] یا \f[CR]\-source\f[R] \f[I]release\f[R]
کد منبع را بر اساس قواعد زبان برنامه‌نویسی جاوا برای نگارش مشخص‌شده Java SE کامپایل می‌کند.
مقادیر پشتیبانی‌شده برای \f[I]release\f[R] عبارتند از نگارش فعلی Java SE و تعداد محدودی از نگارش‌های پیشین که در راهنمای خط فرمان ذکر شده‌اند.
.RS
اگر این گزینه مشخص نشود، حالت پیش‌فرض کامپایل کد منبع طبق قواعد زبان جاوا برای نگارش فعلی Java SE است.
.RE
.TP
\f[CR]\-\-source\-path\f[R] \f[I]path\f[R] یا \f[CR]\-sourcepath\f[R] \f[I]path\f[R]
محل یافتن فایل‌های منبع را مشخص می‌کند.
به جز هنگام کامپایل همزمان چندین ماژول، این همان مسیر کد منبع است که برای جستجوی تعاریف کلاس یا رابط استفاده می‌شود.
.RS
\f[B]نکته:\f[R] کلاس‌های یافت‌شده از طریق مسیر کلاس ممکن است در صورت یافت شدن فایل‌های منبع آن‌ها، دوباره کامپایل شوند.
به بخش \f[B]جستجوی تعاریف ماژول، بسته و نوع\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-\-system\f[R] \f[I]jdk\f[R] | \f[CR]none\f[R]
محل ماژول‌های سیستمی را رونویسی می‌کند.
.TP
\f[CR]\-\-target\f[R] \f[I]release\f[R] یا \f[CR]\-target\f[R] \f[I]release\f[R]
فایل‌های \f[CR]class\f[R] مناسب برای نگارش مشخص‌شده Java SE را تولید می‌کند.
مقادیر پشتیبانی‌شده برای \f[I]release\f[R] عبارتند از نگارش فعلی Java SE و تعداد محدودی از نگارش‌های قبلی که در راهنمای خط فرمان آمده است.
.RS
\f[B]نکته:\f[R] نگارش هدف (target) باید مساوی یا بالاتر از نگارش منبع (source) باشد.
(به \f[B]\f[CB]\-\-source\f[B]\f[R] مراجعه کنید.)
.RE
.TP
\f[CR]\-\-upgrade\-module\-path\f[R] \f[I]path\f[R]
محل ماژول‌های قابل ارتقا را رونویسی می‌کند.
.TP
\f[CR]\-verbose\f[R]
پیام‌هایی درباره اقدامات در حال انجام توسط کامپایلر چاپ می‌کند.
این پیام‌ها شامل اطلاعاتی درباره هر کلاس بارگذاری‌شده و هر فایل منبع کامپایل‌شده است.
.TP
\f[CR]\-\-version\f[R] یا \f[CR]\-version\f[R]
اطلاعات نگارش را چاپ می‌کند.
.TP
\f[CR]\-Werror\f[R]
در صورت بروز هرگونه هشدار، فرآیند کامپایل را متوقف می‌کند؛ این شامل هشدارهای تمام دسته‌های lint و همچنین هشدارهای غیر lint می‌شود.
.TP
\f[CR]\-Werror:\f[R][\f[CR]\-\f[R]]\f[I]key\f[R](\f[CR],\f[R][\f[CR]\-\f[R]]\f[I]key\f[R])*
دسته‌های lint را مشخص می‌کند که هشدارهای آن‌ها باید موجب خاتمه کامپایل شوند.
کلیدهای \f[CR]all\f[R] و \f[CR]none\f[R] به ترتیب تمام دسته‌ها را شامل یا حذف می‌کنند؛ سایر کلیدها دسته مربوطه را شامل می‌شوند، یا اگر قبل از آن‌ها یک خط تیره (\f[CR]\-\f[R]) بیاید، آن را مستثنی می‌کنند.
به طور پیش‌فرض، هیچ دسته‌ای لحاظ نشده است.
برای خاتمه کامپایل، دسته مورد نظر باید فعال نیز باشد (در صورت لزوم، از طریق \f[B]\f[CB]\-Xlint\f[B]\f[R]).
برای فهرست کلیدهای دسته‌بندی lint، بخش \f[B]\f[CB]\-Xlint\f[B]\f[R] را در ادامه ببینید.
.SS "گزینه‌های اضافی (Extra Options)"
.TP
\f[CR]\-\-add\-exports\f[R] \f[I]module\f[R]\f[CR]/\f[R]\f[I]package\f[R]\f[CR]=\f[R]\f[I]other\-module\f[R](\f[CR],\f[R]\f[I]other\-module\f[R])*
بسته‌ای را مشخص می‌کند که باید از ماژول تعریف‌کننده آن به ماژول‌های اضافی، یا در صورت قرار دادن مقدار \f[CR]ALL\-UNNAMED\f[R] برای \f[I]other\-module\f[R] به تمام ماژول‌های بی‌نام، صادرشده تلقی شود.
.TP
\f[CR]\-\-add\-reads\f[R] \f[I]module\f[R]\f[CR]=\f[R]\f[I]other\-module\f[R](\f[CR],\f[R]\f[I]other\-module\f[R])*
ماژول‌های اضافی را مشخص می‌کند که باید توسط یک ماژول داده‌شده موردنیاز تلقی شوند.
.TP
\f[CR]\-\-default\-module\-for\-created\-files\f[R] \f[I]module\-name\f[R]
ماژول هدف پشتیبان (fallback) را برای فایل‌های ایجادشده توسط پردازشگرهای حاشیه‌نویسی در صورت عدم تعیین یا استنتاج مشخص می‌کند.
.TP
\f[CR]\-\-disable\-line\-doc\-comments\f[R]
پشتیبانی از کامنت‌های مستندسازی با خطوطی که با /// شروع می‌شوند را غیرفعال می‌کند.
.TP
\f[CR]\-Djava.endorsed.dirs=\f[R]\f[I]dirs\f[R]
محل مسیر استانداردهای تاییدشده را رونویسی می‌کند.
.RS
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های قبل از JDK 9 قابل استفاده است.
برای جزئیات به توضیحات گزینه‌های \f[B]\f[CB]\-\-release\f[B]\f[R]، \f[B]\f[CB]\-source\f[B]\f[R] یا \f[B]\f[CB]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-Djava.ext.dirs=\f[R]\f[I]dirs\f[R]
محل افزونه‌های نصب‌شده را رونویسی می‌کند.
.RS
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های قبل از JDK 9 قابل استفاده است.
برای جزئیات به توضیحات گزینه‌های \f[B]\f[CB]\-\-release\f[B]\f[R]، \f[B]\f[CB]\-source\f[B]\f[R] یا \f[B]\f[CB]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-\-patch\-module\f[R] \f[I]module\f[R]\f[CR]=\f[R]\f[I]path\f[R]
یک ماژول را با کلاس‌ها و منابع موجود در فایل‌های JAR یا دایرکتوری‌ها رونویسی یا تقویت می‌کند.
.TP
\f[CR]\-Xbootclasspath:\f[R]\f[I]path\f[R]
محل فایل‌های کلاس bootstrap را رونویسی می‌کند.
.RS
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های قبل از JDK 9 قابل استفاده است.
برای جزئیات به توضیحات گزینه‌های \f[B]\f[CB]\-\-release\f[B]\f[R]، \f[B]\f[CB]\-source\f[B]\f[R] یا \f[B]\f[CB]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-Xbootclasspath/a:\f[R]\f[I]path\f[R]
یک پسوند به مسیر کلاس bootstrap اضافه می‌کند.
.RS
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های قبل از JDK 9 قابل استفاده است.
برای جزئیات به توضیحات گزینه‌های \f[B]\f[CB]\-\-release\f[B]\f[R]، \f[B]\f[CB]\-source\f[B]\f[R] یا \f[B]\f[CB]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-Xbootclasspath/p:\f[R]\f[I]path\f[R]
یک پیشوند به مسیر کلاس bootstrap اضافه می‌کند.
.RS
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های قبل از JDK 9 قابل استفاده است.
برای جزئیات به توضیحات گزینه‌های \f[B]\f[CB]\-\-release\f[B]\f[R]، \f[B]\f[CB]\-source\f[B]\f[R] یا \f[B]\f[CB]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-Xdiags:\f[R][\f[CR]compact\f[R], \f[CR]verbose\f[R]]
حالت عیب‌یابی (تشخیصی) را انتخاب می‌کند.
.TP
\f[CR]\-Xdoclint\f[R]
بررسی‌های توصیه‌شده برای خطاهای کامنت‌های مستندسازی را فعال می‌کند.
.TP
\f[CR]\-Xdoclint:\f[R](\f[CR]all\f[R]|\f[CR]none\f[R]|[\f[CR]\-\f[R]]\f[I]group\f[R])[\f[CR]/\f[R]\f[I]access\f[R]]
گروه‌های خاصی از بررسی‌ها را در کامنت‌های مستندسازی فعال یا غیرفعال می‌کند.
.RS
متغیر \f[I]group\f[R] می‌تواند یکی از مقادیر زیر را داشته باشد:
\f[CR]accessibility\f[R]، \f[CR]html\f[R]، \f[CR]missing\f[R]، \f[CR]reference\f[R]، \f[CR]syntax\f[R].
متغیر \f[I]access\f[R] حداقل سطح دسترسی و قابلیت مشاهده کلاس‌ها و اعضایی را که گزینه \f[CR]\-Xdoclint\f[R] بررسی می‌کند، مشخص می‌نماید.
می‌تواند یکی از مقادیر زیر باشد (به ترتیب بیشترین تا کمترین دسترسی):
\f[CR]public\f[R]، \f[CR]protected\f[R]، \f[CR]package\f[R]، \f[CR]private\f[R].
سطح پیش‌فرض \f[I]access\f[R] برابر با \f[CR]private\f[R] است.
هنگامی که پیشوند \f[CR]doclint:\f[R] اضافه شود، نام‌های \f[I]group\f[R] و \f[CR]all\f[R] را می‌توان با \f[CR]\(atSuppressWarnings\f[R] استفاده کرد تا هشدارهای مربوط به کامنت‌های مستندسازی در بخش‌هایی از کد کامپایل‌شده سرکوب شوند.
برای اطلاعات بیشتر درباره این گروه‌های بررسی، به بخش \f[B]DocLint\f[R] در مستندات دستور \f[CR]javadoc\f[R] مراجعه کنید.
گزینه \f[CR]\-Xdoclint\f[R] به طور پیش‌فرض در دستور \f[CR]javac\f[R] غیرفعال است.
برای مثال، گزینه زیر کلاس‌ها و اعضایی (با تمام گروه‌های بررسی) را که سطح دسترسی protected و بالاتر (شامل protected و public) دارند بررسی می‌کند:
.RS
.PP
\f[CR]\-Xdoclint:all/protected\f[R]
.RE
گزینه زیر تمام گروه‌های بررسی را برای همه سطوح دسترسی فعال می‌کند، به جز اینکه خطاهای HTML را برای کلاس‌ها و اعضایی با سطح دسترسی package و بالاتر (شامل package، protected و public) بررسی نمی‌کند:
.RS
.PP
\f[CR]\-Xdoclint:all,\-html/package\f[R]
.RE
.RE
.TP
\f[CR]\-Xdoclint/package:\f[R][\f[CR]\-\f[R]]\f[I]packages\f[R](\f[CR],\f[R][\f[CR]\-\f[R]]\f[I]package\f[R])*
بررسی‌ها را در بسته‌های مشخص‌شده فعال یا غیرفعال می‌کند.
هر \f[I]package\f[R] یا نام کامل یک بسته است یا یک پیشوند نام بسته به همراه \f[CR].*\f[R] که به تمام زیربسته‌های بسته داده‌شده گسترش می‌یابد.
هر \f[I]package\f[R] می‌تواند با یک خط تیره (\f[CR]\-\f[R]) شروع شود تا بررسی‌ها برای یک یا چند بسته خاص غیرفعال شوند.
.RS
برای اطلاعات بیشتر، به بخش \f[B]DocLint\f[R] در مستندات دستور \f[CR]javadoc\f[R] مراجعه کنید.
.RE
.TP
\f[CR]\-Xlint\f[R]
تمامی هشدارهای توصیه‌شده را فعال می‌کند.
در این نگارش، فعال کردن تمامی هشدارهای موجود توصیه می‌شود.
.TP
\f[CR]\-Xlint:\f[R][\f[CR]\-\f[R]]\f[I]key\f[R](\f[CR],\f[R][\f[CR]\-\f[R]]\f[I]key\f[R])*
دسته‌های هشدار را با استفاده از یک یا چند کلید شرح داده شده در زیر که با کاما جدا شده‌اند، فعال و/یا غیرفعال می‌کند.
کلیدهای \f[CR]all\f[R] و \f[CR]none\f[R] به ترتیب تمام دسته‌ها را فعال یا غیرفعال می‌کنند؛ سایر کلیدها دسته متناظر را فعال کرده، یا اگر قبل از آن‌ها خط تیره (\f[CR]\-\f[R]) باشد، آن را غیرفعال می‌نمایند.
.RS
مقادیر پشتیبانی‌شده برای \f[I]key\f[R] عبارتند از:
.IP \(bu 2
\f[CR]all\f[R]: تمامی دسته‌های هشدار را فعال می‌کند.
.IP \(bu 2
\f[CR]auxiliaryclass\f[R]: درباره کلاس کمکی که در یک فایل منبع پنهان شده و از فایل‌های دیگر استفاده می‌شود، هشدار می‌دهد.
.IP \(bu 2
\f[CR]cast\f[R]: درباره استفاده از تبدیل نوع‌های (cast) غیرضروری هشدار می‌دهد.
.IP \(bu 2
\f[CR]classfile\f[R]: درباره مسائل مربوط به محتویات فایل کلاس هشدار می‌دهد.
.IP \(bu 2
\f[CR]dangling\-doc\-comments\f[R]: درباره کامنت‌های مستندسازی اضافی یا جابجا شده در نزدیکی ابتدای یک اعلان هشدار می‌دهد.
.IP \(bu 2
\f[CR]deprecation\f[R]: درباره استفاده از موارد منسوخ‌شده هشدار می‌دهد.
.IP \(bu 2
\f[CR]dep\-ann\f[R]: درباره مواردی که در \f[CR]javadoc\f[R] منسوخ علامت‌گذاری شده‌اند اما فاقد حاشیه‌نویسی \f[CR]\(atDeprecated\f[R] هستند هشدار می‌دهد.
.IP \(bu 2
\f[CR]divzero\f[R]: درباره تقسیم بر عدد صحیح ثابت 0 هشدار می‌دهد.
.IP \(bu 2
\f[CR]empty\f[R]: درباره دستور خالی بعد از \f[CR]if\f[R] هشدار می‌دهد.
.IP \(bu 2
\f[CR]exports\f[R]: درباره مسائل مربوط به صادرات ماژول هشدار می‌دهد.
.IP \(bu 2
\f[CR]fallthrough\f[R]: درباره افتادن (fall-through) از یک حالت دستور switch به حالت بعدی هشدار می‌دهد.
.IP \(bu 2
\f[CR]finally\f[R]: درباره بندهای \f[CR]finally\f[R] که به طور عادی خاتمه نمی‌یابند هشدار می‌دهد.
.IP \(bu 2
\f[CR]identity\f[R]: درباره استفاده از یک کلاس مبتنی بر مقدار (value-based) در جایی که یک کلاس هویتی (identity) انتظار می‌رود، هشدار می‌دهد.
.IP \(bu 2
\f[CR]incubating\f[R]: درباره استفاده از ماژول‌های آزمایشی/انکوباتور (incubating) هشدار می‌دهد.
.IP \(bu 2
\f[CR]lossy\-conversions\f[R]: درباره تبدیل‌های احتمالی همراه با اتلاف داده در انتساب‌های مرکب هشدار می‌دهد.
.IP \(bu 2
\f[CR]missing\-explicit\-ctor\f[R]: درباره عدم وجود سازنده‌های صریح در کلاس‌های عمومی (public) و حفاظت‌شده (protected) در بسته‌های صادرشده هشدار می‌دهد.
.IP \(bu 2
\f[CR]module\f[R]: درباره مسائل مربوط به سیستم ماژول هشدار می‌دهد.
.IP \(bu 2
\f[CR]opens\f[R]: درباره مسائل مربوط به باز کردن ماژول (opens) هشدار می‌دهد.
.IP \(bu 2
\f[CR]options\f[R]: درباره مسائل مربوط به استفاده از گزینه‌های خط فرمان هشدار می‌دهد.
.IP \(bu 2
\f[CR]output\-file\-clash\f[R]: در صورتی که هر فایل خروجی در حین کامپایل بازنویسی شود، هشدار می‌دهد.
این وضعیت ممکن است برای مثال در سیستم‌های فایلی حساس به حروف بزرگ و کوچک رخ دهد.
.IP \(bu 2
\f[CR]overloads\f[R]: درباره مسائل مربوط به سربارگذاری (overload) متدها هشدار می‌دهد.
.IP \(bu 2
\f[CR]overrides\f[R]: درباره مسائل مربوط به بازنویسی (override) متدها هشدار می‌دهد.
.IP \(bu 2
\f[CR]path\f[R]: درباره عناصر نامعتبر مسیر در خط فرمان هشدار می‌دهد.
.IP \(bu 2
\f[CR]preview\f[R]: درباره استفاده از ویژگی‌های پیش‌نمایش زبان هشدار می‌دهد.
.IP \(bu 2
\f[CR]processing\f[R]: درباره مسائل مربوط به پردازش حاشیه‌نویسی هشدار می‌دهد.
.IP \(bu 2
\f[CR]rawtypes\f[R]: درباره استفاده از انواع خام (raw types) هشدار می‌دهد.
.IP \(bu 2
\f[CR]removal\f[R]: درباره استفاده از API که برای حذف علامت‌گذاری شده است هشدار می‌دهد.
.IP \(bu 2
\f[CR]restricted\f[R]: درباره استفاده از متدهای محدودشده هشدار می‌دهد.
.IP \(bu 2
\f[CR]requires\-automatic\f[R]: به توسعه‌دهندگان درباره استفاده از ماژول‌های خودکار در بندهای requires هشدار می‌دهد.
.IP \(bu 2
\f[CR]requires\-transitive\-automatic\f[R]: درباره ماژول‌های خودکار در requires transitive هشدار می‌دهد.
.IP \(bu 2
\f[CR]serial\f[R]: درباره کلاس‌های سریال‌پذیر (serializable) که شناسه نسخه سریالی (serial version ID) ارائه نمی‌دهند هشدار می‌دهد.
همچنین درباره دسترسی به اعضای غیرعمومی از یک عنصر سریال‌پذیر هشدار می‌دهد.
.IP \(bu 2
\f[CR]static\f[R]: درباره دسترسی به یک عضو ایستا (static) با استفاده از یک نمونه (instance) هشدار می‌دهد.
.IP \(bu 2
\f[CR]strictfp\f[R]: درباره استفاده غیرضروری از اصلاح‌کننده \f[CR]strictfp\f[R] هشدار می‌دهد.
.IP \(bu 2
\f[CR]synchronization\f[R]: درباره تلاش برای همگام‌سازی روی نمونه‌های کلاس‌های مبتنی بر مقدار هشدار می‌دهد.
این کلید یک نام مستعار منسوخ‌شده برای \f[CR]identity\f[R] است که همان کاربردها و اثرات را دارد.
کاربران تشویق می‌شوند برای همه کاربردهای آینده و موجود به جای آن از دسته \f[CR]identity\f[R] استفاده کنند.
.IP \(bu 2
\f[CR]text\-blocks\f[R]: درباره نویسه‌های فاصله‌ساز متناقض در تورفتگی بلوک‌های متنی هشدار می‌دهد.
.IP \(bu 2
\f[CR]this\-escape\f[R]: درباره نشت مرجع \f[CR]this\f[R] در سازنده‌ها پیش از مقداردهی اولیه زیرکلاس هشدار می‌دهد.
.IP \(bu 2
\f[CR]try\f[R]: درباره مسائل مربوط به استفاده از بلوک‌های try (یعنی try\-with\-resources) هشدار می‌دهد.
.IP \(bu 2
\f[CR]unchecked\f[R]: درباره عملیات بررسی‌نشده (unchecked) هشدار می‌دهد.
.IP \(bu 2
\f[CR]varargs\f[R]: درباره متدهای دارای تعداد متغیر آرگومان (\f[CR]varargs\f[R]) با ایمنی بالقوه نامطمئن هشدار می‌دهد.
.IP \(bu 2
\f[CR]none\f[R]: تمامی دسته‌های هشدار را غیرفعال می‌کند.
به استثنای \f[CR]all\f[R] و \f[CR]none\f[R]، کلیدها را می‌توان با حاشیه‌نویسی \f[CR]\(atSuppressWarnings\f[R] استفاده کرد تا هشدارها در بخشی از کد منبع در حال کامپایل نادیده گرفته شوند.
بخش \f[B]مثال‌های استفاده از کلیدهای \-Xlint\f[R] را ببینید.
.RE
.TP
\f[CR]\-Xmaxerrs\f[R] \f[I]number\f[R]
حداکثر تعداد خطاهایی را که باید چاپ شوند تنظیم می‌کند.
.TP
\f[CR]\-Xmaxwarns\f[R] \f[I]number\f[R]
حداکثر تعداد هشدارهایی را که باید چاپ شوند تنظیم می‌کند.
.TP
\f[CR]\-Xpkginfo:\f[R][\f[CR]always\f[R], \f[CR]legacy\f[R], \f[CR]nonempty\f[R]]
مشخص می‌کند که دستور \f[CR]javac\f[R] چه زمانی و چگونه فایل‌های \f[CR]package\-info.class\f[R] را از فایل‌های \f[CR]package\-info.java\f[R] با استفاده از یکی از گزینه‌های زیر تولید کند:
.RS
.TP
\f[CR]always\f[R]
برای هر فایل \f[CR]package\-info.java\f[R] یک فایل \f[CR]package\-info.class\f[R] تولید می‌کند.
این گزینه در صورت استفاده از ابزارهای ساختی مانند Ant که بررسی می‌کنند آیا هر فایل \f[CR].java\f[R] یک فایل \f[CR].class\f[R] متناظر دارد، مفید است.
.TP
\f[CR]legacy\f[R]
تنها در صورتی فایل \f[CR]package\-info.class\f[R] تولید می‌کند که \f[CR]package\-info.java\f[R] حاوی حاشیه‌نویسی باشد.
اگر \f[CR]package\-info.java\f[R] فقط حاوی کامنت باشد، این گزینه فایل \f[CR]package\-info.class\f[R] تولید نمی‌کند.
.RS
\f[B]نکته:\f[R] اگر تمام حاشیه‌نویسی‌های موجود در فایل \f[CR]package\-info.java\f[R] دارای خط‌مشی نگهداری \f[CR]RetentionPolicy.SOURCE\f[R] باشند، ممکن است یک فایل \f[CR]package\-info.class\f[R] تولید شود اما خالی باشد.
.RE
.TP
\f[CR]nonempty\f[R]
تنها در صورتی فایل \f[CR]package\-info.class\f[R] تولید می‌کند که \f[CR]package\-info.java\f[R] حاوی حاشیه‌نویسی‌هایی با \f[CR]RetentionPolicy.CLASS\f[R] یا \f[CR]RetentionPolicy.RUNTIME\f[R] باشد.
.RE
.TP
\f[CR]\-Xplugin:\f[R]\f[I]name\f[R] \f[I]args\f[R]
نام و آرگومان‌های اختیاری پلاگینی را که باید اجرا شود مشخص می‌کند.
در صورت ارائه \f[I]args\f[R]، مقدار \f[I]name\f[R] و \f[I]args\f[R] باید درون نقل‌قول قرار گیرند یا نویسه‌های فاصله بین نام و آرگومان‌ها اسکیپ شوند.
برای جزئیات بیشتر در مورد API پلاگین، به مستندات API مربوط به \f[B]jdk.compiler/com.sun.source.util.Plugin\f[R] مراجعه کنید.
.TP
\f[CR]\-Xprefer:\f[R][\f[CR]source\f[R], \f[CR]newer\f[R]]
مشخص می‌کند که هنگام یافتن همزمان فایل منبع و فایل کلاس برای یک کلاس کامپایل‌شده ضمنی، کدام فایل با استفاده از یکی از گزینه‌های زیر خوانده شود.
به بخش \f[B]جستجوی تعاریف ماژول، بسته و نوع\f[R] مراجعه کنید.
.RS
.IP \(bu 2
\f[CR]\-Xprefer:newer\f[R]: فایل تازه‌تر بین فایل منبع یا کلاس را برای یک نوع می‌خواند (پیش‌فرض).
.IP \(bu 2
\f[CR]\-Xprefer:source\f[R] : فایل منبع را می‌خواند.
هنگامی که می‌خواهید مطمئن شوید پردازشگرهای حاشیه‌نویسی می‌توانند به حاشیه‌نویسی‌های اعلان‌شده با خط‌مشی نگهداری \f[CR]SOURCE\f[R] دسترسی داشته باشند، از \f[CR]\-Xprefer:source\f[R] استفاده کنید.
.RE
.TP
\f[CR]\-Xprint\f[R]
نمایشی متنی از انواع مشخص‌شده را برای اهداف خطایابی چاپ می‌کند.
این کار پردازش حاشیه‌نویسی یا کامپایل انجام نمی‌دهد.
قالب خروجی ممکن است تغییر کند.
.TP
\f[CR]\-XprintProcessorInfo\f[R]
اطلاعاتی درباره اینکه از یک پردازشگر خواسته شده چه حاشیه‌نویسی‌هایی را پردازش کند، چاپ می‌کند.
.TP
\f[CR]\-XprintRounds\f[R]
اطلاعاتی درباره دورهای اولیه و بعدی پردازش حاشیه‌نویسی چاپ می‌کند.
.TP
\f[CR]\-Xstdout\f[R] \f[I]filename\f[R]
پیام‌های کامپایلر را به فایل نام‌برده ارسال می‌کند.
به طور پیش‌فرض، پیام‌های کامپایلر به \f[CR]System.err\f[R] ارسال می‌شوند.
.SH "متغیرهای محیطی (ENVIRONMENT VARIABLES)"
.SS CLASSPATH
اگر گزینه \f[B]\f[CB]\-\-class\-path\f[B]\f[R] یا هر یک از اشکال جایگزین آن مشخص نشده باشد، مسیر کلاس در صورت تنظیم بودن به مقدار متغیر محیطی \f[CR]CLASSPATH\f[R] تغییر می‌یابد.
با این حال، توصیه می‌شود که این متغیر محیطی تنظیم \f[I]نشود\f[R] و در صورت نیاز از گزینه \f[CR]\-\-class\-path\f[R] برای تعیین صریح مقدار مسیر کلاس استفاده شود.
.SS JDK_JAVAC_OPTIONS
محتوای متغیر محیطی \f[CR]JDK_JAVAC_OPTIONS\f[R] که با فاصله‌ها ( ) یا نویسه‌های فاصله‌ساز
(\f[CR]\(rsn\f[R]، \f[CR]\(rst\f[R]، \f[CR]\(rsr\f[R] یا \f[CR]\(rsf\f[R])
جدا شده‌اند، به عنوان فهرستی از آرگومان‌ها به ابتدای آرگومان‌های خط فرمان ارسالی به \f[CR]javac\f[R] اضافه می‌شود.
.PP
الزامات رمزگذاری برای این متغیر محیطی مشابه خط فرمان \f[CR]javac\f[R] در سیستم است.
محتوای متغیر محیطی \f[CR]JDK_JAVAC_OPTIONS\f[R] به همان شیوه‌ای که در خط فرمان تعیین می‌شود پردازش می‌گردد.
.PP
می‌توان از نقل‌قول‌های تکی (\f[CR]\(aq\f[R]) یا دوتایی (\f[CR]\(dq\f[R]) برای محصور کردن آرگومان‌های حاوی نویسه‌های فاصله‌ساز استفاده کرد.
تمام محتوای بین نقل‌قول باز و اولین نقل‌قول بسته متناظر با حذف جفت نقل‌قول‌ها حفظ می‌شود.
در صورتی که نقل‌قول متناظر پیدا نشود، راه‌انداز با یک پیام خطا متوقف خواهد شد.
فایل‌های \f[CR]\(at\f[R]\f[I]files\f[R] به همان صورتی که در خط فرمان تعیین می‌شوند، پشتیبانی می‌گردند.
با این حال، همانند فایل‌های \f[CR]\(at\f[R]\f[I]files\f[R]، استفاده از نویسه‌های عمومی (wildcard) پشتیبانی نمی‌شود.
.PP
\f[B]مثال‌های نقل‌قول کردن آرگومان‌های حاوی فاصله:\f[R]
.RS
.PP
\f[CR]export JDK_JAVAC_OPTIONS=\(aq\(at\(dqC:\(rswhite spaces\(rsargfile\(dq\(aq\f[R]
.RE
.RS
.PP
\f[CR]export JDK_JAVAC_OPTIONS=\(aq\(dq\(atC:\(rswhite spaces\(rsargfile\(dq\(aq\f[R]
.RE
.RS
.PP
\f[CR]export JDK_JAVAC_OPTIONS=\(aq\(atC:\(rs\(dqwhite spaces\(dq\(rsargfile\(aq\f[R]
.RE
.SH "فایل‌های آرگومان خط فرمان (COMMAND\-LINE ARGUMENT FILES)"
یک فایل آرگومان می‌تواند شامل گزینه‌های خط فرمان و نام فایل‌های منبع در هر ترکیبی باشد.
آرگومان‌های درون فایل را می‌توان با فاصله یا نویسه‌های خط جدید جدا کرد.
اگر نام فایلی حاوی فاصله‌های درونی باشد، کل نام فایل را درون علامت نقل‌قول دوتایی قرار دهید.
.PP
نام فایل‌های درون یک فایل آرگومان نسبت به دایرکتوری جاری سنجیده می‌شوند، نه نسبت به مکان فایل آرگومان.
نویسه‌های عمومی (\f[CR]*\f[R]) در این فهرست‌ها مجاز نیستند (مانند تعیین \f[CR]*.java\f[R]).
استفاده از علامت اَت (\f[CR]\(at\f[R]) برای تفسیر بازگشتی فایل‌ها پشتیبانی نمی‌شود.
گزینه‌های \f[CR]\-J\f[R] پشتیبانی نمی‌شوند زیرا به راه‌انداز ارسال می‌شوند که از فایل‌های آرگومان پشتیبانی نمی‌کند.
.PP
هنگام اجرای دستور \f[CR]javac\f[R]، مسیر و نام هر فایل آرگومان را با پیشوند علامت اَت (\f[CR]\(at\f[R]) وارد کنید.
هنگامی که دستور \f[CR]javac\f[R] با آرگومانی مواجه می‌شود که با علامت اَت (\f[CR]\(at\f[R]) شروع می‌شود، محتویات آن فایل را در فهرست آرگومان‌ها باز می‌کند.
.SS "مثال‌های استفاده از javac \(atfilename"
.TP
فایل آرگومان تکی (Single Argument File)
می‌توانید از یک فایل آرگومان تکی به نام \f[CR]argfile\f[R] برای نگهداری تمام آرگومان‌های \f[CR]javac\f[R] استفاده کنید:
.RS
.RS
.PP
\f[CR]javac \(atargfile\f[R]
.RE
این فایل آرگومان می‌تواند حاوی محتویات هر دو فایل نشان‌داده‌شده در مثال زیر (\f[B]دو فایل آرگومان\f[R]) باشد.
.RE
.TP
دو فایل آرگومان (Two Argument Files)
می‌توانید دو فایل آرگومان ایجاد کنید: یکی برای گزینه‌های \f[CR]javac\f[R] و دیگری برای نام فایل‌های منبع.
توجه داشته باشید که فهرست‌های زیر فاقد نویسه‌های ادامه‌دهنده خط هستند.
.RS
فایلی به نام \f[CR]options\f[R] ایجاد کنید که حاوی موارد زیر باشد:
.PP
\f[B]لینوکس و مک‌او‌اس:\f[R]
.IP
.EX
\-d classes
\-g
\-sourcepath /java/pubs/ws/1.3/src/share/classes
.EE
\f[B]ویندوز:\f[R]
.IP
.EX
\-d classes
\-g
\-sourcepath C:\(rsjava\(rspubs\(rsws\(rs1.3\(rssrc\(rsshare\(rsclasses
.EE
فایلی به نام \f[CR]sources\f[R] ایجاد کنید که حاوی موارد زیر باشد:
.IP
.EX
MyClass1.java
MyClass2.java
MyClass3.java
.EE
سپس دستور \f[CR]javac\f[R] را به صورت زیر اجرا کنید:
.RS
.PP
\f[CR]javac \(atoptions \(atsources\f[R]
.RE
.RE
.TP
فایل‌های آرگومان دارای مسیر (Argument Files with Paths)
فایل‌های آرگومان می‌توانند مسیر داشته باشند، اما نام هر فایلی درون آن‌ها نسبت به دایرکتوری کاری جاری سنجیده می‌شود (نه نسبت به \f[CR]path1\f[R] یا \f[CR]path2\f[R]):
.RS
.RS
.PP
\f[CR]javac \(atpath1/options \(atpath2/sources\f[R]
.RE
.RE
.SH "آرایش و ساختار کد منبع (ARRANGEMENT OF SOURCE CODE)"
در زبان جاوا، کلاس‌ها و رابط‌ها می‌توانند در بسته‌ها سازمان‌دهی شوند و بسته‌ها نیز در ماژول‌ها قرار گیرند.
دستور \f[CR]javac\f[R] انتظار دارد که آرایش فیزیکی فایل‌های منبع در دایرکتوری‌های سیستم فایل، بازتابی از سازمان‌دهی کلاس‌ها در بسته‌ها و بسته‌ها در ماژول‌ها باشد.
.PP
یک قرارداد پذیرفته‌شده گسترده این است که نام ماژول‌ها و بسته‌ها با حروف کوچک شروع می‌شوند و نام کلاس‌ها با حروف بزرگ آغاز می‌گردند.
.SS "آرایش کد منبع برای یک بسته (Arrangement of Source Code for a Package)"
هنگامی که کلاس‌ها و رابط‌ها در یک بسته سازمان‌دهی می‌شوند، بسته به صورت یک دایرکتوری و زیربسته‌های آن به صورت زیردایرکتوری‌ها نمایش داده می‌شوند.
.PP
برای مثال:
.IP \(bu 2
بسته \f[CR]p\f[R] به صورت دایرکتوری به نام \f[CR]p\f[R] نمایش داده می‌شود.
.IP \(bu 2
بسته \f[CR]p.q\f[R] \-\- یعنی زیربسته \f[CR]q\f[R] از بسته \f[CR]p\f[R] \-\- به صورت زیردایرکتوری \f[CR]q\f[R] از دایرکتوری \f[CR]p\f[R] نمایش داده می‌شود.
بنابراین درخت دایرکتوری نمایش‌دهنده بسته \f[CR]p.q\f[R] در ویندوز \f[CR]p\(rsq\f[R] و در سایر سیستم‌ها \f[CR]p/q\f[R] است.
.IP \(bu 2
بسته \f[CR]p.q.r\f[R] به صورت درخت دایرکتوری \f[CR]p\(rsq\(rsr\f[R] (در ویندوز) یا \f[CR]p/q/r\f[R] (در سایر سیستم‌ها) نمایش داده می‌شود.
.PP
درون یک دایرکتوری یا زیردایرکتوری، فایل‌های \f[CR].java\f[R] نشان‌دهنده کلاس‌ها و رابط‌های موجود در بسته یا زیربسته متناظر هستند.
.PP
برای مثال:
.IP \(bu 2
کلاس \f[CR]X\f[R] اعلان‌شده در بسته \f[CR]p\f[R] با فایل \f[CR]X.java\f[R] در دایرکتوری \f[CR]p\f[R] نمایش داده می‌شود.
.IP \(bu 2
کلاس \f[CR]Y\f[R] اعلان‌شده در بسته \f[CR]p.q\f[R] با فایل \f[CR]Y.java\f[R] در زیردایرکتوری \f[CR]q\f[R] از دایرکتوری \f[CR]p\f[R] نمایش داده می‌شود.
.IP \(bu 2
کلاس \f[CR]Z\f[R] اعلان‌شده در بسته \f[CR]p.q.r\f[R] با فایل \f[CR]Z.java\f[R] در زیردایرکتوری \f[CR]r\f[R] از \f[CR]p\(rsq\f[R] (در ویندوز) یا \f[CR]p/q\f[R] (در سایر سیستم‌ها) نمایش داده می‌شود.
.PP
در برخی شرایط، تفکیک کد به دایرکتوری‌های جداگانه، که هر کدام به صورت بالا ساختاریافته‌اند، و معرفی فهرست تجمیعی دایرکتوری‌ها به \f[CR]javac\f[R] راحت‌تر است.
.SS "آرایش کد منبع برای یک ماژول (Arrangement of Source Code for a Module)"
در زبان جاوا، ماژول مجموعه‌ای از بسته‌ها است که برای استفاده مجدد طراحی شده‌اند.
علاوه بر فایل‌های \f[CR].java\f[R] برای کلاس‌ها و رابط‌ها، هر ماژول دارای یک فایل منبع به نام \f[CR]module\-info.java\f[R] است که:
.IP "1." 3
نام ماژول را تعریف می‌کند؛
.IP "2." 3
بسته‌های صادرشده توسط ماژول را فهرست می‌کند (تا استفاده مجدد توسط سایر ماژول‌ها امکان‌پذیر شود)؛
.IP "3." 3
سایر ماژول‌های مورد نیاز این ماژول را فهرست می‌کند (تا از بسته‌های صادرشده آن‌ها استفاده مجدد شود).
.PP
هنگامی که بسته‌ها در یک ماژول سازمان‌دهی می‌شوند، ماژول با یک یا چند دایرکتوری نشان‌دهنده بسته‌های درون ماژول نمایش داده می‌شود که یکی از آن‌ها حاوی فایل \f[CR]module\-info.java\f[R] است.
ممکن است استفاده از یک دایرکتوری واحد، هم‌نام با ماژول، برای نگهداری فایل \f[CR]module\-info.java\f[R] در کنار درخت دایرکتوری نشان‌دهنده بسته‌ها در ماژول (یعنی \f[I]سلسله‌مراتب بسته\f[R] که در بالا توضیح داده شد) راحت باشد، اما اجباری نیست.
آرایش دقیق کد منبع برای یک ماژول معمولاً توسط قراردادهای محیط توسعه (IDE) یا سیستم ساخت دیکته می‌شود.
.PP
برای مثال:
.IP \(bu 2
ماژول \f[CR]a.b.c\f[R] ممکن است با دایرکتوری \f[CR]a.b.c\f[R] در تمام سیستم‌ها نمایش داده شود.
.IP \(bu 2
اعلان ماژول با فایل \f[CR]module\-info.java\f[R] در دایرکتوری \f[CR]a.b.c\f[R] نمایش داده می‌شود.
.IP \(bu 2
اگر ماژول حاوی بسته \f[CR]p.q.r\f[R] باشد، دایرکتوری \f[CR]a.b.c\f[R] شامل درخت دایرکتوری \f[CR]p\(rsq\(rsr\f[R] (در ویندوز) یا \f[CR]p/q/r\f[R] (در سایر سیستم‌ها) خواهد بود.
.PP
محیط توسعه ممکن است ساختار سلسله‌مراتبی دایرکتوری خاصی را بین دایرکتوری نام‌گذاری‌شده برای ماژول و فایل‌های منبعی که باید توسط \f[CR]javac\f[R] خوانده شوند، تعیین کند.
.PP
برای مثال:
.IP \(bu 2
ماژول \f[CR]a.b.c\f[R] ممکن است با دایرکتوری \f[CR]a.b.c\f[R] نمایش داده شود.
.IP \(bu 2
اعلان ماژول و بسته‌های ماژول ممکن است در زیردایرکتوری از \f[CR]a.b.c\f[R] قرار گیرند، مانند \f[CR]src\(rsmain\(rsjava\f[R] (در ویندوز) یا \f[CR]src/main/java\f[R] (در سایر سیستم‌ها).
.SH "پیکربندی کامپایل (CONFIGURING A COMPILATION)"
این بخش نحوه پیکربندی \f[CR]javac\f[R] را برای انجام یک کامپایل پایه‌ای شرح می‌دهد.
.PP
برای جزئیات بیشتر هنگام کامپایل برای نگارشی از پلتفرم که از ماژول‌ها پشتیبانی می‌کند، به بخش \f[B]پیکربندی سیستم ماژول\f[R] مراجعه کنید.
.SS "فایل‌های منبع (Source Files)"
.IP \(bu 2
فایل‌های منبعی را که باید کامپایل شوند در خط فرمان مشخص کنید.
.PP
اگر خطای کامپایلی وجود نداشته باشد، فایل‌های کلاس متناظر در \f[B]دایرکتوری خروجی\f[R] قرار می‌گیرند.
.PP
برخی از سیستم‌ها ممکن است حجم ورودی در خط فرمان را محدود کنند؛ برای دور زدن این محدودیت‌ها، می‌توانید از \f[B]فایل‌های آرگومان\f[R] استفاده کنید.
.PP
هنگام کامپایل کد برای ماژول‌ها، می‌توانید فایل‌های منبع را به صورت غیرمستقیم با استفاده از گزینه \f[B]\f[CB]\-\-module\f[B]\f[R] یا \f[CR]\-m\f[R] مشخص نمایید.
.SS "دایرکتوری خروجی (Output Directory)"
.IP \(bu 2
از گزینه \f[B]\f[CB]\-d\f[B]\f[R] برای تعیین دایرکتوری خروجی برای قرار دادن فایل‌های کلاس کامپایل‌شده استفاده کنید.
.PP
این خروجی به طور معمول در یک \f[B]سلسله‌مراتب بسته\f[R] سازمان‌دهی می‌شود، مگر اینکه کدهای منبع را از چندین ماژول کامپایل کنید، که در این صورت به صورت \f[B]سلسله‌مراتب ماژول\f[R] سازمان‌دهی خواهد شد.
.PP
پس از اتمام کامپایل، اگر یک یا چند ماژول را کامپایل کرده‌اید، می‌توانید دایرکتوری خروجی را در مسیر ماژول برای \f[B]راه‌انداز\f[R] جاوا قرار دهید؛ در غیر این صورت، می‌توانید دایرکتوری خروجی را در مسیر کلاس برای راه‌انداز جاوا قرار دهید.
.SS "کد از پیش کامپایل‌شده (Precompiled Code)"
کدی که باید کامپایل شود ممکن است به کتابخانه‌هایی فراتر از آنچه توسط پلتفرم ارائه شده ارجاع دهد.
در این صورت، باید این کتابخانه‌ها را در مسیر کلاس یا مسیر ماژول قرار دهید.
اگر کد کتابخانه در یک ماژول نیست، آن را در مسیر کلاس قرار دهید؛ اگر در یک ماژول است، آن را در مسیر ماژول قرار دهید.
.IP \(bu 2
از گزینه \f[B]\f[CB]\-\-class\-path\f[B]\f[R] برای تعیین کتابخانه‌هایی که باید در مسیر کلاس قرار گیرند استفاده کنید.
مکان‌های موجود در مسیر کلاس باید در یک \f[B]سلسله‌مراتب بسته\f[R] سازمان‌دهی شوند.
همچنین می‌توانید از اشکال جایگزین این گزینه استفاده کنید: \f[CR]\-classpath\f[R] یا \f[CR]\-cp\f[R].
.IP \(bu 2
از گزینه \f[B]\f[CB]\-\-module\-path\f[B]\f[R] برای تعیین کتابخانه‌هایی که باید در مسیر ماژول قرار گیرند استفاده کنید.
مکان‌های موجود در مسیر ماژول باید ماژول‌ها یا دایرکتوری‌های حاوی ماژول باشند.
همچنین می‌توانید از شکل جایگزین این گزینه استفاده کنید: \f[CR]\-p\f[R].
.RS 2
.PP
برای جزئیات بیشتر در مورد نحوه تغییر پیکربندی پیش‌فرض ماژول‌های کتابخانه، به بخش \f[B]پیکربندی سیستم ماژول\f[R] مراجعه کنید.
.RE
.PP
\f[B]نکته\f[R]: گزینه‌های مسیر کلاس و مسیر ماژول ناسازگار با یکدیگر نیستند، هرچند تعیین مسیر کلاس هنگام کامپایل کد برای یک یا چند ماژول معمول نیست.
.SS "فایل‌های منبع اضافی (Additional Source Files)"
کد مورد نظر برای کامپایل ممکن است به انواعی در فایل‌های منبع اضافی ارجاع دهد که در خط فرمان مشخص نشده‌اند.
در این صورت، باید آن فایل‌های منبع را در مسیر منبع یا مسیر ماژول قرار دهید.
شما فقط می‌توانید یکی از این گزینه‌ها را مشخص کنید: اگر کدی را برای یک ماژول کامپایل نمی‌کنید یا اگر فقط برای یک ماژول واحد کامپایل می‌کنید، از مسیر منبع استفاده کنید؛ اگر برای چندین ماژول کامپایل می‌کنید، از مسیر منبع ماژول استفاده نمایید.
.IP \(bu 2
از گزینه \f[B]\f[CB]\-\-source\-path\f[B]\f[R] برای تعیین مکان فایل‌های منبع اضافی که ممکن است توسط javac خوانده شوند استفاده کنید.
مکان‌های موجود در مسیر منبع باید در یک \f[B]سلسله‌مراتب بسته\f[R] سازمان‌دهی شوند.
همچنین می‌توانید از شکل جایگزین این گزینه استفاده کنید: \f[CR]\-sourcepath\f[R].
.IP \(bu 2
از گزینه \f[B]\f[CB]\-\-module\-source\-path\f[B]\f[R] یک یا چند بار برای تعیین مکان فایل‌های منبع اضافی در ماژول‌های مختلف که ممکن است توسط javac خوانده شوند، یا هنگام کامپایل فایل‌های منبع در چندین ماژول استفاده کنید.
می‌توانید مکان‌ها را برای هر ماژول به صورت \f[B]جداگانه\f[R] مشخص کنید یا فایل‌های منبع را طوری سازمان‌دهی کنید که بتوانید مکان‌ها را به صورت \f[B]یکجا\f[R] مشخص نمایید.
برای جزئیات بیشتر، به بخش \f[B]گزینه مسیر منبع ماژول\f[R] مراجعه کنید.
.PP
اگر می‌خواهید بتوانید به انواع موجود در فایل‌های منبع اضافی ارجاع دهید اما نمی‌خواهید آن‌ها کامپایل شوند، از گزینه \f[B]\f[CB]\-implicit\f[B]\f[R] استفاده کنید.
.PP
\f[B]نکته\f[R]: اگر کدی را برای چندین ماژول کامپایل می‌کنید، باید همیشه یک مسیر منبع ماژول مشخص کنید، و تمام فایل‌های منبع مشخص‌شده در خط فرمان باید در یکی از دایرکتوری‌های موجود در مسیر منبع ماژول یا در زیردایرکتوری‌های آن قرار داشته باشند.
.SS "مثال کامپایل چندین فایل منبع (Example of Compiling Multiple Source Files)"
این مثال فایل‌های منبع \f[CR]Aloha.java\f[R]، \f[CR]GutenTag.java\f[R]، \f[CR]Hello.java\f[R] و \f[CR]Hi.java\f[R] را در بسته \f[CR]greetings\f[R] کامپایل می‌کند.
.PP
\f[B]لینوکس و مک‌او‌اس:\f[R]
.IP
.EX
% javac greetings/*.java
% ls greetings
Aloha.class         GutenTag.class      Hello.class         Hi.class
Aloha.java          GutenTag.java       Hello.java          Hi.java
.EE
.PP
\f[B]ویندوز:\f[R]
.IP
.EX
C:\(rs>javac greetings\(rs*.java
C:\(rs>dir greetings
Aloha.class         GutenTag.class      Hello.class         Hi.class
Aloha.java          GutenTag.java       Hello.java          Hi.java
.EE
.SS "مثال تعیین مسیر کلاس کاربر (Example of Specifying a User Class Path)"
پس از تغییر یکی از فایل‌های منبع در مثال قبلی، آن را دوباره کامپایل کنید:
.PP
\f[B]لینوکس و مک‌او‌اس:\f[R]
.IP
.EX
pwd
/examples
javac greetings/Hi.java
.EE
.PP
\f[B]ویندوز:\f[R]
.IP
.EX
C:\(rs>cd
\(rsexamples
C:\(rs>javac greetings\(rsHi.java
.EE
.PP
از آنجا که \f[CR]greetings.Hi\f[R] به کلاس‌های دیگر در بسته \f[CR]greetings\f[R] ارجاع می‌دهد، کامپایلر باید این کلاس‌های دیگر را پیدا کند.
مثال قبلی کار می‌کند زیرا مسیر کلاس کاربر پیش‌فرض، دایرکتوری حاوی دایرکتوری بسته است.
اگر می‌خواهید این فایل را بدون توجه به دایرکتوری جاری کامپایل مجدد کنید، دایرکتوری examples را با تنظیم \f[CR]CLASSPATH\f[R] به مسیر کلاس کاربر اضافه کنید.
این مثال از گزینه \f[CR]\-classpath\f[R] استفاده می‌کند.
.PP
\f[B]لینوکس و مک‌او‌اس:\f[R]
.RS
.PP
\f[CR]javac \-classpath /examples /examples/greetings/Hi.java\f[R]
.RE
.PP
\f[B]ویندوز:\f[R]
.RS
.PP
\f[CR]C:\(rs>javac \-classpath \(rsexamples \(rsexamples\(rsgreetings\(rsHi.java\f[R]
.RE
.PP
اگر \f[CR]greetings.Hi\f[R] را برای استفاده از یک ابزار بنر تغییر دهید، آن ابزار نیز باید از طریق مسیر کلاس کاربر در دسترس باشد.
.PP
\f[B]لینوکس و مک‌او‌اس:\f[R]
.IP
.EX
javac \-classpath /examples:/lib/Banners.jar \(rs
            /examples/greetings/Hi.java
.EE
.PP
\f[B]ویندوز:\f[R]
.IP
.EX
C:\(rs>javac \-classpath \(rsexamples;\(rslib\(rsBanners.jar \(ha
            \(rsexamples\(rsgreetings\(rsHi.java
.EE
.PP
برای اجرای یک کلاس در بسته \f[CR]greetings\f[R]، برنامه نیاز به دسترسی به بسته \f[CR]greetings\f[R] و کلاس‌هایی دارد که کلاس‌های \f[CR]greetings\f[R] از آن‌ها استفاده می‌کنند.
.PP
\f[B]لینوکس و مک‌او‌اس:\f[R]
.RS
.PP
\f[CR]java \-classpath /examples:/lib/Banners.jar greetings.Hi\f[R]
.RE
.PP
\f[B]ویندوز:\f[R]
.RS
.PP
\f[CR]C:\(rs>java \-classpath \(rsexamples;\(rslib\(rsBanners.jar greetings.Hi\f[R]
.RE
.SH "پیکربندی سیستم ماژول (CONFIGURING THE MODULE SYSTEM)"
اگر می‌خواهید ماژول‌های اضافی را در کامپایل خود بگنجانید، از گزینه
\f[B]\f[CB]\-\-add\-modules\f[B]\f[R]
استفاده کنید.
این کار زمانی ضروری است که کدی را کامپایل می‌کنید که در یک ماژول نیست یا در یک ماژول خودکار است و کد به API موجود در ماژول‌های اضافی ارجاع می‌دهد.
.PP
اگر می‌خواهید مجموعه ماژول‌های موجود در کامپایل خود را محدود کنید، از گزینه
\f[B]\f[CB]\-\-limit\-modules\f[B]\f[R]
استفاده کنید.
این کار زمانی مفید است که بخواهید اطمینان حاصل کنید کدی که کامپایل می‌کنید قادر به اجرا روی سیستمی با تعداد محدودی ماژول نصب‌شده است.
.PP
اگر می‌خواهید کپسوله‌سازی را بشکنید و مشخص کنید که بسته‌های اضافی باید از یک ماژول صادرشده تلقی شوند، از گزینه
\f[B]\f[CB]\-\-add\-exports\f[B]\f[R]
استفاده کنید.
این کار ممکن است هنگام انجام تست جعبه سفید مفید باشد؛ اتکا به دسترسی به APIهای داخلی در کد محیط عملیاتی به شدت نهی می‌شود.
.PP
اگر می‌خواهید مشخص کنید که بسته‌های اضافی باید توسط یک ماژول موردنیاز تلقی شوند، از گزینه
\f[B]\f[CB]\-\-add\-reads\f[B]\f[R]
استفاده کنید.
این کار هنگام انجام تست جعبه سفید می‌تواند مفید باشد؛ اتکا به دسترسی به APIهای داخلی در کد محیط عملیاتی به شدت نهی می‌شود.
.PP
می‌توانید با استفاده از گزینه
\f[B]\f[CB]\-\-patch\-module\f[B]\f[R]
محتوای اضافی را به هر ماژولی وصله کنید.
برای جزئیات بیشتر به بخش [وصله‌زدن ماژول‌ها] مراجعه کنید.
.SH "جستجوی تعاریف ماژول، بسته و نوع (SEARCHING FOR MODULE, PACKAGE AND TYPE DECLARATIONS)"
برای کامپایل یک فایل منبع، کامپایلر اغلب به اطلاعاتی درباره یک ماژول یا نوع نیاز دارد، اما اعلان آن در فایل‌های منبع مشخص‌شده در خط فرمان موجود نیست.
.PP
دستور \f[CR]javac\f[R] به اطلاعات نوع برای هر کلاس یا رابطی که در فایل منبع استفاده، گسترش داده شده یا پیاده‌سازی شده است نیاز دارد.
این شامل کلاس‌ها و رابط‌هایی است که صریحاً در فایل منبع ذکر نشده‌اند، اما اطلاعاتی را از طریق وراثت ارائه می‌دهند.
.PP
برای مثال، هنگامی که زیرکلاسی از \f[CR]java.awt.Window\f[R] ایجاد می‌کنید، از کلاس‌های والد \f[CR]Window\f[R] نیز استفاده می‌کنید:
\f[CR]java.awt.Container\f[R]، \f[CR]java.awt.Component\f[R] و \f[CR]java.lang.Object\f[R].
.PP
هنگام کامپایل کد برای یک ماژول، کامپایلر همچنین باید اعلان آن ماژول را در دسترس داشته باشد.
.PP
یک جستجوی موفق ممکن است یک فایل کلاس، یک فایل منبع یا هر دو را پیدا کند.
اگر هر دو پیدا شوند، می‌توانید از گزینه \f[B]\f[CB]\-Xprefer\f[B]\f[R] استفاده کنید تا به کامپایلر دستور دهید از کدام یک استفاده کند.
.PP
اگر جستجویی یک فایل منبع را پیدا کرده و استفاده کند، به طور پیش‌فرض \f[CR]javac\f[R] آن فایل منبع را کامپایل می‌کند.
این رفتار را می‌توان با \f[B]\f[CB]\-implicit\f[B]\f[R] تغییر داد.
.PP
کامپایلر ممکن است تا پس از اتمام پردازش حاشیه‌نویسی، متوجه نیاز به برخی اطلاعات نوع نشود.
هنگامی که اطلاعات نوع در یک فایل منبع یافت می‌شود و هیچ گزینه \f[B]\f[CB]\-implicit\f[B]\f[R] مشخص نشده باشد، کامپایلر هشداری صادر می‌کند مبنی بر اینکه فایل بدون قرار گرفتن تحت پردازش حاشیه‌نویسی در حال کامپایل است.
برای غیرفعال کردن هشدار، یا فایل را در خط فرمان مشخص کنید (تا تحت پردازش حاشیه‌نویسی قرار گیرد) یا از گزینه \f[B]\f[CB]\-implicit\f[B]\f[R] برای تعیین اینکه آیا فایل‌های کلاس برای چنین فایل‌های منبعی تولید شوند یا خیر استفاده نمایید.
.PP
روشی که \f[CR]javac\f[R] تعاریف آن نوع‌ها را پیدا می‌کند به این بستگی دارد که آیا ارجاع درون کد یک ماژول وجود دارد یا خیر.
.SS "جستجوی مسیرهای مبتنی بر بسته (Searching Package Oriented Paths)"
هنگام جستجو برای یک فایل منبع یا کلاس در مسیری متشکل از مکان‌های مبتنی بر بسته، \f[CR]javac\f[R] هر مکان در مسیر را به نوبت برای بررسی احتمال وجود فایل بررسی می‌کند.
اولین رخداد یک فایل خاص، هرگونه رخداد بعدی فایل‌های هم‌نام را سایه‌اندازی (پنهان) می‌کند.
این سایه‌اندازی روی جستجو برای فایل‌هایی با نام متفاوت تأثیری ندارد.
این ویژگی هنگام جستجوی فایل‌های منبع که ممکن است در مکان‌های مختلفی مانند کد مشترک، کد مختص پلتفرم و کد تولیدشده گروه‌بندی شده باشند، راحت است.
همچنین می‌تواند هنگام تزریق نسخه‌های جایگزین یک فایل کلاس به یک بسته، برای مقاصد دیباگ یا سایر دلایل ابزارسازی مفید باشد.
اما می‌تواند خطرناک نیز باشد، مانند زمانی که نسخه‌های ناسازگار متفاوتی از یک کتابخانه در مسیر کلاس قرار می‌گیرند.
.SS "جستجوی مسیرهای مبتنی بر ماژول (Searching Module Oriented Paths)"
پیش از پیمایش هر مسیر ماژول برای یافتن تعاریف بسته یا نوع، \f[CR]javac\f[R] مسیرها و مکان‌های زیر را به صورت تنبلانه (lazy) بررسی می‌کند تا ماژول‌هایی را که در کامپایل استفاده خواهند شد مشخص کند:
.IP \(bu 2
مسیر منبع ماژول (گزینه \f[B]\f[CB]\-\-module\-source\-path\f[B]\f[R] را ببینید)
.IP \(bu 2
مسیر ماژول‌های قابل ارتقا (گزینه \f[B]\f[CB]\-\-upgrade\-module\-path\f[B]\f[R] را ببینید)
.IP \(bu 2
ماژول‌های سیستم (گزینه \f[B]\f[CB]\-\-system\f[B]\f[R] را ببینید)
.IP \(bu 2
مسیر ماژول کاربر (گزینه \f[B]\f[CB]\-\-module\-path\f[B]\f[R] را ببینید)
.PP
برای هر ماژول، اولین رخداد ماژول در طول پیمایش، هرگونه حضور بعدی یک ماژول هم‌نام را به طور کامل سایه‌اندازی (مخفی) می‌کند.
در حین مکان‌یابی ماژول‌ها، \f[CR]javac\f[R] قادر است بسته‌های صادرشده توسط ماژول را تعیین کند و به هر ماژول یک مسیر مبتنی بر بسته برای محتویات ماژول اختصاص دهد.
برای هر ماژول از پیش کامپایل‌شده، این مسیر معمولاً یک مدخل واحد برای یک دایرکتوری یا فایلی است که یک سلسله‌مراتب دایرکتوری‌مانند داخلی را فراهم می‌کند، مانند یک فایل JAR.
بنابراین، هنگام جستجو برای نوعی که در بسته‌ای قرار دارد که مشخص شده توسط یک ماژول صادر می‌شود، \f[CR]javac\f[R] می‌تواند تعریف را مستقیماً و به طور کارآمد پیدا کند.
.SS "جستجو برای اعلان یک ماژول (Searching for the Declaration of a Module)"
اگر ماژول قبلاً کامپایل شده باشد، اعلان ماژول در فایلی به نام \f[CR]module\-info.class\f[R] در ریشه سلسله‌مراتب بسته برای محتوای ماژول قرار دارد.
.PP
اگر ماژول یکی از ماژول‌های در حال کامپایل باشد، اعلان ماژول یا فایل \f[CR]module\-info.class\f[R] در ریشه سلسله‌مراتب بسته برای ماژول در دایرکتوری خروجی کلاس خواهد بود، یا فایل \f[CR]module\-info.java\f[R] در یکی از مکان‌های موجود در مسیر منبع یا مسیر منبع ماژول برای آن ماژول خواهد بود.
.SS "جستجو برای اعلان یک نوع وقتی ارجاع در ماژول نیست (Searching for the Declaration of a Type When the Reference is not in a Module)"
هنگام جستجو برای نوعی که در کدی خارج از ماژول ارجاع داده شده است، \f[CR]javac\f[R] مکان‌های زیر را بررسی می‌کند:
.IP \(bu 2
کلاس‌های پلتفرم (یا انواع موجود در بسته‌های صادرشده ماژول‌های پلتفرم) (این فقط برای فایل‌های کلاس کامپایل‌شده است.)
.IP \(bu 2
انواع موجود در بسته‌های صادرشده هر ماژولی در مسیر ماژول، در صورت وجود. (این فقط برای فایل‌های کلاس کامپایل‌شده است.)
.IP \(bu 2
انواع موجود در بسته‌های روی مسیر کلاس و/یا مسیر منبع:
.RS 2
.IP \(bu 2
اگر هر دو مشخص شده باشند، \f[CR]javac\f[R] به دنبال فایل‌های کلاس کامپایل‌شده در مسیر کلاس و به دنبال فایل‌های منبع در مسیر منبع می‌گردد.
.IP \(bu 2
اگر مسیر کلاس مشخص شده باشد اما مسیر منبع مشخص نشده باشد، \f[CR]javac\f[R] هم به دنبال فایل‌های کلاس کامپایل‌شده و هم فایل‌های منبع در مسیر کلاس می‌گردد.
.IP \(bu 2
اگر مسیر کلاس مشخص نشده باشد، پیش‌فرض دایرکتوری جاری است.
.RE
.PP
هنگام جستجو برای یک نوع در مسیر کلاس و/یا مسیر منبع، اگر هم یک فایل کلاس کامپایل‌شده و هم یک فایل منبع پیدا شوند، فایلی که اخیراً تغییر یافته به طور پیش‌فرض استفاده خواهد شد.
اگر فایل منبع جدیدتر باشد، کامپایل خواهد شد و ممکن است هر نسخه از پیش کامپایل‌شده فایل را رونویسی کند.
می‌توانید از گزینه \f[B]\f[CB]\-Xprefer\f[B]\f[R] برای تغییر این رفتار پیش‌فرض استفاده کنید.
.SS "جستجو برای اعلان یک نوع وقتی ارجاع در ماژول است (Searching for the Declaration of a Type When the Reference is in a Module)"
هنگام جستجو برای نوعی که در کد درون یک ماژول ارجاع داده شده است، \f[CR]javac\f[R] اعلان ماژول دربرگیرنده را بررسی می‌کند تا تعیین کند آیا آن نوع در بسته‌ای است که از ماژول دیگری صادر شده و برای ماژول دربرگیرنده قابل خواندن است یا خیر.
اگر چنین باشد، \f[CR]javac\f[R] مستقیماً به سراغ تعریف آن ماژول می‌رود تا تعریف نوع مورد نیاز را پیدا کند.
مگر اینکه آن ماژول، یکی دیگر از ماژول‌های در حال کامپایل باشد، \f[CR]javac\f[R] فقط به دنبال فایل‌های کلاس کامپایل‌شده خواهد گشت.
به عبارت دیگر، \f[CR]javac\f[R] به دنبال فایل‌های منبع در ماژول‌های پلتفرم یا ماژول‌های موجود در مسیر ماژول نخواهد گشت.
.PP
اگر نوع مورد ارجاع در ماژول خواندنی دیگری نباشد، \f[CR]javac\f[R] ماژول در حال کامپایل را بررسی می‌کند تا اعلان آن نوع را بیابد.
دستور \f[CR]javac\f[R] به دنبال اعلان نوع به صورت زیر خواهد گشت:
.IP \(bu 2
فایل‌های منبع تعیین‌شده در خط فرمان یا در مسیر منبع یا مسیر منبع ماژول.
.IP \(bu 2
فایل‌های از پیش کامپایل‌شده در دایرکتوری خروجی.
.SH "سلسله‌مراتب‌های دایرکتوری (DIRECTORY HIERARCHIES)"
دستور \f[CR]javac\f[R] عموماً فرض می‌کند که فایل‌های منبع و فایل‌های کلاس کامپایل‌شده در یک ساختار سلسله‌مراتبی دایرکتوری سیستم فایل یا در نوعی فایل که ساختار دایرکتوری داخلی دارد (مانند فایل JAR) سازمان‌دهی می‌شوند.
سه نوع ساختار سلسله‌مراتبی پشتیبانی می‌شود: \f[I]سلسله‌مراتب بسته\f[R]، \f[I]سلسله‌مراتب ماژول\f[R] و \f[I]سلسله‌مراتب منبع ماژول\f[R].
.PP
در حالی که \f[CR]javac\f[R] در مورد سازمان‌دهی کد منبع نسبتاً انعطاف‌پذیر است، فراتر از این انتظار که منبع در یک یا چند سلسله‌مراتب بسته سازمان‌دهی شود، و عموماً می‌تواند ساختارهای تجویزشده توسط محیط‌های توسعه و ابزارهای ساخت را در خود جای دهد، ابزارهای جاوا به طور کلی، و به ویژه \f[CR]javac\f[R] و راه‌انداز جاوا، در مورد سازمان‌دهی فایل‌های کلاس کامپایل‌شده سخت‌گیرتر هستند و بسته به شرایط در سلسله‌مراتب‌های بسته یا سلسله‌مراتب‌های ماژول سازمان‌دهی خواهند شد.
.PP
مکان این سلسله‌مراتب‌ها با گزینه‌های خط فرمان به \f[CR]javac\f[R] معرفی می‌شوند که نام آن‌ها معمولاً به \(dqpath\(dq ختم می‌شود، مانند \f[B]\f[CB]\-\-source\-path\f[B]\f[R] یا \f[B]\f[CB]\-\-class\-path\f[B]\f[R].
همچنین به عنوان یک قاعده کلی، گزینه‌های مسیری که نام آن‌ها شامل کلمه \f[CR]module\f[R] است، مانند \f[B]\f[CB]\-\-module\-path\f[B]\f[R]، برای تعیین سلسله‌مراتب‌های ماژول استفاده می‌شوند، اگرچه برخی از گزینه‌های مسیر مرتبط با ماژول اجازه می‌دهند یک سلسله‌مراتب بسته برای هر ماژول به طور جداگانه تعیین شود.
تمام گزینه‌های مسیر دیگر برای تعیین سلسله‌مراتب‌های بسته استفاده می‌شوند.
.PP
هنگامی که یک فایل JAR در مسیر کلاس کاربر دارای ویژگی مانیفست \f[CR]Class\-Path\f[R] باشد و فایل(های) JAR مشخص‌شده وجود داشته باشند، آن‌ها به طور خودکار پس از فایل JAR مربوطه در مسیر کلاس کاربر درج می‌شوند.
این قاعده همچنین به صورت بازگشتی برای هر فایل JAR جدیدِ یافت‌شده اعمال می‌شود.
برای جزئیات بیشتر به \f[B]مشخصات فایل‌های JAR (JAR File Specification)\f[R] مراجعه کنید.
.SS "سلسله‌مراتب بسته (Package Hierarchy)"
در یک سلسله‌مراتب بسته، دایرکتوری‌ها و زیردایرکتوری‌ها برای نمایش بخش‌های تشکیل‌دهنده نام بسته استفاده می‌شوند، و فایل منبع یا فایل کلاس کامپایل‌شده برای یک نوع به صورت فایلی با پسوند \f[CR].java\f[R] یا \f[CR].class\f[R] در داخلی‌ترین دایرکتوری ذخیره می‌شود.
.PP
برای مثال، در یک سلسله‌مراتب بسته، فایل منبع کلاسی به نام \f[CR]com.example.MyClass\f[R] در فایل \f[I]com/example/MyClass.java\f[R] ذخیره خواهد شد.
.SS "سلسله‌مراتب ماژول (Module Hierarchy)"
در یک سلسله‌مراتب ماژول، اولین سطح دایرکتوری‌ها بر اساس ماژول‌های موجود در سلسله‌مراتب نام‌گذاری می‌شوند؛ در درون هر یک از آن دایرکتوری‌ها، محتویات ماژول در سلسله‌مراتب‌های بسته سازمان‌دهی می‌شوند.
.PP
برای مثال، در یک سلسله‌مراتب ماژول، فایل کلاس کامپایل‌شده برای نوعی به نام \f[CR]com.example.MyClass\f[R] در ماژولی به نام \f[CR]my.library\f[R] در فایل \f[I]my.library/com/example/MyClass.class\f[R] ذخیره خواهد شد.
.PP
دایرکتوری‌های خروجی مختلف مورد استفاده توسط \f[CR]javac\f[R] (دایرکتوری خروجی کلاس، دایرکتوری خروجی منبع و دایرکتوری خروجی هدر بومی) همگی هنگامی که چندین ماژول در حال کامپایل هستند، در یک سلسله‌مراتب ماژول سازمان‌دهی خواهند شد.
.SS "سلسله‌مراتب منبع ماژول (Module Source Hierarchy)"
اگرچه منبع هر ماژول به صورت جداگانه باید همیشه در یک سلسله‌مراتب بسته سازمان‌دهی شود، ممکن است گروه‌بندی آن سلسله‌مراتب‌ها در یک سلسله‌مراتب منبع ماژول راحت باشد.
این ساختار شبیه به یک سلسله‌مراتب ماژول است، با این تفاوت که ممکن است دایرکتوری‌های واسطه‌ای بین دایرکتوری مربوط به ماژول و دایرکتوری ریشه سلسله‌مراتب بسته برای کد منبع ماژول وجود داشته باشد.
.PP
برای مثال، در یک سلسله‌مراتب منبع ماژول، فایل منبع نوعی به نام \f[CR]com.example.MyClass\f[R] در ماژولی به نام \f[CR]my.library\f[R] ممکن است در فایلی مانند \f[I]my.library/src/main/java/com/example/MyClass.java\f[R] ذخیره شود.
.SH "گزینه مسیر منبع ماژول (THE MODULE SOURCE PATH OPTION)"
گزینه \f[B]\f[CB]\-\-module\-source\-path\f[B]\f[R] دارای دو شکل است: یک \f[I]شکل مختص ماژول\f[R]، که در آن یک مسیر بسته برای هر ماژول حاوی کد برای کامپایل ارائه می‌شود، و یک شکل \f[I]الگوی ماژول\f[R]، که در آن مسیر منبع برای هر ماژول توسط یک الگو مشخص می‌شود.
شکل مختص ماژول عموماً زمانی که تعداد کمی ماژول دخیل هستند ساده‌تر است؛ شکل الگوی ماژول ممکن است زمانی که تعداد ماژول‌ها زیاد است و ماژول‌ها به شیوه‌ای منظم سازمان‌دهی شده‌اند که می‌توان با یک الگو توصیف کرد، راحت‌تر باشد.
.PP
چندین نمونه از گزینه \f[CR]\-\-module\-source\-path\f[R] را می‌توان ارائه داد که هر کدام از شکل الگوی ماژول یا شکل مختص ماژول استفاده می‌کنند، مشروط به محدودیت‌های زیر:
.IP \(bu 2
شکل الگوی ماژول حداکثر یک بار می‌تواند استفاده شود.
.IP \(bu 2
شکل مختص ماژول برای هر ماژول داده‌شده حداکثر یک بار می‌تواند استفاده شود.
.PP
اگر شکل مختص ماژول برای هر ماژولی استفاده شود، مسیر جستجوی مرتبط با آن بر هر مسیری که ممکن بود از شکل الگوی ماژول استنتاج شود ارجحیت دارد و آن را رونویسی می‌کند.
.SS "شکل مختص ماژول (Module\-specific form)"
شکل مختص ماژول امکان تعیین یک مسیر جستجوی صریح را برای هر ماژول خاص فراهم می‌کند.
این شکل به صورت زیر است:
.IP \(bu 2
\f[CR]\-\-module\-source\-path\f[R]
\f[I]module\-name\f[R]\f[CR]=\f[R]\f[I]file\-path\f[R]
(\f[I]path\-separator\f[R] \f[I]file\-path\f[R])*
.PP
نویسه جداکننده مسیر در ویندوز \f[CR];\f[R] و در سایر سیستم‌ها \f[CR]:\f[R] است.
مسیرهای ارائه‌شده برای ماژول باید ریشه یک سلسله‌مراتب بسته را برای محتویات ماژول مشخص کنند.
.PP
\f[B]نکته:\f[R] این شکل مشابه شکل مورد استفاده برای گزینه \f[B]\f[CB]\-\-patch\-module\f[B]\f[R] است.
.SS "شکل الگوی ماژول (Module\-pattern form)"
شکل الگوی ماژول امکان تعیین فشرده مسیر منبع ماژول را برای هر تعداد ماژول که به شیوه‌ای منظم سازمان‌دهی شده‌اند فراهم می‌کند.
.IP \(bu 2
\f[CR]\-\-module\-source\-path\f[R] \f[I]pattern\f[R]
.PP
الگو بر اساس قواعد زیر تعریف می‌شود که به ترتیب اعمال می‌گردند:
.IP \(bu 2
آرگومان به عنوان مجموعه‌ای از بخش‌ها در نظر گرفته می‌شود که با نویسه جداکننده مسیر (\f[CR];\f[R] در ویندوز و \f[CR]:\f[R] در سایر سیستم‌ها) جدا شده‌اند.
.IP \(bu 2
هر بخشی که حاوی آکولاد به فرم زیر باشد:
.RS 2
.IP
.EX
string1{alt1 ( ,alt2 )* } string2
.EE
.PP
به عنوان بخشی در نظر گرفته می‌شود که با مجموعه‌ای از بخش‌های حاصل از \(dqگسترش\(dq آکولادها جایگزین شده است:
.IP
.EX
string1 alt1 string2
string1 alt2 string2
و غیره...
.EE
.PP
آکولادها ممکن است تودرتو باشند.
.PP
این قاعده برای تمام کاربردهای این‌چنینی از آکولاد اعمال می‌شود.
.RE
.IP \(bu 2
هر بخش باید حداکثر یک ستاره (\f[CR]*\f[R]) داشته باشد.
اگر بخشی حاوی ستاره نباشد، فرض می‌شود که نویسه جداکننده فایل و یک ستاره به انتهای آن اضافه شده است.
.RS 2
.PP
برای هر ماژول \f[I]M\f[R]، مسیر منبع برای آن ماژول از مجموعه‌ای از بخش‌ها تشکیل می‌شود که با جایگزینی نام ماژول \f[I]M\f[R] به جای ستاره در هر بخش به دست می‌آید.
.PP
\f[B]نکته\f[R]: در این زمینه، ستاره فقط به عنوان یک نشانگر ویژه برای نشان دادن موقعیت نام ماژول در مسیر استفاده می‌شود.
نباید آن را با کاربرد \f[CR]*\f[R] به عنوان نویسه عمومی (wildcard) نام فایل در اکثر سیستم‌عامل‌ها اشتباه گرفت.
.RE
.SH "وصله‌زدن ماژول‌ها (PATCHING MODULES)"
دستور javac اجازه می‌دهد تا با استفاده از گزینه \f[B]\f[CB]\-\-patch\-module\f[B]\f[R]، هر محتوایی، چه به صورت منبع یا فرم کامپایل‌شده، به هر ماژولی وصله شود.
ممکن است بخواهید این کار را برای کامپایل پیاده‌سازی‌های جایگزین یک کلاس جهت وصله‌شدن در زمان اجرا به JVM انجام دهید، یا کلاس‌های اضافی را در ماژول تزریق کنید، مانند زمان تست.
.PP
شکل این گزینه به صورت زیر است:
.IP \(bu 2
\f[CR]\-\-patch\-module\f[R]
\f[I]module\-name\f[R]\f[CR]=\f[R]\f[I]file\-path\f[R]
(\f[I]path\-separator\f[R] \f[I]file\-path\f[R] )*
.PP
نویسه جداکننده مسیر در ویندوز \f[CR];\f[R] و در سایر سیستم‌ها \f[CR]:\f[R] است.
مسیرهای ارائه‌شده برای ماژول باید ریشه یک سلسله‌مراتب بسته را برای محتویات ماژول مشخص کنند.
.PP
این گزینه برای هر ماژول داده‌شده حداکثر یک بار می‌تواند ارائه شود.
هر محتوایی در این مسیر، هرگونه محتوای هم‌نام بعدی در مسیر و در ماژول وصله‌شده را پنهان می‌کند.
.PP
هنگام وصله‌زدن کد منبع به بیش از یک ماژول، گزینه \f[B]\f[CB]\-\-module\-source\-path\f[B]\f[R] نیز باید استفاده شود تا دایرکتوری خروجی در یک سلسله‌مراتب ماژول سازمان‌دهی شده و قادر به نگهداری فایل‌های کلاس کامپایل‌شده برای ماژول‌های در حال کامپایل باشد.
.SH "پردازش حاشیه‌نویسی (ANNOTATION PROCESSING)"
دستور \f[CR]javac\f[R] پشتیبانی مستقیمی از پردازش حاشیه‌نویسی ارائه می‌دهد.
.PP
رابط برنامه‌نویسی (API) برای پردازشگرهای حاشیه‌نویسی در بسته‌ها و زیربسته‌های \f[CR]javax.annotation.processing\f[R] و \f[CR]javax.lang.model\f[R] تعریف شده است.
.SS "نحوه کارکرد پردازش حاشیه‌نویسی (How Annotation Processing Works)"
پردازش حاشیه‌نویسی با استفاده از گزینه‌ای برای پیکربندی پردازش حاشیه‌نویسی مانند \f[B]\f[CB]\-processor\f[B]\f[R]، \f[B]\f[CB]\-\-processor\-path\f[B]\f[R]، \f[B]\f[CB]\-\-processor\-module\-path\f[B]\f[R] یا با فعال‌سازی صریح پردازش با گزینه‌های \f[B]\f[CB]\-proc:full\f[B]\f[R] یا \f[B]\f[CB]\-proc:only\f[B]\f[R] درخواست می‌شود.
پردازش حاشیه‌نویسی با استفاده از گزینه \f[B]\f[CB]\-proc:none\f[B]\f[R] غیرفعال می‌شود.
.PP
اگر پردازش حاشیه‌نویسی درخواست شود، کامپایلر به دنبال پردازشگرهای حاشیه‌نویسی موجود می‌گردد.
.PP
مسیر جستجو را می‌توان با گزینه \f[B]\f[CB]\-processorpath\f[B]\f[R] مشخص کرد.
اگر مسیری مشخص نشود، از مسیر کلاس کاربر استفاده می‌شود.
پردازشگرها با استفاده از فایل‌های پیکربندی ارائه‌دهنده سرویس به نام
\f[CR]META\-INF/services/javax.annotation.processing.Processor\f[R]
در مسیر جستجو پیدا می‌شوند.
این فایل‌ها باید حاوی نام پردازشگرهای حاشیه‌نویسی مورد استفاده باشند که در هر سطر یک نام ذکر شده است.
همچنین، پردازشگرها را می‌توان به صراحت با استفاده از گزینه \f[B]\f[CB]\-processor\f[B]\f[R] مشخص کرد.
.PP
پس از بررسی فایل‌های منبع و کلاس‌های موجود در خط فرمان برای تعیین حاشیه‌نویسی‌های موجود، کامپایلر از پردازشگرها پرس‌وجو می‌کند تا مشخص کند چه حاشیه‌نویسی‌هایی را پردازش می‌کنند.
هنگامی که تطابقی یافت شد، پردازشگر فراخوانی می‌شود.
یک پردازشگر می‌تواند حاشیه‌نویسی‌هایی را که پردازش می‌کند تصاحب (claim) کند، که در این صورت تلاش دیگری برای یافتن پردازشگرها برای آن حاشیه‌نویسی‌ها انجام نمی‌شود.
پس از اینکه همه حاشیه‌نویسی‌ها تصاحب شدند، کامپایلر به دنبال پردازشگرهای اضافی نمی‌گردد.
.PP
اگر پردازشگری فایل‌های منبع جدیدی تولید کند، دور دیگری از پردازش حاشیه‌نویسی رخ می‌دهد: هر فایل منبع تازه تولیدشده بررسی می‌شود و حاشیه‌نویسی‌ها مانند قبل پردازش می‌شوند.
هر پردازشگری که در دورهای قبلی فراخوانی شده باشد، در تمام دورهای بعدی نیز فراخوانی می‌شود.
این فرآیند تا زمانی که هیچ فایل منبع جدیدی تولید نشود ادامه می‌یابد.
.PP
پس از دوره‌ای که هیچ فایل منبع جدیدی تولید نمی‌شود، پردازشگرهای حاشیه‌نویسی برای آخرین بار فراخوانی می‌شوند تا فرصت تکمیل کارهای باقی‌مانده را داشته باشند.
در نهایت، مگر اینکه از گزینه \f[B]\f[CB]\-proc:only\f[B]\f[R] استفاده شده باشد، کامپایلر فایل‌های منبع اصلی و تمام فایل‌های تولیدشده را کامپایل می‌کند.
.PP
اگر از پردازشگر حاشیه‌نویسی استفاده می‌کنید که فایل‌های منبع اضافی را برای گنجاندن در کامپایل تولید می‌کند، می‌توانید یک ماژول پیش‌فرض را برای فایل‌های تازه تولیدشده مشخص کنید، تا زمانی که اعلان ماژول نیز تولید نشده است استفاده شود.
در این حالت، از گزینه
\f[B]\f[CB]\-\-default\-module\-for\-created\-files\f[B]\f[R]
استفاده کنید.
.SS "محیط کامپایل و محیط زمان اجرا (Compilation Environment and Runtime Environment)"
تعاریف موجود در فایل‌های منبع و فایل‌های کلاس قبلاً کامپایل‌شده توسط \f[CR]javac\f[R] در یک \f[I]محیط کامپایل\f[R] تحلیل می‌شوند که متمایز از \f[I]محیط زمان اجرا\f[R] مورد استفاده برای اجرای خود \f[CR]javac\f[R] است.
اگرچه شباهت عمدی بین بسیاری از گزینه‌های \f[CR]javac\f[R] و گزینه‌های هم‌نام برای \f[B]راه‌انداز\f[R] جاوا مانند \f[CR]\-\-class\-path\f[R]، \f[CR]\-\-module\-path\f[R] و غیره وجود دارد، درک این نکته مهم است که به طور کلی گزینه‌های \f[CR]javac\f[R] فقط بر محیطی که فایل‌های منبع در آن کامپایل می‌شوند تأثیر می‌گذارند و بر عملکرد خود \f[CR]javac\f[R] تأثیری ندارند.
.PP
تمایز بین محیط کامپایل و محیط زمان اجرا هنگام استفاده از پردازشگرهای حاشیه‌نویسی بسیار حائز اهمیت است.
اگرچه پردازشگرهای حاشیه‌نویسی عناصری (تعاریفی) را پردازش می‌کنند که در محیط کامپایل وجود دارند، خود پردازشگر حاشیه‌نویسی در محیط زمان اجرا اجرا می‌شود.
اگر پردازشگر حاشیه‌نویسی وابستگی‌هایی به کتابخانه‌هایی داشته باشد که در ماژول‌ها نیستند، این کتابخانه‌ها را می‌توان همراه با خود پردازشگر حاشیه‌نویسی در مسیر پردازشگر قرار داد.
(گزینه \f[B]\f[CB]\-\-processor\-path\f[B]\f[R] را ببینید.)
اگر پردازشگر حاشیه‌نویسی و وابستگی‌های آن در ماژول‌ها هستند، باید به جای آن از مسیر ماژول پردازشگر استفاده کنید.
(گزینه \f[B]\f[CB]\-\-processor\-module\-path\f[B]\f[R] را ببینید.)
هنگامی که این موارد ناکافی باشند، ممکن است نیاز به پیکربندی بیشتر محیط زمان اجرا باشد.
این کار را می‌توان به دو روش انجام داد:
.IP "1." 3
اگر \f[CR]javac\f[R] از خط فرمان فراخوانی شود، گزینه‌ها را می‌توان با قرار دادن پیشوند \f[B]\f[CB]\-J\f[B]\f[R] به زمان اجرای زیرین ارسال کرد.
.IP "2." 3
می‌توانید مستقیماً یک نمونه از ماشین مجازی جاوا را راه‌اندازی کنید و از گزینه‌های خط فرمان و API برای پیکربندی محیطی استفاده نمایید که در آن \f[CR]javac\f[R] می‌تواند از طریق یکی از \f[B]APIهای\f[R] خود فراخوانی شود.
.SH "کامپایل برای نگارش‌های قبلی پلتفرم (COMPILING FOR EARLIER RELEASES OF THE PLATFORM)"
دستور \f[CR]javac\f[R] می‌تواند کدهایی را که قرار است در سایر نگارش‌های پلتفرم استفاده شوند، با استفاده از گزینه \f[B]\f[CB]\-\-release\f[B]\f[R]، یا گزینه‌های \f[B]\f[CB]\-\-source\f[B]\f[R]/\f[CR]\-source\f[R] و \f[B]\f[CB]\-\-target\f[B]\f[R]/\f[CR]\-target\f[R] همراه با گزینه‌های اضافی برای تعیین کلاس‌های پلتفرم کامپایل کند.
.PP
بسته به نگارش مورد نظر پلتفرم، محدودیت‌هایی در مورد برخی از گزینه‌های قابل استفاده وجود دارد.
.IP \(bu 2
هنگام کامپایل برای JDK 8 و نگارش‌های قبلی، نمی‌توانید از هیچ گزینه‌ای که برای استفاده با سیستم ماژول در نظر گرفته شده است استفاده کنید.
این شامل تمام گزینه‌های زیر می‌شود:
.RS 2
.IP \(bu 2
\f[B]\f[CB]\-\-module\-source\-path\f[B]\f[R]، \f[B]\f[CB]\-\-upgrade\-module\-path\f[B]\f[R]، \f[B]\f[CB]\-\-system\f[B]\f[R]، \f[B]\f[CB]\-\-module\-path\f[B]\f[R]، \f[B]\f[CB]\-\-add\-modules\f[B]\f[R]، \f[B]\f[CB]\-\-add\-exports\f[B]\f[R]، \f[CR]\-\-add\-opens\f[R]، \f[B]\f[CB]\-\-add\-reads\f[B]\f[R]، \f[B]\f[CB]\-\-limit\-modules\f[B]\f[R]، \f[B]\f[CB]\-\-patch\-module\f[B]\f[R]
.PP
اگر از گزینه‌های \f[CR]\-\-source\f[R]/\f[CR]\-source\f[R] یا \f[CR]\-\-target\f[R]/\f[CR]\-target\f[R] استفاده می‌کنید، باید کلاس‌های پلتفرم مناسب را با استفاده از خانواده گزینه‌های boot class path نیز تنظیم کنید.
.RE
.IP \(bu 2
هنگام کامپایل برای JDK 9 و نگارش‌های جدیدتر، نمی‌توانید از هیچ گزینه‌ای که برای پیکربندی مسیر کلاس bootstrap در نظر گرفته شده است استفاده کنید.
این شامل تمام گزینه‌های زیر می‌شود:
.RS 2
.IP \(bu 2
\f[B]\f[CB]\-Xbootclasspath/p:\f[B]\f[R]، \f[B]\f[CB]\-Xbootclasspath\f[B]\f[R]، \f[B]\f[CB]\-Xbootclasspath/a:\f[B]\f[R]، \f[B]\f[CB]\-endorseddirs\f[B]\f[R]، \f[B]\f[CB]\-Djava.endorsed.dirs\f[B]\f[R]، \f[B]\f[CB]\-extdirs\f[B]\f[R]، \f[B]\f[CB]\-Djava.ext.dirs\f[B]\f[R]، \f[B]\f[CB]\-profile\f[B]\f[R]
.PP
اگر از گزینه‌های \f[CR]\-\-source\f[R]/\f[CR]\-source\f[R] یا \f[CR]\-\-target\f[R]/\f[CR]\-target\f[R] استفاده می‌کنید، باید کلاس‌های پلتفرم مناسب را با استفاده از گزینه \f[CR]\-\-system\f[R] برای تعیین مکان یک نگارش نصب‌شده مناسب از JDK نیز تنظیم کنید.
.RE
.PP
هنگام استفاده از گزینه \f[CR]\-\-release\f[R]، فقط می‌توان از API مستندشده و پشتیبانی‌شده برای آن نگارش استفاده کرد؛ شما نمی‌توانید از هیچ گزینه‌ای برای شکستن کپسوله‌سازی جهت دسترسی به کلاس‌های داخلی استفاده کنید.
.SH "رابط‌های برنامه‌نویسی (APIS)"
کامپایلر \f[CR]javac\f[R] می‌تواند با استفاده از یک API به سه روش مختلف فراخوانی شود:
.TP
\f[B]Java Compiler API\f[R]
این روش انعطاف‌پذیرترین راه را برای فراخوانی کامپایلر فراهم می‌کند، از جمله امکان کامپایل فایل‌های منبع ارائه‌شده در بافرهای حافظه یا سایر سیستم‌های فایل غیراستاندارد.
.TP
\f[B]ToolProvider API\f[R]
یک \f[CR]ToolProvider\f[R] برای \f[CR]javac\f[R] را می‌توان با فراخوانی \f[CR]ToolProvider.findFirst(\(dqjavac\(dq)\f[R] به دست آورد.
این یک شیء با عملکرد معادل ابزار خط فرمان برمی‌گرداند.
.RS
\f[B]نکته\f[R]: این API را نباید با API هم‌نام در بسته \f[B]\f[CB]javax.tools\f[B]\f[R] اشتباه گرفت.
.RE
.TP
\f[B]Legacy API برای javac\f[R]
این API فقط برای سازگاری عقبروی حفظ شده است.
تمام کدهای جدید باید از Java Compiler API یا ToolProvider API استفاده کنند.
.PP
\f[B]نکته:\f[R] تمام کلاس‌ها و متدهای دیگر موجود در بسته‌ای با نام‌هایی که با \f[CR]com.sun.tools.javac\f[R] شروع می‌شوند (زیربسته‌های \f[CR]com.sun.tools.javac\f[R]) کاملاً داخلی هستند و در هر زمان ممکن است تغییر کنند.
.SH "مثال‌های استفاده از کلیدهای \-XLINT (EXAMPLES OF USING \-XLINT KEYS)"
.TP
\f[CR]cast\f[R]
درباره تبدیل نوع‌های غیرضروری و اضافی هشدار می‌دهد، برای مثال:
.RS
.RS
.PP
\f[CR]String s = (String) \(dqHello!\(dq\f[R]
.RE
.RE
.TP
\f[CR]classfile\f[R]
درباره مسائل مربوط به محتویات فایل کلاس هشدار می‌دهد.
.TP
\f[CR]deprecation\f[R]
درباره استفاده از موارد منسوخ‌شده هشدار می‌دهد.
برای مثال:
.RS
.IP
.EX
java.util.Date myDate = new java.util.Date();
int currentDay = myDate.getDay();
.EE
متد \f[CR]java.util.Date.getDay\f[R] از زمان JDK 1.1 منسوخ شده است.
.RE
.TP
\f[CR]dep\-ann\f[R]
درباره مواردی که با کامنت Javadoc با تگ \f[CR]\(atdeprecated\f[R] مستند شده‌اند، اما فاقد حاشیه‌نویسی \f[CR]\(atDeprecated\f[R] هستند هشدار می‌دهد، برای مثال:
.RS
.IP
.EX
/**
  * \(atdeprecated As of Java SE 7, replaced by {\(atlink #newMethod()}
  */
public static void deprecatedMethod() { }
public static void newMethod() { }
.EE
.RE
.TP
\f[CR]divzero\f[R]
درباره تقسیم بر عدد صحیح ثابت 0 هشدار می‌دهد، برای مثال:
.RS
.RS
.PP
\f[CR]int divideByZero = 42 / 0;\f[R]
.RE
.RE
.TP
\f[CR]empty\f[R]
درباره دستورات خالی پس از دستورات \f[CR]if\f[R] هشدار می‌دهد، برای مثال:
.RS
.IP
.EX
class E {
    void m() {
         if (true) ;
    }
}
.EE
.RE
.TP
\f[CR]fallthrough\f[R]
بلوک‌های switch را برای حالت‌های افتادن (fall\-through) بررسی می‌کند و در صورت وجود، پیام هشداری ارائه می‌دهد.
حالت‌های افتادن، مواردی در یک بلوک switch به جز آخرین مورد هستند که کد آن‌ها شامل دستور \f[CR]break\f[R] نیست و اجازه می‌دهد اجرای کد از آن حالت به حالت بعدی بیفتد.
برای مثال، کد پس از برچسب case 1 در این بلوک switch با دستور \f[CR]break\f[R] پایان نمی‌یابد:
.RS
.IP
.EX
switch (x) {
case 1:
  System.out.println(\(dq1\(dq);
  // No break statement here.
case 2:
  System.out.println(\(dq2\(dq);
}
.EE
اگر هنگام کامپایل این کد از گزینه \f[CR]\-Xlint:fallthrough\f[R] استفاده شده باشد، کامپایلر هشداری درباره افتادن احتمالی به case همراه با شماره خط مورد نظر صادر می‌کند.
.RE
.TP
\f[CR]finally\f[R]
درباره بندهای \f[CR]finally\f[R] که نمی‌توانند به طور معمول کامل شوند هشدار می‌دهد، برای مثال:
.RS
.IP
.EX
public static int m() {
  try {
     throw new NullPointerException();
  }  catch (NullPointerException e) {
     System.err.println(\(dqCaught NullPointerException.\(dq);
     return 1;
   } finally {
     return 0;
   }
  }
.EE
کامپایلر برای بلوک \f[CR]finally\f[R] در این مثال یک هشدار تولید می‌کند.
هنگامی که متد \f[CR]int\f[R] فراخوانی می‌شود، مقدار 0 را برمی‌گرداند.
یک بلوک \f[CR]finally\f[R] هنگام خروج از بلوک \f[CR]try\f[R] اجرا می‌شود.
در این مثال، هنگامی که کنترل به بلوک \f[CR]catch\f[R] منتقل می‌شود، متد \f[CR]int\f[R] خارج می‌شود.
با این حال، بلوک \f[CR]finally\f[R] باید اجرا شود، بنابراین حتی با اینکه کنترل به خارج از متد منتقل شده بود، اجرا می‌شود.
.RE
.TP
\f[CR]options\f[R]
درباره مسائل مربوط به استفاده از گزینه‌های خط فرمان هشدار می‌دهد.
به بخش \f[B]کامپایل برای نگارش‌های قبلی پلتفرم\f[R] مراجعه کنید.
.TP
\f[CR]overrides\f[R]
درباره مسائل مربوط به بازنویسی (override) متدها هشدار می‌دهد.
برای مثال، دو کلاس زیر را در نظر بگیرید:
.RS
.IP
.EX
public class ClassWithVarargsMethod {
  void varargsMethod(String... s) { }
}

public class ClassWithOverridingMethod extends ClassWithVarargsMethod {
   \(atOverride
   void varargsMethod(String[] s) { }
}
.EE
کامپایلر هشداری مشابه زیر تولید می‌کند:
.IP
.EX
warning: [override] varargsMethod(String[]) in ClassWithOverridingMethod
overrides varargsMethod(String...) in ClassWithVarargsMethod; overriding
method is missing \(aq...\(aq
.EE
هنگامی که کامپایلر با یک متد \f[CR]varargs\f[R] مواجه می‌شود، پارامتر صوری \f[CR]varargs\f[R] را به یک آرایه تبدیل می‌کند.
در متد \f[CR]ClassWithVarargsMethod.varargsMethod\f[R]، کامپایلر پارامتر صوری \f[CR]String... s\f[R] را به پارامتر صوری \f[CR]String[] s\f[R] ترجمه می‌کند، آرایه‌ای که با پارامتر صوری متد \f[CR]ClassWithOverridingMethod.varargsMethod\f[R] مطابقت دارد.
در نتیجه، این مثال کامپایل می‌شود.
.RE
.TP
\f[CR]path\f[R]
درباره عناصر مسیر نامعتبر و دایرکتوری‌های مسیر ناموجود در خط فرمان (با توجه به مسیر کلاس، مسیر منبع و سایر مسیرها) هشدار می‌دهد.
چنین هشدارهایی را نمی‌توان با حاشیه‌نویسی \f[CR]\(atSuppressWarnings\f[R] نادیده گرفت.
برای مثال:
.RS
.IP \(bu 2
\f[B]لینوکس و مک‌او‌اس:\f[R]
\f[CR]javac \-Xlint:path \-classpath /nonexistentpath Example.java\f[R]
.IP \(bu 2
\f[B]ویندوز:\f[R]
\f[CR]javac \-Xlint:path \-classpath C:\(rsnonexistentpath Example.java\f[R]
.RE
.TP
\f[CR]processing\f[R]
درباره مسائل مربوط به پردازش حاشیه‌نویسی هشدار می‌دهد.
کامپایلر هنگامی که کلاسی دارای حاشیه‌نویسی باشد و از پردازشگر حاشیه‌نویسی استفاده کنید که نتواند آن نوع حاشیه‌نویسی را مدیریت کند، این هشدار را تولید می‌کند.
برای مثال، کد زیر یک پردازشگر حاشیه‌نویسی ساده است:
.RS
\f[B]فایل منبع AnnoProc.java\f[R]:
.IP
.EX
import java.util.*;
import javax.annotation.processing.*;
import javax.lang.model.*;
import javax.lang.model.element.*;

\(atSupportedAnnotationTypes(\(dqNotAnno\(dq)
public class AnnoProc extends AbstractProcessor {
  public boolean process(Set<? extends TypeElement> elems, RoundEnvironment renv){
     return true;
  }

  public SourceVersion getSupportedSourceVersion() {
     return SourceVersion.latest();
   }
}
.EE
\f[B]فایل منبع AnnosWithoutProcessors.java\f[R]:
.IP
.EX
\(atinterface Anno { }

\(atAnno
class AnnosWithoutProcessors { }
.EE
دستورات زیر پردازشگر حاشیه‌نویسی \f[CR]AnnoProc\f[R] را کامپایل می‌کنند، سپس این پردازشگر را روی فایل منبع \f[CR]AnnosWithoutProcessors.java\f[R] اجرا می‌نمایند:
.IP
.EX
javac AnnoProc.java
javac \-cp . \-Xlint:processing \-processor AnnoProc \-proc:only AnnosWithoutProcessors.java
.EE
هنگامی که کامپایلر پردازشگر حاشیه‌نویسی را روی فایل منبع \f[CR]AnnosWithoutProcessors.java\f[R] اجرا می‌کند، هشدار زیر را صادر می‌نماید:
.IP
.EX
warning: [processing] No processor claimed any of these annotations: Anno
.EE
برای رفع این مشکل، می‌توانید نام حاشیه‌نویسی تعریف‌شده و استفاده‌شده در کلاس \f[CR]AnnosWithoutProcessors\f[R] را از \f[CR]Anno\f[R] به \f[CR]NotAnno\f[R] تغییر دهید.
.RE
.TP
\f[CR]rawtypes\f[R]
درباره عملیات بررسی‌نشده روی انواع خام (raw types) هشدار می‌دهد.
دستور زیر یک هشدار \f[CR]rawtypes\f[R] تولید می‌کند:
.RS
.RS
.PP
\f[CR]void countElements(List l) { ... }\f[R]
.RE
مثال زیر هشدار \f[CR]rawtypes\f[R] تولید نمی‌کند:
.RS
.PP
\f[CR]void countElements(List<?> l) { ... }\f[R]
.RE
عبارت \f[CR]List\f[R] یک نوع خام است.
با این حال، \f[CR]List<?>\f[R] یک نوع پارامتری‌شده با نویسه عمومی نامحدود است.
از آنجا که \f[CR]List\f[R] یک رابط پارامتری‌شده است، همیشه آرگومان نوع آن را مشخص کنید.
در این مثال، آرگومان صوری \f[CR]List\f[R] با یک نویسه عمومی نامحدود (\f[CR]?\f[R]) به عنوان پارامتر نوع صوری آن مشخص شده است، به این معنی که متد \f[CR]countElements\f[R] می‌تواند هر نمونه‌ای از رابط \f[CR]List\f[R] را بپذیرد.
.RE
.TP
\f[CR]serial\f[R]
درباره عدم وجود تعاریف \f[CR]serialVersionUID\f[R] در کلاس‌های سریال‌پذیر هشدار می‌دهد.
برای مثال:
.RS
.IP
.EX
public class PersistentTime implements Serializable
{
  private Date time;

   public PersistentTime() {
     time = Calendar.getInstance().getTime();
   }

   public Date getTime() {
     return time;
   }
}
.EE
کامپایلر هشدار زیر را تولید می‌کند:
.IP
.EX
warning: [serial] serializable class PersistentTime has no definition of
serialVersionUID
.EE
اگر یک کلاس سریال‌پذیر فیلدی به نام \f[CR]serialVersionUID\f[R] را به صراحت تعریف نکند، محیط زمان اجرای سریال‌سازی مقدار پیش‌فرضی برای \f[CR]serialVersionUID\f[R] برای آن کلاس بر اساس جنبه‌های مختلف کلاس طبق مشخصات سریال‌سازی اشیاء جاوا محاسبه می‌کند.
با این حال، اکیداً توصیه می‌شود که تمام کلاس‌های سریال‌پذیر مقادیر \f[CR]serialVersionUID\f[R] را به صراحت تعریف کنند، زیرا فرآیند پیش‌فرض محاسبه این مقادیر نسبت به جزئیات کلاس که بسته به پیاده‌سازی کامپایلر متغیر است، بسیار حساس است.
در نتیجه، این ممکن است باعث بروز خطای غیرمنتظره \f[CR]InvalidClassExceptions\f[R] در هنگام بازیابی سریال‌سازی (deserialization) شود.
برای تضمین یک مقدار سازگار برای \f[CR]serialVersionUID\f[R] در پیاده‌سازی‌های مختلف کامپایلر جاوا، یک کلاس سریال‌پذیر باید یک مقدار صریح برای \f[CR]serialVersionUID\f[R] تعریف کند.
.RE
.TP
\f[CR]static\f[R]
درباره مسائل مربوط به استفاده از متغیرها و متدهای ایستا (static) هشدار می‌دهد، برای مثال:
.RS
.IP
.EX
class XLintStatic {
    static void m1() { }
    void m2() { this.m1(); }
}
.EE
کامپایلر هشدار زیر را تولید می‌کند:
.IP
.EX
warning: [static] static method should be qualified by type name,
XLintStatic, instead of by an expression
.EE
برای رفع این مشکل، می‌توانید متد \f[CR]static\f[R] به نام \f[CR]m1\f[R] را به صورت زیر فراخوانی کنید:
.RS
.PP
\f[CR]XLintStatic.m1();\f[R]
.RE
به عنوان روش جایگزین، می‌توانید کلیدواژه \f[CR]static\f[R] را از اعلان متد \f[CR]m1\f[R] حذف کنید.
.RE
.TP
\f[CR]this\-escape\f[R]
درباره نشت مرجع \f[CR]this\f[R] در سازنده‌ها قبل از مقداردهی اولیه کامل زیرکلاس هشدار می‌دهد.
برای مثال، این کلاس:
.RS
.IP
.EX
public class MyClass {
  public MyClass() {
    System.out.println(this.hashCode());
  }
}
.EE
هشدار زیر را تولید می‌کند:
.IP
.EX
MyClass.java:3: warning: [this\-escape] possible \(aqthis\(aq escape
                         before subclass is fully initialized
    System.out.println(this.hashCode());
                                    \(ha
.EE
هشدار نشت \(aqthis\(aq زمانی تولید می‌شود که یک سازنده کاری انجام دهد که ممکن است منجر به فراخوانی متد یک زیرکلاس قبل از بازگشت سازنده شود.
در چنین مواردی متد زیرکلاس روی نمونه‌ای که مقداردهی اولیه‌اش کامل نشده کار خواهد کرد.
در مثال بالا، زیرکلاسی از \f[CR]MyClass\f[R] که \f[CR]hashCode()\f[R] را برای گنجاندن فیلدهای خود بازنویسی می‌کند، در صورت فراخوانی به این شکل احتمالاً نتیجه نادرستی تولید خواهد کرد.
هشدارها تنها در صورتی تولید می‌شوند که زیرکلاسی بتواند خارج از ماژول جاری (یا بسته جاری، در صورت عدم وجود ماژول) در حال کامپایل وجود داشته باشد.
بنابراین، برای مثال، سازنده‌ها در کلاس‌های final و غیرعمومی هشداری تولید نمی‌کنند.
.RE
.TP
\f[CR]try\f[R]
درباره مسائل مربوط به استفاده از بلوک‌های \f[CR]try\f[R]، از جمله دستورات try\-with\-resources هشدار می‌دهد.
برای مثال، هشداری برای دستور زیر تولید می‌شود زیرا منبع \f[CR]ac\f[R] تعریف‌شده در بلوک \f[CR]try\f[R] استفاده نشده است:
.RS
.IP
.EX
try ( AutoCloseable ac = getResource() ) {    // do nothing}
.EE
.RE
.TP
\f[CR]unchecked\f[R]
جزئیات بیشتری برای هشدارهای تبدیل بررسی‌نشده که توسط مشخصات زبان جاوا الزامی شده‌اند ارائه می‌دهد، برای مثال:
.RS
.IP
.EX
List l = new ArrayList<Number>();
List<String> ls = l;       // unchecked warning
.EE
در حین پاک‌سازی نوع (type erasure)، انواع \f[CR]ArrayList<Number>\f[R] و \f[CR]List<String>\f[R] به ترتیب به \f[CR]ArrayList\f[R] و \f[CR]List\f[R] تبدیل می‌شوند.
متغیر \f[CR]ls\f[R] دارای نوع پارامتری‌شده \f[CR]List<String>\f[R] است.
هنگامی که \f[CR]List\f[R] مورد ارجاع توسط \f[CR]l\f[R] به \f[CR]ls\f[R] انتساب داده می‌شود، کامپایلر یک هشدار بررسی‌نشده (unchecked) صادر می‌کند.
در زمان کامپایل، کامپایلر و JVM نمی‌توانند تشخیص دهند که آیا \f[CR]l\f[R] به یک نوع \f[CR]List<String>\f[R] ارجاع می‌دهد یا خیر.
در این مورد، \f[CR]l\f[R] به نوع \f[CR]List<String>\f[R] ارجاع نمی‌دهد.
در نتیجه، آلودگی هیپ (heap pollution) رخ می‌دهد.
وضعیت آلودگی هیپ زمانی رخ می‌دهد که شیء \f[CR]List\f[R] یعنی \f[CR]l\f[R]، که نوع ایستای آن \f[CR]List<Number>\f[R] است، به شیء \f[CR]List\f[R] دیگری یعنی \f[CR]ls\f[R] که دارای نوع ایستای متفاوتی (\f[CR]List<String>\f[R]) است انتساب داده شود.
با این حال، کامپایلر همچنان این انتساب را مجاز می‌داند.
باید این انتساب را برای حفظ سازگاری عقبروی با نگارش‌هایی از Java SE که از جنریک‌ها (generics) پشتیبانی نمی‌کردند، مجاز بداند.
به دلیل پاک‌سازی نوع، هر دو \f[CR]List<Number>\f[R] و \f[CR]List<String>\f[R] به \f[CR]List\f[R] تبدیل می‌شوند.
در نتیجه، کامپایلر انتساب شیء \f[CR]l\f[R] را که نوع خام \f[CR]List\f[R] دارد، به شیء \f[CR]ls\f[R] مجاز می‌داند.
.RE
.TP
\f[CR]varargs\f[R]
درباره استفاده ناایمن از متدهای با تعداد متغیر آرگومان (\f[CR]varargs\f[R]) هشدار می‌دهد، به ویژه آن‌هایی که شامل آرگومان‌های غیرقابل تصدیق مجدد (non\-reifiable) هستند، برای مثال:
.RS
.IP
.EX
public class ArrayBuilder {
  public static <T> void addToList (List<T> listArg, T... elements) {
    for (T x : elements) {
      listArg.add(x);
    }
  }
}
.EE
یک نوع غیرقابل تصدیق مجدد، نوعی است که اطلاعات نوع آن در زمان اجرا به طور کامل در دسترس نیست.
کامپایلر هشدار زیر را برای تعریف متد \f[CR]ArrayBuilder.addToList\f[R] تولید می‌کند:
.IP
.EX
warning: [varargs] Possible heap pollution from parameterized vararg type T
.EE
هنگامی که کامپایلر با یک متد varargs مواجه می‌شود، پارامتر صوری \f[CR]varargs\f[R] را به یک آرایه ترجمه می‌کند.
با این حال، زبان برنامه‌نویسی جاوا اجازه ایجاد آرایه‌هایی از انواع پارامتری‌شده را نمی‌دهد.
در متد \f[CR]ArrayBuilder.addToList\f[R]، کامپایلر پارامتر صوری \f[CR]T...\f[R] را به پارامتر صوری \f[CR]T[]\f[R]، یعنی یک آرایه ترجمه می‌کند.
اما به دلیل پاک‌سازی نوع، کامپایلر پارامتر صوری \f[CR]varargs\f[R] را به عناصر \f[CR]Object[]\f[R] تبدیل می‌نماید.
در نتیجه، احتمال بروز آلودگی هیپ وجود دارد.
.RE