.\" Copyright (c) 1994, 2020, Oracle and/or its affiliates. All rights reserved.
.\" DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
.\"
.\" This code is free software; you can redistribute it and/or modify it
.\" under the terms of the GNU General Public License version 2 only, as
.\" published by the Free Software Foundation.
.\"
.\" This code is distributed in the hope that it will be useful, but WITHOUT
.\" ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
.\" FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
.\" version 2 for more details (a copy is included in the LICENSE file that
.\" accompanied this code).
.\"
.\" You should have received a copy of the GNU General Public License version
.\" 2 along with this work; if not, write to the Free Software Foundation,
.\" Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
.\"
.\" Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
.\" or visit www.oracle.com if you need additional information or have any
.\" questions.
.\"
.\" Automatically generated by Pandoc 2.3.1
.\"
.TH "JAVAC" "1" "2021" "JDK 17" "JDK Commands"
.hy
.SH "نام (NAME)"
.PP
javac \- خواندن اعلان‌های جاوا و کامپایل آن‌ها به فایل‌های کلاس
.SH "خلاصه دستور (SYNOPSIS)"
.PP
\f[CB]javac\f[R] [\f[I]options\f[R]] [\f[I]sourcefiles\-or\-classnames\f[R]]
.TP
.B \f[I]options\f[R]
گزینه‌های خط فرمان.
.RS
.RE
.TP
.B \f[I]sourcefiles\-or\-classnames\f[R]
فایل‌های منبع برای کامپایل (برای مثال، \f[CB]Shape.java\f[R]) یا نام کلاس‌های از پیش کامپایل‌شده برای پردازش حاشیه‌نویسی‌ها (برای مثال، \f[CB]geometry.MyShape\f[R]).
.RS
.RE
.SH "توضیحات (DESCRIPTION)"
.PP
دستور \f[CB]javac\f[R] \f[I]فایل‌های منبعی\f[R] را که حاوی اعلان‌های ماژول، بسته و نوع نوشته‌شده به زبان برنامه‌نویسی جاوا هستند می‌خواند، و آن‌ها را به \f[I]فایل‌های کلاس\f[R] که روی ماشین مجازی جاوا اجرا می‌شوند کامپایل می‌کند.
.PP
دستور \f[CB]javac\f[R] همچنین می‌تواند \f[B]حاشیه‌نویسی‌ها را پردازش کند\f[R] که در فایل‌های منبع و کلاس‌های جاوا قرار دارند.
.PP
فایل‌های منبع باید پسوند نام فایل \f[CB]\&.java\f[R] داشته باشند.
فایل‌های کلاس دارای پسوند نام فایل \f[CB]\&.class\f[R] هستند.
به‌طور معمول هم فایل‌های منبع و هم فایل‌های کلاس نام‌هایی دارند که محتوای آن‌ها را مشخص می‌کند.
برای مثال، کلاسی به نام \f[CB]Shape\f[R] در یک فایل منبع به نام \f[CB]Shape.java\f[R] اعلان می‌شود و در یک فایل کلاس با نام \f[CB]Shape.class\f[R] کامپایل خواهد شد.
.PP
دو روش برای مشخص کردن فایل‌های منبع برای \f[CB]javac\f[R] وجود دارد:
.IP \[bu] 2
برای تعداد کمی از فایل‌های منبع، می‌توانید نام فایل‌های آن‌ها را در خط فرمان فهرست کنید.
.IP \[bu] 2
برای تعداد زیادی از فایل‌های منبع، می‌توانید از گزینهٔ \f[B]\f[BC]\@\f[B]\f[BI]filename\f[B]\f[R] در خط فرمان استفاده کنید تا یک \f[I]فایل آرگومان\f[R] را مشخص نمایید که نام‌های فایل‌ها در آن فهرست شده است.
برای شرح این گزینه به \f[B]Standard Options\f[R] و برای شرح فایل‌های آرگومان \f[CB]javac\f[R] به \f[B]Command\-Line Argument Files\f[R] مراجعه کنید.
.PP
ترتیب فایل‌های منبع مشخص‌شده در خط فرمان یا در یک فایل آرگومان اهمیتی ندارد.
\f[CB]javac\f[R] فایل‌ها را با یکدیگر، به‌عنوان یک گروه، کامپایل می‌کند و وابستگی‌های میان اعلان‌ها در فایل‌های منبع گوناگون را به‌طور خودکار رفع خواهد کرد.
.PP
\f[CB]javac\f[R] انتظار دارد که فایل‌های منبع در یک یا چند سلسله‌مراتب دایرکتوری در سیستم فایل سازمان‌دهی شده باشند، همان‌گونه که در \f[B]Arrangement of Source Code\f[R] شرح داده شده است.
.PP
برای کامپایل یک فایل منبع، \f[CB]javac\f[R] باید اعلان هر کلاس یا رابطی را که توسط کد موجود در فایل منبع استفاده، گسترش داده شده، یا پیاده‌سازی شده است بیابد.
این کار به \f[CB]javac\f[R] اجازه می‌دهد بررسی کند که آیا کد، حق دسترسی به آن کلاس‌ها و رابط‌ها را دارد یا خیر.
به‌جای مشخص کردن صریح فایل‌های منبع آن کلاس‌ها و رابط‌ها، می‌توانید از گزینه‌های خط فرمان استفاده کنید تا به \f[CB]javac\f[R] بگویید کجا به دنبال فایل‌های منبع آن‌ها جستجو کند.
اگر پیش‌تر آن فایل‌های منبع را کامپایل کرده‌اید، می‌توانید از گزینه‌ها استفاده کنید تا به \f[CB]javac\f[R] بگویید کجا به دنبال فایل‌های کلاس متناظر بگردد.
این گزینه‌ها، که همگی نام‌هایی ختم‌شده به \(lqpath\(rq دارند، در \f[B]Standard Options\f[R]، و با جزئیات بیشتر در \f[B]Configuring a Compilation\f[R] و \f[B]Searching for Module, Package and Type Declarations\f[R] توضیح داده شده‌اند.
.PP
به‌طور پیش‌فرض، \f[CB]javac\f[R] هر فایل منبع را به یک فایل کلاس در همان دایرکتوریِ فایل منبع کامپایل می‌کند.
با این حال، توصیه می‌شود یک دایرکتوری مقصد جداگانه را با گزینهٔ \f[B]\f[BC]\-d\f[B]\f[R] مشخص کنید.
.PP
\f[B]گزینه‌ها\f[R] و \f[B]متغیرهای محیطی\f[R] خط فرمان نیز نحوهٔ انجام وظایف مختلف توسط \f[CB]javac\f[R] را کنترل می‌کنند:
.IP \[bu] 2
کامپایل کد برای اجرا روی نگارش‌های قدیمی‌تر JDK.
.IP \[bu] 2
کامپایل کد برای اجرا زیر نظر یک اشکال‌زدا (debugger).
.IP \[bu] 2
بررسی اشکالات نگارشی و سبک کدنویسی در کد منبع جاوا.
.IP \[bu] 2
بررسی مشکلات موجود در یادداشت‌های \f[CB]javadoc\f[R]
(\f[CB]/**\ ...\ */\f[R]).
.IP \[bu] 2
پردازش حاشیه‌نویسی‌ها در فایل‌های منبع و فایل‌های کلاس.
.IP \[bu] 2
ارتقا و وصله‌زدن ماژول‌ها در محیط زمان کامپایل.
.PP
\f[CB]javac\f[R] از قابلیت \f[B]Compiling for Earlier Releases Of The Platform\f[R] پشتیبانی می‌کند و همچنین می‌تواند از طریق کد جاوا با استفاده از مجموعه‌ای از \f[B]API\f[R]ها فراخوانی شود..SH "گزینه‌ها (OPTIONS)"
.PP
\f[CB]javac\f[R] شامل \f[B]گزینه‌های استاندارد\f[R] و \f[B]گزینه‌های اضافی\f[R] است که یا غیراستاندارد هستند یا برای استفاده‌های پیشرفته در نظر گرفته شده‌اند.
.PP
برخی گزینه‌ها یک یا چند آرگومان می‌گیرند.
اگر یک آرگومان حاوی فاصله یا دیگر نویسه‌های فاصله‌ساز باشد، مقدار آن باید طبق قراردادهای محیطی که برای فراخوانی javac استفاده می‌شود، نقل‌قول (کوتیشن) شود.
اگر گزینه با یک خط تیره تکی (\f[CB]\-\f[R]) آغاز شود، آرگومان باید بسته به نوع گزینه، یا بلافاصله پس از نام گزینه بیاید، یا با یک دونقطه (\f[CB]:\f[R]) یا فاصله از آن جدا شود.
اگر گزینه با دو خط تیره (\f[CB]\-\-\f[R]) آغاز شود، آرگومان می‌تواند با فاصله یا با نویسهٔ مساوی (\f[CB]=\f[R]) بدون هیچ فاصلهٔ اضافی جدا شود.
برای نمونه:
.IP
.nf
\f[CB]
\-Aname="J.\ Duke"
\-proc:only
\-d\ myDirectory
\-\-module\-version\ 3
\-\-module\-version=3
\f[R]
.fi
.PP
در فهرست‌های گزینه‌های زیر، آرگومان \f[I]path\f[R] نشان‌دهندهٔ یک مسیر جست‌وجو است که از فهرستی از مکان‌های فایل‌سیستم تشکیل شده و با نویسهٔ جداکنندهٔ مسیر پلتفرم (نقطه‌ویرگول \f[CB];\f[R] در Windows، یا دونقطه \f[CB]:\f[R] در سایر سیستم‌ها) از یکدیگر جدا می‌شوند. بسته به نوع گزینه، مکان‌های فایل‌سیستم می‌توانند دایرکتوری‌ها، فایل‌های JAR یا فایل‌های JMOD باشند.
.SS "گزینه‌های استاندارد (Standard Options)"
.TP
.B \f[CB]\@\f[R]\f[I]filename\f[R]
گزینه‌ها و نام‌های فایل را از یک فایل می‌خواند.
برای کوتاه‌تر یا ساده‌تر کردن دستور \f[CB]javac\f[R]، می‌توانید یک یا چند فایل را که حاوی آرگومان‌های دستور \f[CB]javac\f[R] هستند (به جز گزینه‌های \f[B]\f[BC]\-J\f[B]\f[R]) مشخص کنید.
این کار به شما امکان می‌دهد دستورهای \f[CB]javac\f[R] با هر طولی را روی هر سیستم‌عاملی ایجاد کنید.
بخش \f[B]Command\-Line Argument Files\f[R] را ببینید.
.RS
.RE
.TP
.B \f[CB]\-A\f[R]\f[I]key\f[R][\f[CB]=\f[R]\f[I]value\f[R]]
گزینه‌هایی را برای ارسال به پردازنده‌های حاشیه‌نویسی (annotation processors) مشخص می‌کند.
این گزینه‌ها مستقیماً توسط \f[CB]javac\f[R] تفسیر نمی‌شوند، بلکه برای استفاده در دسترس هر یک از پردازنده‌ها قرار می‌گیرند.
مقدار \f[I]key\f[R] باید یک یا چند شناسه باشد که با نقطه (\f[CB]\&.\f[R]) از هم جدا شده‌اند.
.RS
.RE
.TP
.B \f[CB]\-\-add\-modules\f[R] \f[I]module\f[R]\f[CB],\f[R]\f[I]module\f[R]
ماژول‌های ریشه را علاوه بر ماژول‌های اولیه برای تحلیل (resolve) مشخص می‌کند، یا اگر \f[I]module\f[R] برابر با \f[CB]ALL\-MODULE\-PATH\f[R] باشد، همهٔ ماژول‌های موجود در مسیر ماژول را تعیین می‌کند.
.RS
.RE
.TP
.B \f[CB]\-\-boot\-class\-path\f[R] \f[I]path\f[R] یا \f[CB]\-bootclasspath\f[R] \f[I]path\f[R]
مکان فایل‌های کلاس bootstrap را رونویسی (جایگزین) می‌کند.
.RS
.PP
\f[B]نکته:\f[R] این گزینه تنها هنگام کامپایل برای نسخه‌های پیش از JDK 9 قابل استفاده است.
در صورت لزوم، برای جزئیات به توضیحات در \f[B]\f[BC]\-\-release\f[B]\f[R]، \f[B]\f[BC]\-source\f[B]\f[R] یا \f[B]\f[BC]\-target\f[B]\f[R] مراجعه کنید.
برای JDK 9 یا جدیدتر، \f[B]\f[BC]\-\-system\f[B]\f[R] را ببینید.
.RE
.TP
.B \f[CB]\-\-class\-path\f[R] \f[I]path\f[R]، \f[CB]\-classpath\f[R] \f[I]path\f[R] یا \f[CB]\-cp\f[R] \f[I]path\f[R]
محل یافتن فایل‌های کلاس کاربر و پردازنده‌های حاشیه‌نویسی را مشخص می‌کند.
این مسیر کلاس، مسیر کلاس کاربر در متغیر محیطی \f[CB]CLASSPATH\f[R] را جایگزین می‌کند.
.RS
.IP \[bu] 2
اگر \f[CB]\-\-class\-path\f[R]، \f[CB]\-classpath\f[R] یا \f[CB]\-cp\f[R] مشخص نشده باشند، مسیر کلاس کاربر برابر با مقدار متغیر محیطی \f[CB]CLASSPATH\f[R] (در صورت تنظیم بودن) یا دایرکتوری جاری خواهد بود.
.IP \[bu] 2
هنگامی که کد برای ماژول‌ها کامپایل نمی‌شود، اگر گزینهٔ \f[B]\f[BC]\-\-source\-path\f[B]\f[R] یا \-sourcepath` مشخص نشده باشد، مسیر کلاس کاربر برای فایل‌های منبع نیز جست‌وجو می‌شود.
.IP \[bu] 2
اگر گزینهٔ \f[B]\f[BC]\-processorpath\f[B]\f[R] مشخص نشده باشد، مسیر کلاس برای پردازنده‌های حاشیه‌نویسی نیز جست‌وجو می‌شود.
.RE
.TP
.B \f[CB]\-d\f[R] \f[I]directory\f[R]
دایرکتوری مقصد (یا \f[I]دایرکتوری خروجی کلاس\f[R]) را برای فایل‌های کلاس تعیین می‌کند.
اگر یک کلاس بخشی از یک بسته (package) باشد، \f[CB]javac\f[R] فایل کلاس را در زیردایرکتوری متناسب با نام ماژول (در صورت وجود) و نام بسته قرار می‌دهد.
اگر دایرکتوری و زیردایرکتوری‌های لازم از قبل وجود نداشته باشند، ایجاد خواهند شد.
.RS
.PP
اگر گزینهٔ \f[CB]\-d\f[R] مشخص نشود، \f[CB]javac\f[R] هر فایل کلاس را در همان دایرکتوری قرار می‌دهد که فایل منبع مولد آن در آن قرار دارد.
.PP
به جز مواردی که کد برای چندین ماژول کامپایل می‌شود، محتویات دایرکتوری خروجی کلاس در یک سلسله‌مراتب بسته‌ای سازمان‌دهی می‌شوند.
هنگام کامپایل کد برای چندین ماژول، محتویات دایرکتوری خروجی در یک سلسله‌مراتب ماژولی سازمان‌دهی می‌شوند؛ به‌طوری‌که محتویات هر ماژول در یک زیردایرکتوری جداگانه قرار می‌گیرد و هر کدام در یک سلسله‌مراتب بسته‌ای سازمان می‌یابند.
.PP
\f[B]نکته:\f[R] هنگام کامپایل کد برای یک یا چند ماژول، دایرکتوری خروجی کلاس هنگام جست‌وجو برای کلاس‌های از پیش کامپایل‌شده به‌طور خودکار بررسی می‌شود.
هنگامی که برای ماژول‌ها کامپایل صورت نمی‌گیرد، برای حفظ سازگاری با گذشته، دایرکتوری به‌طور خودکار برای کلاس‌های از پیش کامپایل‌شده بررسی \f[I]نمی‌شود\f[R]؛ از این رو توصیه می‌شود دایرکتوری خروجی کلاس را با استفاده از گزینهٔ \f[CB]\-\-class\-path\f[R] یا یکی از اشکال جایگزین آن، به عنوان یکی از مکان‌های مسیر کلاس کاربر مشخص کنید.
.RE
.TP
.B \f[CB]\-deprecation\f[R]
توضیحی از هر بار استفاده یا رونویسی (override) از یک عضو یا کلاس منسوخ‌شده (deprecated) را نشان می‌دهد.
بدون گزینهٔ \f[CB]\-deprecation\f[R]، دستور \f[CB]javac\f[R] خلاصه‌ای از فایل‌های منبعی را نمایش می‌دهد که از اعضا یا کلاس‌های منسوخ‌شده استفاده یا آن‌ها را رونویسی می‌کنند.
گزینهٔ \f[CB]\-deprecation\f[R] کوتاه‌نوشت \f[CB]\-Xlint:deprecation\f[R] است.
.RS
.RE
.TP
.B \f[CB]\-\-enable\-preview\f[R]
ویژگی‌های پیش‌نمایش زبان را فعال می‌کند.
همراه با \f[B]\f[BC]\-source\f[B]\f[R] یا \f[B]\f[BC]\-\-release\f[B]\f[R] استفاده می‌شود.
.RS
.RE
.TP
.B \f[CB]\-encoding\f[R] \f[I]encoding\f[R]
کدگذاری نویسه‌های مورد استفاده توسط فایل‌های منبع، مانند EUC\-JP و UTF\-8 را تعیین می‌کند.
اگر گزینهٔ \f[CB]\-encoding\f[R] مشخص نشود، مبدل پیش‌فرض پلتفرم به کار گرفته می‌شود.
.RS
.RE
.TP
.B \f[CB]\-endorseddirs\f[R] \f[I]directories\f[R]
مکان مسیر استانداردهای تأییدشده (endorsed standards path) را جایگزین می‌کند.
.RS
.PP
\f[B]نکته:\f[R] این گزینه تنها هنگام کامپایل برای نسخه‌های پیش از JDK 9 قابل استفاده است.
در صورت لزوم، برای جزئیات به توضیحات \f[B]\f[BC]\-\-release\f[B]\f[R]، \f[B]\f[BC]\-source\f[B]\f[R] یا \f[B]\f[BC]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
.B \f[CB]\-extdirs\f[R] \f[I]directories\f[R]
مکان افزونه‌های (extensions) نصب‌شده را جایگزین می‌کند.
\f[CB]directories\f[R] فهرستی از دایرکتوری‌ها است که با جداکنندهٔ مسیر پلتفرم (\f[CB];\f[R] در Windows، و در غیر این صورت \f[CB]:\f[R]) جدا شده‌اند.
تمام فایل‌های JAR موجود در دایرکتوری‌های مشخص‌شده برای یافتن فایل‌های کلاس جست‌وجو می‌شوند.
همهٔ فایل‌های JAR یافت‌شده بخشی از مسیر کلاس خواهند شد.
.RS
.PP
اگر برای نسخه‌ای از پلتفرم کامپایل می‌کنید که از سازوکار افزونه (Extension Mechanism) پشتیبانی می‌کند، این گزینه دایرکتوری‌های حاوی کلاس‌های افزونه را مشخص می‌کند.
بخش [Compiling for Other Releases of the Platform] را ببینید.
.PP
\f[B]نکته:\f[R] این گزینه تنها هنگام کامپایل برای نسخه‌های پیش از JDK 9 قابل استفاده است.
در صورت لزوم، برای جزئیات به توضیحات \f[B]\f[BC]\-\-release\f[B]\f[R]، \f[B]\f[BC]\-source\f[B]\f[R] یا \f[B]\f[BC]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
.B \f[CB]\-g\f[R]
تمامی اطلاعات اشکال‌زدایی، از جمله متغیرهای محلی را تولید می‌کند.
به‌طور پیش‌فرض، فقط اطلاعات شمارهٔ خط و فایل منبع تولید می‌شود.
.RS
.RE
.TP
.B \f[CB]\-g:\f[R][\f[CB]lines\f[R], \f[CB]vars\f[R], \f[CB]source\f[R]]
تنها آن دسته از اطلاعات اشکال‌زدایی را تولید می‌کند که با فهرست کلیدواژه‌های جداشده با ویرگول مشخص شده‌اند.
کلیدواژه‌های معتبر عبارتند از:
.RS
.TP
.B \f[CB]lines\f[R]
اطلاعات اشکال‌زدایی شمارهٔ خط.
.RS
.RE
.TP
.B \f[CB]vars\f[R]
اطلاعات اشکال‌زدایی متغیر محلی.
.RS
.RE.TP
.B \f[CB]source\f[R]
اطلاعات اشکال‌زدایی فایل مبدأ.
.RS
.RE
.RE
.TP
.B \f[CB]\-g:none\f[R]
اطلاعات اشکال‌زدایی تولید نمی‌کند.
.RS
.RE
.TP
.B \f[CB]\-h\f[R] \f[I]directory\f[R]
محل قرارگیری فایل‌های سرایند محلی (native) تولیدشده را مشخص می‌کند.
.RS
.PP
هنگامی که این گزینه را مشخص می‌کنید، یک فایل سرایند محلی برای هر کلاسی که شامل متدهای محلی است یا دارای یک یا چند ثابت حاشیه‌نویسی‌شده با حاشیه‌نویسی \f[B]\f[BC]java.lang.annotation.Native\f[B]\f[R] باشد، تولید می‌شود.
اگر کلاس بخشی از یک بسته باشد، کامپایلر فایل سرایند محلی را در زیرشاخه‌ای قرار می‌دهد که نام ماژول (در صورت لزوم) و نام بسته را بازتاب می‌دهد.
دایرکتوری و زیرشاخه‌های مورد نیاز، در صورت عدم وجود، ایجاد خواهند شد.
.RE
.TP
.B \f[CB]\-\-help\f[R]، \f[CB]\-help\f[R] یا \f[CB]\-?\f[R]
خلاصه‌ای از گزینه‌های استاندارد را چاپ می‌کند.
.RS
.RE
.TP
.B \f[CB]\-\-help\-extra\f[R] یا \f[CB]\-X\f[R]
خلاصه‌ای از مجموعهٔ گزینه‌های اضافی را چاپ می‌کند.
.RS
.RE
.TP
.B \f[CB]\-\-help\-lint\f[R]
کلیدهای پشتیبانی‌شده برای گزینهٔ \f[CB]\-Xlint\f[R] را چاپ می‌کند.
.RS
.RE
.TP
.B \f[CB]\-implicit:\f[R][\f[CB]none\f[R], \f[CB]class\f[R]]
مشخص می‌کند که آیا برای فایل‌های ارجاع‌داده‌شده به صورت ضمنی، فایل کلاس تولید شود یا خیر:
.RS
.IP \[bu] 2
\f[CB]\-implicit:class\f[R] \-\-\- فایل‌های کلاس را به طور خودکار تولید می‌کند.
.IP \[bu] 2
\f[CB]\-implicit:none\f[R] \-\-\- از تولید فایل کلاس جلوگیری می‌کند.
.PP
اگر این گزینه مشخص نشود، به صورت پیش‌فرض فایل‌های کلاس به طور خودکار تولید می‌شوند.
در این حالت، اگر در هنگام انجام پردازش حاشیه‌نویسی هرگونه فایل کلاسی تولید شود، کامپایلر یک هشدار صادر می‌کند.
در صورتی که گزینهٔ \f[CB]\-implicit\f[R] به طور صریح تنظیم شده باشد، این هشدار صادر نخواهد شد.
بخش \f[B]Searching for Module, Package and Type Declarations\f[R] را ببینید.
.RE
.TP
.B \f[CB]\-J\f[R]\f[I]option\f[R]
گزینهٔ \f[I]option\f[R] را به سیستم زمان اجرا (runtime) منتقل می‌کند، که در آن \f[I]option\f[R] یکی از گزینه‌های جاوا است که در دستور \f[B]java\f[R] شرح داده شده است.
برای مثال، \f[CB]\-J\-Xms48m\f[R] حافظهٔ راه‌اندازی را روی ۴۸ مگابایت تنظیم می‌کند.
.RS
.PP
\f[B]نکته:\f[R] متغیر محیطی \f[CB]CLASSPATH\f[R]، گزینهٔ \f[CB]\-classpath\f[R]، گزینهٔ \f[CB]\-bootclasspath\f[R] و گزینهٔ \f[CB]\-extdirs\f[R] کلاس‌های مورد استفاده برای اجرای \f[CB]javac\f[R] را تعیین نمی‌کنند.
تلاش برای سفارشی‌سازی پیاده‌سازی کامپایلر با این گزینه‌ها و متغیرها پرخطر است و اغلب به هدف مورد نظر شما نمی‌رسد.
اگر ملزم به سفارشی‌سازی پیاده‌سازی کامپایلر هستید، از گزینهٔ \f[CB]\-J\f[R] برای انتقال گزینه‌ها به راه‌انداز زیرین جاوا استفاده کنید.
.RE
.TP
.B \f[CB]\-\-limit\-modules\f[R] \f[I]module\f[R]\f[CB],\f[R]\f[I]module\f[R]*
دامنهٔ ماژول‌های قابل مشاهده را محدود می‌کند.
.RS
.RE
.TP
.B \f[CB]\-\-module\f[R] \f[I]module\-name\f[R] (\f[CB],\f[R]\f[I]module\-name\f[R])* یا \f[CB]\-m\f[R] \f[I]module\-name\f[R] (\f[CB],\f[R]\f[I]module\-name\f[R])*
آن دسته از فایل‌های مبدأ در ماژول‌های نام‌برده را که از فایل‌های متناظر در دایرکتوری خروجی جدیدتر هستند کامپایل می‌کند.
.RS
.RE
.TP
.B \f[CB]\-\-module\-path\f[R] \f[I]path\f[R] یا \f[CB]\-p\f[R] \f[I]path\f[R]
محل یافتن ماژول‌های برنامه را مشخص می‌کند.
.RS
.RE
.TP
.B \f[CB]\-\-module\-source\-path\f[R] \f[I]module\-source\-path\f[R]
محل یافتن فایل‌های مبدأ را هنگام کامپایل کد در چندین ماژول مشخص می‌کند.
بخش [Compilation Modes] و \f[B]The Module Source Path Option\f[R] را ببینید.
.RS
.RE
.TP
.B \f[CB]\-\-module\-version\f[R] \f[I]version\f[R]
نسخهٔ ماژول‌هایی که کامپایل می‌شوند را مشخص می‌کند.
.RS
.RE
.TP
.B \f[CB]\-nowarn\f[R]
پیام‌های هشدار را غیرفعال می‌کند.
این گزینه همانند گزینهٔ \f[CB]\-Xlint:none\f[R] عمل می‌کند.
.RS
.RE
.TP
.B \f[CB]\-parameters\f[R]
فرادهاده‌ها را برای بازتاب (reflection) بر روی پارامترهای متد تولید می‌کند.
نام‌های پارامترهای صوری سازنده‌ها و متدها را در فایل کلاسِ تولیدشده ذخیره می‌کند تا متد \f[CB]java.lang.reflect.Executable.getParameters\f[R] از Reflection API بتواند آن‌ها را بازیابی کند.
.RS
.RE
.TP
.B \f[CB]\-proc:\f[R][\f[CB]none\f[R], \f[CB]only\f[R]]
انجام پردازش حاشیه‌نویسی و کامپایل را کنترل می‌کند.
\f[CB]\-proc:none\f[R] بدان معناست که کامپایل بدون پردازش حاشیه‌نویسی انجام می‌شود.
\f[CB]\-proc:only\f[R] بدان معناست که تنها پردازش حاشیه‌نویسی، بدون هیچ‌گونه کامپایل بعدی، انجام می‌شود.
.RS
.RE
.TP
.B \f[CB]\-processor\f[R] \f[I]class1\f[R][\f[CB],\f[R]\f[I]class2\f[R]\f[CB],\f[R]\f[I]class3\f[R]...]
نام‌های پردازش‌گرهای حاشیه‌نویسی برای اجرا.
این کار فرایند پیش‌فرض شناسایی را دور می‌زند.
.RS
.RE
.TP
.B \f[CB]\-\-processor\-module\-path\f[R] \f[I]path\f[R]
مسیر ماژول مورد استفاده برای یافتن پردازش‌گرهای حاشیه‌نویسی را مشخص می‌کند.
.RS
.RE
.TP
.B \f[CB]\-\-processor\-path\f[R] \f[I]path\f[R] یا \f[CB]\-processorpath\f[R] \f[I]path\f[R]
محل یافتن پردازش‌گرهای حاشیه‌نویسی را مشخص می‌کند.
اگر از این گزینه استفاده نشود، مسیر کلاس (class path) برای یافتن پردازش‌گرها جستجو می‌شود.
.RS
.RE
.TP
.B \f[CB]\-profile\f[R] \f[I]profile\f[R]
بررسی می‌کند که API مورد استفاده در پروفایل مشخص‌شده موجود باشد.
.RS
.PP
\f[B]نکته:\f[R] این مورد تنها هنگام کامپایل برای نگارش‌های پیش از JDK 9 قابل استفاده است.
در صورت لزوم، برای جزئیات به توضیحات در \f[B]\f[BC]\-\-release\f[B]\f[R]، \f[B]\f[BC]\-source\f[B]\f[R] یا \f[B]\f[BC]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
.B \f[CB]\-\-release\f[R] \f[I]release\f[R]
کد مبدأ را بر اساس قوانین زبان برنامه‌نویسی جاوا برای انتشار (release) مشخص‌شدهٔ Java SE کامپایل کرده و فایل‌های کلاسی تولید می‌کند که آن انتشار را هدف قرار می‌دهند.
کد مبدأ در برابر ترکیب APIهای Java SE و JDK برای انتشار مشخص‌شده کامپایل می‌شود.
.RS
.PP
مقادیر پشتیبانی‌شده برای \f[I]release\f[R] عبارتند از انتشار فعلی Java SE و تعداد محدودی از انتشارهای پیشین که جزئیات آن‌ها در راهنمای خط فرمان آمده است.
.PP
برای انتشار فعلی، Java SE API شامل بسته‌های \f[CB]java.*\f[R]، \f[CB]javax.*\f[R] و \f[CB]org.*\f[R] است که توسط ماژول‌های Java SE در این انتشار صادر (export) شده‌اند؛ JDK API شامل بسته‌های \f[CB]com.*\f[R] و \f[CB]jdk.*\f[R] است که توسط ماژول‌های JDK در این انتشار صادر شده‌اند، به‌علاوهٔ بسته‌های \f[CB]javax.*\f[R] که توسط ماژول‌های استاندارد، اما غیر Java SE در این انتشار صادر شده‌اند.
.PP
برای انتشارهای پیشین، Java SE API و JDK API همان‌گونه هستند که در آن انتشار تعریف شده‌اند.
.PP
\f[B]نکته:\f[R] هنگام استفاده از \f[CB]\-\-release\f[R]، نمی‌توانید هم‌زمان از گزینه‌های \f[B]\f[BC]\-\-source\f[B]\f[R]/\f[CB]\-source\f[R] یا \f[B]\f[BC]\-\-target\f[B]\f[R]/\f[CB]\-target\f[R] استفاده کنید.
.PP
\f[B]نکته:\f[R] هنگام استفاده از \f[CB]\-\-release\f[R] برای مشخص کردن انتشاری که از Java Platform Module System پشتیبانی می‌کند، گزینهٔ \f[CB]\-\-add\-exports\f[R] نمی‌تواند برای گسترش مجموعهٔ بسته‌های صادرشده توسط ماژول‌های Java SE، JDK و ماژول‌های استاندارد در انتشار مشخص‌شده به کار رود.
.RE
.TP
.B \f[CB]\-s\f[R] \f[I]directory\f[R]
دایرکتوری مورد استفاده برای قرار دادن فایل‌های مبدأ تولیدشده را مشخص می‌کند.
اگر کلاسی بخشی از یک بسته باشد، کامپایلر فایل مبدأ را در زیرشاخه‌ای قرار می‌دهد که بیانگر نام ماژول (در صورت لزوم) و نام بسته است.
دایرکتوری و زیرشاخه‌های لازم، در صورتی که از قبل وجود نداشته باشند، ایجاد خواهند شد.
.RS
.PP
به‌جز هنگام کامپایل کد برای چندین ماژول، محتویات دایرکتوری خروجی مبدأ بر اساس یک سلسله‌مراتب بسته‌ای سازماندهی خواهند شد.
هنگام کامپایل کد برای چندین ماژول، محتویات دایرکتوری خروجی مبدأ در یک سلسله‌مراتب ماژولی سازماندهی می‌شوند، به‌طوری که محتویات هر ماژول در زیرشاخه‌ای جداگانه قرار می‌گیرد و هرکدام به صورت یک سلسله‌مراتب بسته‌ای مرتب می‌شوند.
.RE.TP
.B \f[CB]\-\-source\f[R] \f[I]release\f[R] یا \f[CB]\-source\f[R] \f[I]release\f[R]
کد منبع را مطابق با قوانین زبان برنامه‌نویسی Java برای انتشار مشخص‌شده Java SE کامپایل می‌کند.
مقادیر پشتیبانی‌شده برای \f[I]release\f[R] عبارتند از انتشار کنونی Java SE و تعداد محدودی از انتشار‌های پیشین، که جزئیات آن در راهنمای خط فرمان آمده است.
.RS
.PP
اگر این گزینه مشخص نشود، پیش‌فرض این است که کد منبع مطابق با قوانین زبان برنامه‌نویسی Java برای انتشار کنونی Java SE کامپایل شود.
.RE
.TP
.B \f[CB]\-\-source\-path\f[R] \f[I]path\f[R] یا \f[CB]\-sourcepath\f[R] \f[I]path\f[R]
محل یافتن فایل‌های منبع را مشخص می‌کند.
به‌جز هنگام کامپایل هم‌زمان چندین ماژول، این مسیر کد منبع است که برای جستجوی تعاریف کلاس (class) یا رابط (interface) استفاده می‌شود.
.RS
.PP
\f[B]نکته:\f[R] کلاس‌های یافت‌شده از طریق مسیر کلاس (class path) ممکن است در صورتی که فایل‌های منبع آن‌ها نیز یافت شوند، مجدداً کامپایل گردند.
به \f[B]Searching for Module, Package and Type Declarations\f[R] مراجعه کنید.
.RE
.TP
.B \f[CB]\-\-system\f[R] \f[I]jdk\f[R] | \f[CB]none\f[R]
مکان ماژول‌های سیستم را بازنویسی می‌کند.
.RS
.RE
.TP
.B \f[CB]\-\-target\f[R] \f[I]release\f[R] یا \f[CB]\-target\f[R] \f[I]release\f[R]
فایل‌های \f[CB]class\f[R] مناسب برای انتشار مشخص‌شده Java SE را تولید می‌کند.
مقادیر پشتیبانی‌شده برای \f[I]release\f[R] عبارتند از انتشار کنونی Java SE و تعداد محدودی از انتشار‌های پیشین، که جزئیات آن در راهنمای خط فرمان آمده است.
.RS
.PP
\f[B]نکته:\f[R] انتشار مقصد (target release) باید برابر یا بالاتر از انتشار مبدأ (source release) باشد.
(به \f[B]\f[BC]\-\-source\f[B]\f[R] مراجعه کنید.)
.RE
.TP
.B \f[CB]\-\-upgrade\-module\-path\f[R] \f[I]path\f[R]
مکان ماژول‌های قابل ارتقا را بازنویسی می‌کند.
.RS
.RE
.TP
.B \f[CB]\-verbose\f[R]
پیام‌هایی دربارهٔ عملیات کامپایلر صادر می‌کند.
پیام‌ها شامل اطلاعات مربوط به هر کلاس بارگذاری‌شده و هر فایل منبع کامپایل‌شده است.
.RS
.RE
.TP
.B \f[CB]\-\-version\f[R] یا \f[CB]\-version\f[R]
اطلاعات نسخه را چاپ می‌کند.
.RS
.RE
.TP
.B \f[CB]\-Werror\f[R]
در صورت بروز هشدار، فرآیند کامپایل را خاتمه می‌دهد.
.RS
.RE
.SS "گزینه‌های اضافی (Extra Options)"
.TP
.B \f[CB]\-\-add\-exports\f[R] \f[I]module\f[R]\f[CB]/\f[R]\f[I]package\f[R]\f[CB]=\f[R]\f[I]other\-module\f[R](\f[CB],\f[R]\f[I]other\-module\f[R])*
بسته‌ای را مشخص می‌کند تا از ماژول تعریف‌کننده‌اش به ماژول‌های اضافی، یا در صورتی که مقدار \f[I]other\-module\f[R] برابر با \f[CB]ALL\-UNNAMED\f[R] باشد به تمام ماژول‌های بی‌نام (unnamed modules)، صادرشده (exported) در نظر گرفته شود.
.RS
.RE
.TP
.B \f[CB]\-\-add\-reads\f[R] \f[I]module\f[R]\f[CB]=\f[R]\f[I]other\-module\f[R](\f[CB],\f[R]\f[I]other\-module\f[R])*
ماژول‌های اضافی را مشخص می‌کند تا به‌عنوان نیازمندی‌های یک ماژول داده‌شده در نظر گرفته شوند.
.RS
.RE
.TP
.B \f[CB]\-\-default\-module\-for\-created\-files\f[R] \f[I]module\-name\f[R]
در صورتی که هیچ ماژولی مشخص یا استنتاج نشده باشد، ماژول مقصد جایگزین (fallback) را برای فایل‌های ایجادشده توسط پردازشگرهای حاشیه‌نویسی (annotation processors) مشخص می‌کند.
.RS
.RE
.TP
.B \f[CB]\-Djava.endorsed.dirs=\f[R]\f[I]dirs\f[R]
مکان مسیر استانداردهای تأییدشده (endorsed standards path) را بازنویسی می‌کند.
.RS
.PP
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای انتشار‌های قبل از JDK 9 قابل استفاده است.
برحسب مورد، برای جزئیات به توضیحات در \f[B]\f[BC]\-\-release\f[B]\f[R]، \f[B]\f[BC]\-source\f[B]\f[R] یا \f[B]\f[BC]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
.B \f[CB]\-Djava.ext.dirs=\f[R]\f[I]dirs\f[R]
مکان افزونه‌های نصب‌شده را بازنویسی می‌کند.
.RS
.PP
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای انتشار‌های قبل از JDK 9 قابل استفاده است.
برحسب مورد، برای جزئیات به توضیحات در \f[B]\f[BC]\-\-release\f[B]\f[R]، \f[B]\f[BC]\-source\f[B]\f[R] یا \f[B]\f[BC]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
.B \f[CB]\-\-patch\-module\f[R] \f[I]module\f[R]\f[CB]=\f[R]\f[I]path\f[R]
یک ماژول را با کلاس‌ها و منابع موجود در فایل‌های JAR یا دایرکتوری‌ها بازنویسی کرده یا گسترش می‌دهد.
.RS
.RE
.TP
.B \f[CB]\-Xbootclasspath:\f[R]\f[I]path\f[R]
مکان فایل‌های کلاس راه‌انداز (bootstrap class files) را بازنویسی می‌کند.
.RS
.PP
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای انتشار‌های قبل از JDK 9 قابل استفاده است.
برحسب مورد، برای جزئیات به توضیحات در \f[B]\f[BC]\-\-release\f[B]\f[R]، \f[B]\f[BC]\-source\f[B]\f[R] یا \f[B]\f[BC]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
.B \f[CB]\-Xbootclasspath/a:\f[R]\f[I]path\f[R]
یک پسوند به مسیر کلاس راه‌انداز (bootstrap class path) می‌افزاید.
.RS
.PP
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای انتشار‌های قبل از JDK 9 قابل استفاده است.
برحسب مورد، برای جزئیات به توضیحات در \f[B]\f[BC]\-\-release\f[B]\f[R]، \f[B]\f[BC]\-source\f[B]\f[R] یا \f[B]\f[BC]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
.B \f[CB]\-Xbootclasspath/p:\f[R]\f[I]path\f[R]
یک پیشوند به مسیر کلاس راه‌انداز (bootstrap class path) می‌افزاید.
.RS
.PP
\f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای انتشار‌های قبل از JDK 9 قابل استفاده است.
برحسب مورد، برای جزئیات به توضیحات در \f[B]\f[BC]\-\-release\f[B]\f[R]، \f[B]\f[BC]\-source\f[B]\f[R] یا \f[B]\f[BC]\-target\f[B]\f[R] مراجعه کنید.
.RE
.TP
.B \f[CB]\-Xdiags:\f[R][\f[CB]compact\f[R], \f[CB]verbose\f[R]]
یک حالت عیب‌یابی را انتخاب می‌کند.
.RS
.RE
.TP
.B \f[CB]\-Xdoclint\f[R]
بررسی‌های توصیه‌شده برای مشکلات موجود در کامنت‌های \f[CB]javadoc\f[R] را فعال می‌کند.
.RS
.RE
.TP
.B \f[CB]\-Xdoclint:\f[R](\f[CB]all\f[R]|\f[CB]none\f[R]|[\f[CB]\-\f[R]]\f[I]group\f[R])[\f[CB]/\f[R]\f[I]access\f[R]]
گروه‌های خاصی از بررسی‌ها را فعال یا غیرفعال می‌کند،
.RS
.PP
مقدار \f[I]group\f[R] می‌تواند یکی از موارد زیر باشد:
.IP \[bu] 2
\f[CB]accessibility\f[R]
.IP \[bu] 2
\f[CB]html\f[R]
.IP \[bu] 2
\f[CB]missing\f[R]
.IP \[bu] 2
\f[CB]reference\f[R]
.IP \[bu] 2
\f[CB]syntax\f[R]
.PP
متغیر \f[I]access\f[R] حداقل سطح دیداری (visibility) کلاس‌ها و اعضایی را که گزینهٔ \f[CB]\-Xdoclint\f[R] بررسی می‌کند، مشخص می‌سازد.
این متغیر می‌تواند یکی از مقادیر زیر باشد (به ترتیب از بیشترین به کمترین میزان دیداری):
.IP \[bu] 2
\f[CB]public\f[R]
.IP \[bu] 2
\f[CB]protected\f[R]
.IP \[bu] 2
\f[CB]package\f[R]
.IP \[bu] 2
\f[CB]private\f[R]
.PP
سطح دیداری پیش‌فرض \f[I]access\f[R] برابر با \f[CB]private\f[R] است.
.PP
برای اطلاعات بیشتر دربارهٔ این گروه‌های بررسی، گزینهٔ \f[CB]\-Xdoclint\f[R] در دستور \f[CB]javadoc\f[R] را ببینید.
گزینهٔ \f[CB]\-Xdoclint\f[R] به‌طور پیش‌فرض در دستور \f[CB]javac\f[R] غیرفعال است.
.PP
برای مثال، گزینهٔ زیر کلاس‌ها و اعضایی را (با تمام گروه‌های بررسی) که دارای سطح دسترسی protected و بالاتر هستند (که شامل protected و public می‌شود) بررسی می‌کند:
.RS
.PP
\f[CB]\-Xdoclint:all/protected\f[R]
.RE
.PP
گزینهٔ زیر تمام گروه‌های بررسی را برای همهٔ سطوح دسترسی فعال می‌کند، به‌جز اینکه خطاهای HTML را برای کلاس‌ها و اعضایی که دارای سطح دسترسی package و بالاتر هستند (که شامل package، protected و public می‌شود) بررسی نمی‌کند:
.RS.PP
\f[CB]\-Xdoclint:all,\-html/package\f[R]
.RE
.RE
.TP
.B \f[CB]\-Xdoclint/package:\f[R][\f[CB]\-\f[R]]\f[I]packages\f[R](\f[CB],\f[R][\f[CB]\-\f[R]]\f[I]package\f[R])*
بررسی‌ها را در بسته‌های مشخص فعال یا غیرفعال می‌کند.
هر \f[I]package\f[R] یا نام کامل (qualified name) یک بسته است یا پیشوند نام بسته به همراه \f[CB]\&.*\f[R]، که به تمام زیربسته‌های بسته داده‌شده گسترش می‌یابد.
هر \f[I]package\f[R] می‌تواند با یک خط تیره (\f[CB]\-\f[R]) شروع شود تا بررسی‌ها برای یک یا چند بسته مشخص غیرفعال گردند.
.RS
.RE
.TP
.B \f[CB]\-Xlint\f[R]
همه هشدارهای توصیه‌شده را فعال می‌کند.
در این نسخه، فعال‌سازی تمام هشدارهای موجود توصیه می‌شود.
.RS
.RE
.TP
.B \f[CB]\-Xlint:\f[R][\f[CB]\-\f[R]]\f[I]key\f[R](\f[CB],\f[R][\f[CB]\-\f[R]]\f[I]key\f[R])*
هشدارهایی را برای فعال یا غیرفعال شدن تعیین می‌کند که با ویرگول جدا می‌شوند.
برای غیرفعال کردن هشدار مشخص‌شده، یک خط تیره (\f[CB]\-\f[R]) پیش از کلید قرار دهید.
.RS
.PP
مقادیر پشتیبانی‌شده برای \f[I]key\f[R] عبارتند از:
.IP \[bu] 2
\f[CB]all\f[R]: همه هشدارها را فعال می‌کند.
.IP \[bu] 2
\f[CB]auxiliaryclass\f[R]: درباره یک کلاس کمکی (auxiliary class) که در یک فایل مبدأ پنهان شده و در فایل‌های دیگر استفاده شده است، هشدار می‌دهد.
.IP \[bu] 2
\f[CB]cast\f[R]: درباره استفاده از تبدیل‌های نوع (cast) غیرضروری هشدار می‌دهد.
.IP \[bu] 2
\f[CB]classfile\f[R]: درباره مسائل مربوط به محتویات classfile هشدار می‌دهد.
.IP \[bu] 2
\f[CB]deprecation\f[R]: درباره استفاده از موارد منسوخ‌شده (deprecated) هشدار می‌دهد.
.IP \[bu] 2
\f[CB]dep\-ann\f[R]: درباره مواردی که در \f[CB]javadoc\f[R] به عنوان منسوخ مشخص شده‌اند اما فاقد یادداشت \f[CB]\@Deprecated\f[R] هستند، هشدار می‌دهد.
.IP \[bu] 2
\f[CB]divzero\f[R]: درباره تقسیم بر عدد صحیح ثابت 0 هشدار می‌دهد.
.IP \[bu] 2
\f[CB]empty\f[R]: درباره عبارت خالی پس از دستور \f[CB]if\f[R] هشدار می‌دهد.
.IP \[bu] 2
\f[CB]exports\f[R]: درباره مسائل مربوط به صادرات ماژول (module exports) هشدار می‌دهد.
.IP \[bu] 2
\f[CB]fallthrough\f[R]: درباره افتادن (fall-through) از یک حالت دستور switch به حالت بعدی هشدار می‌دهد.
.IP \[bu] 2
\f[CB]finally\f[R]: درباره بندهای \f[CB]finally\f[R] که به‌طور عادی خاتمه نمی‌یابند هشدار می‌دهد.
.IP \[bu] 2
\f[CB]module\f[R]: درباره مسائل مرتبط با سیستم ماژول هشدار می‌دهد.
.IP \[bu] 2
\f[CB]opens\f[R]: درباره مسائل مربوط به باز کردن ماژول (module opens) هشدار می‌دهد.
.IP \[bu] 2
\f[CB]options\f[R]: درباره مسائل مربوط به استفاده از گزینه‌های خط فرمان هشدار می‌دهد.
.IP \[bu] 2
\f[CB]overloads\f[R]: درباره مسائل مربوط به چندریختی متدها (method overloads) هشدار می‌دهد.
.IP \[bu] 2
\f[CB]overrides\f[R]: درباره مسائل مربوط به بازنویسی متدها (method overrides) هشدار می‌دهد.
.IP \[bu] 2
\f[CB]path\f[R]: درباره عناصر نامعتبر مسیر در خط فرمان هشدار می‌دهد.
.IP \[bu] 2
\f[CB]processing\f[R]: درباره مسائل مربوط به پردازش یادداشت‌ها (annotation processing) هشدار می‌دهد.
.IP \[bu] 2
\f[CB]rawtypes\f[R]: درباره استفاده از انواع خام (raw types) هشدار می‌دهد.
.IP \[bu] 2
\f[CB]removal\f[R]: درباره استفاده از یک API که برای حذف علامت‌گذاری شده است هشدار می‌دهد.
.IP \[bu] 2
\f[CB]requires\-automatic\f[R]: به توسعه‌دهندگان درباره استفاده از ماژول‌های خودکار (automatic modules) در بندهای requires هشدار می‌دهد.
.IP \[bu] 2
\f[CB]requires\-transitive\-automatic\f[R]: درباره ماژول‌های خودکار در requires transitive هشدار می‌دهد.
.IP \[bu] 2
\f[CB]serial\f[R]: درباره کلاس‌های قابل‌سریال‌سازی (serializable) که شناسه نسخه سریالی ارائه نمی‌دهند هشدار می‌دهد.
همچنین درباره دسترسی به اعضای غیرعمومی از یک عنصر قابل‌سریال‌سازی هشدار می‌دهد.
.IP \[bu] 2
\f[CB]static\f[R]: درباره دسترسی به یک عضو ایستا (static) از طریق یک نمونه شیء هشدار می‌دهد.
.IP \[bu] 2
\f[CB]try\f[R]: درباره مسائل مربوط به استفاده از بلوک‌های try (یعنی try\-with\-resources) هشدار می‌دهد.
.IP \[bu] 2
\f[CB]unchecked\f[R]: درباره عملیات‌های بررسی‌نشده (unchecked) هشدار می‌دهد.
.IP \[bu] 2
\f[CB]varargs\f[R]: درباره متدهای بالقوه ناامن \f[CB]vararg\f[R] هشدار می‌دهد.
.IP \[bu] 2
\f[CB]none\f[R]: همه هشدارها را غیرفعال می‌کند.
.PP
بخش \f[B]Examples of Using \-Xlint keys\f[R] را ببینید.
.RE
.TP
.B \f[CB]\-Xmaxerrs\f[R] \f[I]number\f[R]
حداکثر تعداد خطاهای قابل‌چاپ را تنظیم می‌کند.
.RS
.RE
.TP
.B \f[CB]\-Xmaxwarns\f[R] \f[I]number\f[R]
حداکثر تعداد هشدارهای قابل‌چاپ را تنظیم می‌کند.
.RS
.RE
.TP
.B \f[CB]\-Xpkginfo:\f[R][\f[CB]always\f[R], \f[CB]legacy\f[R], \f[CB]nonempty\f[R]]
مشخص می‌کند که دستور \f[CB]javac\f[R] چه زمانی و چگونه فایل‌های \f[CB]package\-info.class\f[R] را با استفاده از یکی از گزینه‌های زیر از فایل‌های \f[CB]package\-info.java\f[R] تولید کند:
.RS
.TP
.B \f[CB]always\f[R]
برای هر فایل \f[CB]package\-info.java\f[R] یک فایل \f[CB]package\-info.class\f[R] تولید می‌کند.
این گزینه ممکن است زمانی مفید باشد که از یک سامانه ساخت مانند Ant استفاده می‌کنید که تطابق هر فایل \f[CB]\&.java\f[R] با فایل متناظر \f[CB]\&.class\f[R] را بررسی می‌کند.
.RS
.RE
.TP
.B \f[CB]legacy\f[R]
تنها در صورتی یک فایل \f[CB]package\-info.class\f[R] تولید می‌کند که \f[CB]package\-info.java\f[R] حاوی یادداشت‌ها (annotations) باشد.
این گزینه در صورتی که \f[CB]package\-info.java\f[R] فقط شامل توضیحات (comments) باشد، فایل \f[CB]package\-info.class\f[R] تولید نمی‌کند.
.RS
.PP
\f[B]نکته:\f[R] ممکن است یک فایل \f[CB]package\-info.class\f[R] تولید شود اما در صورتی که تمام یادداشت‌های موجود در فایل \f[CB]package\-info.java\f[R] دارای \f[CB]RetentionPolicy.SOURCE\f[R] باشند، خالی خواهد بود.
.RE
.TP
.B \f[CB]nonempty\f[R]
تنها در صورتی یک فایل \f[CB]package\-info.class\f[R] تولید می‌کند که \f[CB]package\-info.java\f[R] شامل یادداشت‌هایی با \f[CB]RetentionPolicy.CLASS\f[R] یا \f[CB]RetentionPolicy.RUNTIME\f[R] باشد.
.RS
.RE
.RE
.TP
.B \f[CB]\-Xplugin:\f[R]\f[I]name\f[R] \f[I]args\f[R]
نام و آرگومان‌های اختیاری را برای اجرای یک افزونه (plug\-in) مشخص می‌کند.
در صورت ارائه \f[I]args\f[R]، باید \f[I]name\f[R] و \f[I]args\f[R] داخل گیومه قرار گیرند یا کاراکترهای فاصله بین نام و تمام آرگومان‌ها با کاراکتر گریز (escape) تفکیک شوند.
برای جزئیات بیشتر درباره API افزونه، مستندات API مربوط به \f[B]jdk.compiler/com.sun.source.util.Plugin\f[R] را ببینید.
.RS
.RE
.TP
.B \f[CB]\-Xprefer:\f[R][\f[CB]source\f[R], \f[CB]newer\f[R]]
با استفاده از یکی از گزینه‌های زیر مشخص می‌کند که هنگام یافت شدن هم‌زمان فایل مبدأ و فایل کلاس برای یک کلاس کامپایل‌شده به‌صورت ضمنی، کدام فایل خوانده شود.
بخش \f[B]Searching for Module, Package and Type Declarations\f[R] را ببینید.
.RS
.IP \[bu] 2
\f[CB]\-Xprefer:newer\f[R]: فایل تازه‌تر را از میان فایل‌های مبدأ یا کلاس برای یک نوع می‌خواند (پیش‌فرض).
.IP \[bu] 2
\f[CB]\-Xprefer:source\f[R] : فایل مبدأ را می‌خواند.
زمانی از \f[CB]\-Xprefer:source\f[R] استفاده کنید که می‌خواهید مطمئن شوید پردازنده‌های یادداشت می‌توانند به یادداشت‌های اعلان‌شده با سیاست نگهداری \f[CB]SOURCE\f[R] دسترسی داشته باشند.
.RE
.TP
.B \f[CB]\-Xprint\f[R]
نمایشی متنی از نوع‌های مشخص‌شده را برای اهداف اشکال‌زدایی چاپ می‌کند.
این گزینه پردازش یادداشت یا کامپایل را انجام نمی‌دهد.
قالب خروجی ممکن است تغییر کند.
.RS
.RE
.TP
.B \f[CB]\-XprintProcessorInfo\f[R]
اطلاعاتی درباره اینکه از پردازنده درخواست پردازش چه یادداشت‌هایی شده است را چاپ می‌کند.
.RS
.RE
.TP
.B \f[CB]\-XprintRounds\f[R]
اطلاعاتی را درباره دورهای اولیه و بعدی پردازش یادداشت چاپ می‌کند.
.RS
.RE
.TP
.B \f[CB]\-Xstdout\f[R] \f[I]filename\f[R]
پیام‌های کامپایلر را به فایل مشخص‌شده ارسال می‌کند.
به‌طور پیش‌فرض، پیام‌های کامپایلر به \f[CB]System.err\f[R] ارسال می‌شوند.
.RS
.RE.SH "متغیرهای محیطی (ENVIRONMENT VARIABLES)"
.SS CLASSPATH
.PP
اگر گزینهٔ \f[B]\f[BC]\-\-class\-path\f[B]\f[R] یا هر یک از اَشکال جایگزین آن مشخص نشده باشد، در صورت تنظیم بودن متغیر محیطی \f[CB]CLASSPATH\f[R]، مسیر کلاس به‌طور پیش‌فرض برابر با مقدار آن خواهد بود. با این حال، توصیه می‌شود که این متغیر محیطی تنظیم \f[I]نشود\f[R] و در صورت نیاز به یک مقدار صریح برای مسیر کلاس، از گزینهٔ \f[CB]\-\-class\-path\f[R] استفاده گردد.
.SS JDK_JAVAC_OPTIONS
.PP
محتوای متغیر محیطی \f[CB]JDK_JAVAC_OPTIONS\f[R] که با فاصله‌ها ( ) یا نویسه‌های فاصلهٔ خالی (\f[CB]\\n\f[R]، \f[CB]\\t\f[R]، \f[CB]\\r\f[R] یا \f[CB]\\f\f[R]) جدا شده‌اند، به عنوان فهرستی از آرگومان‌ها به ابتدای آرگومان‌های خط فرمان ارسالی به \f[CB]javac\f[R] اضافه می‌شود.
.PP
الزامات مربوط به کدگذاری برای این متغیر محیطی همانند خط فرمان \f[CB]javac\f[R] در سیستم است. با محتوای متغیر محیطی \f[CB]JDK_JAVAC_OPTIONS\f[R] دقیقاً به همان شیوه‌ای که در خط فرمان مشخص شده است رفتار می‌شود.
.PP
می‌توان از نقل‌قول تکی (\f[CB]\[aq]\f[R]) یا نقل‌قول جفت (\f[CB]"\f[R]) برای دربرگرفتن آرگومان‌هایی که حاوی نویسه‌های فاصله هستند استفاده کرد. تمام محتوای بین نقل‌قول آغازین و نخستین نقل‌قول پایانی متناظر، صرفاً با حذف جفت نقل‌قول حفظ می‌شود. در صورتی که نقل‌قول متناظری یافت نشود، اجراکننده (launcher) با یک پیام خطا متوقف خواهد شد. پرونده‌های \f[CB]\@\f[R]\f[I]files\f[R] همان‌گونه که در خط فرمان مشخص می‌شوند، پشتیبانی می‌گردند. با این حال، همانند \f[CB]\@\f[R]\f[I]files\f[R]، استفاده از نویسه‌های عام (wildcard) پشتیبانی نمی‌شود.
.PP
\f[B]مثال‌هایی از نقل‌قول کردن آرگومان‌های حاوی نویسه‌های فاصله:\f[R]
.RS
.PP
\f[CB]export\ JDK_JAVAC_OPTIONS=\[aq]\@"C:\\white\ spaces\\argfile"\[aq]\f[R]
.RE
.RS
.PP
\f[CB]export\ JDK_JAVAC_OPTIONS=\[aq]"\@C:\\white\ spaces\\argfile"\[aq]\f[R]
.RE
.RS
.PP
\f[CB]export\ JDK_JAVAC_OPTIONS=\[aq]\@C:\\"white\ spaces"\\argfile\[aq]\f[R]
.RE
.SH "فایل‌های آرگومان خط فرمان (COMMAND\-LINE ARGUMENT FILES)"
.PP
یک فایل آرگومان می‌تواند شامل گزینه‌های خط فرمان و نام فایل‌های منبع در هر ترکیبی باشد. آرگومان‌های درون یک فایل را می‌توان با فاصله یا نویسه‌های خط جدید از یکدیگر جدا کرد. اگر نام فایلی دارای فاصله است، کل نام فایل را درون علامت‌های نقل‌قول جفت قرار دهید.
.PP
نام فایل‌های درون یک فایل آرگومان نسبت به دایرکتوری جاری سنجیده می‌شوند، نه نسبت به مکان قرارگیری فایل آرگومان. نویسه‌های عام (\f[CB]*\f[R]) در این فهرست‌ها مجاز نیستند (مانند مشخص کردن \f[CB]*.java\f[R]). استفاده از علامت اَت (\f[CB]\@\f[R]) برای تفسیر بازگشتی فایل‌ها پشتیبانی نمی‌شود. گزینه‌های \f[CB]\-J\f[R] پشتیبانی نمی‌شوند زیرا به اجراکننده تحویل داده می‌شوند که خود از فایل‌های آرگومان پشتیبانی نمی‌کند.
.PP
هنگام اجرای دستور \f[CB]javac\f[R]، مسیر و نام هر فایل آرگومان را با پیشوند علامت اَت (\f[CB]\@\f[R]) وارد کنید. هنگامی که دستور \f[CB]javac\f[R] با آرگومانی مواجه می‌شود که با علامت اَت (\f[CB]\@\f[R]) آغاز شده است، محتویات آن فایل را در فهرست آرگومان‌ها باز می‌کند.
.SS "مثال‌های استفاده از javac \@filename"
.TP
.B "فایل آرگومان تکی"
می‌توانید از یک فایل آرگومان به نام \f[CB]argfile\f[R] برای نگه‌داری تمام آرگومان‌های \f[CB]javac\f[R] استفاده کنید:
.RS
.RS
.PP
\f[CB]javac\ \@argfile\f[R]
.RE
.PP
این فایل آرگومان می‌تواند حاوی محتویات هر دو فایل نشان‌داده‌شده در مثال زیر یعنی \f[B]دو فایل آرگومان\f[R] باشد.
.RE
.TP
.B "دو فایل آرگومان"
می‌توانید دو فایل آرگومان ایجاد کنید: یکی برای گزینه‌های \f[CB]javac\f[R] و دیگری برای نام‌های فایل‌های منبع. توجه داشته باشید که فهرست‌های زیر هیچ نویسهٔ ادامه‌دهندهٔ خطی ندارند.
.RS
.PP
فایلی به نام \f[CB]options\f[R] ایجاد کنید که حاوی موارد زیر باشد:
.PP
\f[B]لینوکس و macOS:\f[R]
.IP
.nf
\f[CB]
\-d\ classes
\-g
\-sourcepath\ /java/pubs/ws/1.3/src/share/classes
\f[R]
.fi
.PP
\f[B]ویندوز:\f[R]
.IP
.nf
\f[CB]
\-d\ classes
\-g
\-sourcepath\ C:\\java\\pubs\\ws\\1.3\\src\\share\\classes
\f[R]
.fi
.PP
فایلی به نام \f[CB]classes\f[R] ایجاد کنید که حاوی موارد زیر باشد:
.IP
.nf
\f[CB]
MyClass1.java
MyClass2.java
MyClass3.java
\f[R]
.fi
.PP
سپس، دستور \f[CB]javac\f[R] را به صورت زیر اجرا کنید:
.RS
.PP
\f[CB]javac\ \@options\ \@classes\f[R]
.RE
.RE
.TP
.B "فایل‌های آرگومان دارای مسیر"
فایل‌های آرگومان می‌توانند دارای مسیر باشند، اما هر نام فایلی درون این فایل‌ها نسبت به دایرکتوری کاری جاری سنجیده می‌شود (نه نسبت به \f[CB]path1\f[R] یا \f[CB]path2\f[R]):
.RS
.RS
.PP
\f[CB]javac\ \@path1/options\ \@path2/classes\f[R]
.RE
.RE.SH "چیدمان کد منبع (ARRANGEMENT OF SOURCE CODE)"
.PP
در زبان Java، کلاس‌ها و رابط‌ها (interfaces) می‌توانند در بسته‌ها (packages)
سازمان‌دهی شوند، و بسته‌ها نیز می‌توانند در ماژول‌ها قرار گیرند.
\f[CB]javac\f[R] انتظار دارد که چیدمان فیزیکی فایل‌های منبع در دایرکتوری‌های
سیستم‌فایل، منعکس‌کننده سازمان‌دهی کلاس‌ها در بسته‌ها، و بسته‌ها در ماژول‌ها باشد.
.PP
این یک قرارداد پذیرفته‌شده گسترده است که نام ماژول‌ها و بسته‌ها با حروف
کوچک و نام کلاس‌ها با حروف بزرگ آغاز شود.
.SS "چیدمان کد منبع برای یک بسته"
.PP
هنگامی که کلاس‌ها و رابط‌ها در یک بسته سازمان‌دهی می‌شوند، آن بسته به‌صورت
یک دایرکتوری و هر زیربسته (subpackage) به‌صورت یک زیردایرکتوری نمایش داده می‌شود.
.PP
برای نمونه:
.IP \[bu] 2
بسته \f[CB]p\f[R] به‌صورت دایرکتوری‌ای به نام \f[CB]p\f[R] نمایش داده می‌شود.
.IP \[bu] 2
بسته \f[CB]p.q\f[R] \-\- یعنی زیربسته \f[CB]q\f[R] از بسته \f[CB]p\f[R] \-\-
به‌صورت زیردایرکتوری \f[CB]q\f[R] از دایرکتوری \f[CB]p\f[R] نمایش داده می‌شود.
بنابراین درخت دایرکتوری نمایانگر بسته \f[CB]p.q\f[R] در ویندوز به‌صورت
\f[CB]p\\q\f[R] و در سایر سیستم‌ها به‌صورت \f[CB]p/q\f[R] است.
.IP \[bu] 2
بسته \f[CB]p.q.r\f[R] به‌صورت درخت دایرکتوری \f[CB]p\\q\\r\f[R] (در ویندوز)
یا \f[CB]p/q/r\f[R] (در سایر سیستم‌ها) نمایش داده می‌شود.
.PP
درون یک دایرکتوری یا زیردایرکتوری، فایل‌های \f[CB]\&.java\f[R] نشان‌دهنده
کلاس‌ها و رابط‌های موجود در بسته یا زیربسته متناظر هستند.
.PP
برای نمونه:
.IP \[bu] 2
کلاس \f[CB]X\f[R] تعریف‌شده در بسته \f[CB]p\f[R] با فایل \f[CB]X.java\f[R]
در دایرکتوری \f[CB]p\f[R] مشخص می‌شود.
.IP \[bu] 2
کلاس \f[CB]Y\f[R] تعریف‌شده در بسته \f[CB]p.q\f[R] با فایل \f[CB]Y.java\f[R]
در زیردایرکتوری \f[CB]q\f[R] از دایرکتوری \f[CB]p\f[R] مشخص می‌شود.
.IP \[bu] 2
کلاس \f[CB]Z\f[R] تعریف‌شده در بسته \f[CB]p.q.r\f[R] با فایل \f[CB]Z.java\f[R]
در زیردایرکتوری \f[CB]r\f[R] از \f[CB]p\\q\f[R] (در ویندوز) یا
\f[CB]p/q\f[R] (در سایر سیستم‌ها) مشخص می‌شود.
.PP
در برخی شرایط، تفکیک کدها در دایرکتوری‌های مجزا که هر یک ساختاری مانند آنچه
در بالا توصیف شد دارند، و مشخص کردن فهرست تجمیعی دایرکتوری‌ها برای
\f[CB]javac\f[R] راحت‌تر و مناسب‌تر است.
.SS "چیدمان کد منبع برای یک ماژول"
.PP
در زبان Java، یک ماژول مجموعه‌ای از بسته‌ها است که برای استفاده مجدد طراحی شده‌اند.
علاوه بر فایل‌های \f[CB]\&.java\f[R] مربوط به کلاس‌ها و رابط‌ها، هر ماژول
دارای یک فایل منبع به نام \f[CB]module\-info.java\f[R] است که:
.IP "1." 3
نام ماژول را اعلام می‌کند؛
.IP "2." 3
فهرست بسته‌های صادرشده توسط ماژول را مشخص می‌کند (تا امکان استفاده مجدد توسط سایر
ماژول‌ها فراهم شود)؛
.IP "3." 3
فهرست سایر ماژول‌های مورد نیاز این ماژول را مشخص می‌کند (برای استفاده مجدد از
بسته‌های صادرشده آن‌ها).
.PP
هنگامی که بسته‌ها در یک ماژول سازمان‌دهی می‌شوند، ماژول با یک یا چند دایرکتوری
نمایانگر بسته‌های موجود در ماژول نشان داده می‌شود که یکی از آن‌ها حاوی
فایل \f[CB]module\-info.java\f[R] است.
استفاده از یک دایرکتوری واحد، همنام با ماژول، برای نگهداری فایل
\f[CB]module\-info.java\f[R] در کنار درخت دایرکتوری نمایانگر بسته‌های درون ماژول
(یعنی همان \f[I]سلسله‌مراتب بسته‌ها\f[R] که در بالا توضیح داده شد) ممکن است
راحت‌تر باشد، اما الزامی نیست.
چیدمان دقیق کد منبع برای یک ماژول معمولاً توسط قراردادهای اتخاذشده توسط
یک محیط توسعه (IDE) یا سیستم ساخت تعیین می‌شود.
.PP
برای نمونه:
.IP \[bu] 2
ماژول \f[CB]a.b.c\f[R] می‌تواند در تمام سیستم‌ها با دایرکتوری
\f[CB]a.b.c\f[R] نمایش داده شود.
.IP \[bu] 2
تعریف ماژول با فایل \f[CB]module\-info.java\f[R] در دایرکتوری
\f[CB]a.b.c\f[R] نشان داده می‌شود.
.IP \[bu] 2
اگر ماژول حاوی بسته \f[CB]p.q.r\f[R] باشد، در این صورت دایرکتوری \f[CB]a.b.c\f[R]
حاوی درخت دایرکتوری \f[CB]p\\q\\r\f[R] (در ویندوز) یا
\f[CB]p/q/r\f[R] (در سایر سیستم‌ها) خواهد بود.
.PP
محیط توسعه ممکن است یک سلسله‌مراتب دایرکتوری مشخص میان دایرکتوری همنام
ماژول و فایل‌های منبعی که قرار است توسط \f[CB]javac\f[R] خوانده شوند،
تعیین کند.
.PP
برای نمونه:
.IP \[bu] 2
ماژول \f[CB]a.b.c\f[R] ممکن است با دایرکتوری \f[CB]a.b.c\f[R] نمایش داده شود
.IP \[bu] 2
تعریف ماژول و بسته‌های ماژول ممکن است در زیردایرکتوری‌ای از \f[CB]a.b.c\f[R]،
مانند \f[CB]src\\main\\java\f[R] (در ویندوز) یا \f[CB]src/main/java\f[R]
(در سایر سیستم‌ها) قرار داشته باشند.
.SH "پیکربندی کامپایل (CONFIGURING A COMPILATION)"
.PP
این بخش نحوه پیکربندی \f[CB]javac\f[R] را برای انجام یک کامپایل پایه
شرح می‌دهد.
.PP
برای جزئیات بیشتر هنگام کامپایل برای نسخه‌ای از پلتفرم که از ماژول‌ها پشتیبانی
می‌کند، به بخش \f[B]Configuring the Module System\f[R] مراجعه کنید.
.SS "فایل‌های منبع"
.IP \[bu] 2
فایل‌های منبع مورد نظر برای کامپایل را در خط فرمان مشخص کنید.
.PP
در صورت نبود خطای کامپایل، فایل‌های کلاس متناظر در \f[B]دایرکتوری خروجی\f[R]
قرار خواهند گرفت.
.PP
برخی سیستم‌ها ممکن است مقداری را که می‌توانید در خط فرمان وارد کنید محدود
سازند؛ برای دور زدن این محدودیت‌ها، می‌توانید از \f[B]فایل‌های آرگومان (argument files)\f[R]
استفاده کنید.
.PP
هنگام کامپایل کدها برای ماژول‌ها، همچنین می‌توانید فایل‌های منبع را به‌صورت
غیرمستقیم با استفاده از گزینه \f[B]\f[BC]\-\-module\f[B]\f[R] یا \f[CB]\-m\f[R]
مشخص کنید.
.SS "دایرکتوری خروجی"
.IP \[bu] 2
از گزینه \f[B]\f[BC]\-d\f[B]\f[R] برای مشخص کردن یک دایرکتوری خروجی جهت
قرار دادن فایل‌های کلاس کامپایل‌شده استفاده کنید.
.PP
این دایرکتوری معمولاً در قالب یک \f[B]سلسله‌مراتب بسته‌ها\f[R] سازمان‌دهی می‌شود،
مگر اینکه کدهای منبع چندین ماژول را کامپایل کنید که در این صورت به‌صورت یک
\f[B]سلسله‌مراتب ماژول‌ها\f[R] سازمان‌دهی خواهد شد.
.PP
پس از اتمام کامپایل، چنانچه یک یا چند ماژول را کامپایل کرده باشید، می‌توانید
دایرکتوری خروجی را در مسیر ماژول (module path) برای \f[B]راه‌انداز (launcher)\f[R]
جاوا قرار دهید؛ در غیر این صورت، می‌توانید دایرکتوری خروجی را در مسیر کلاس
(class path) برای راه‌انداز جاوا تعیین کنید..SS کد از پیش کامپایل‌شده
.PP
کدی که قرار است کامپایل شود ممکن است به کتابخانه‌هایی فراتر از آنچه توسط پلتفرم ارائه شده است ارجاع دهد.
اگر چنین است، باید این کتابخانه‌ها را در مسیر کلاس یا مسیر ماژول قرار دهید.
اگر کد کتابخانه در یک ماژول قرار ندارد، آن را در مسیر کلاس بگذارید؛ اگر درون یک ماژول است، آن را در مسیر ماژول قرار دهید.
.IP \[bu] 2
از گزینهٔ \f[B]\f[BC]\-\-class\-path\f[B]\f[R] برای مشخص کردن کتابخانه‌هایی که باید در مسیر کلاس قرار گیرند استفاده کنید.
مکان‌ها در مسیر کلاس باید در یک \f[B]سلسله‌مراتب بسته\f[R] سازمان‌دهی شوند.
همچنین می‌توانید از اشکال دیگر این گزینه استفاده کنید: \f[CB]\-classpath\f[R] یا \f[CB]\-cp\f[R].
.IP \[bu] 2
از گزینهٔ \f[B]\f[BC]\-\-module\-path\f[B]\f[R] برای مشخص کردن کتابخانه‌هایی که باید در مسیر ماژول قرار گیرند استفاده کنید.
مکان‌ها در مسیر ماژول باید ماژول یا دایرکتوری‌هایی از ماژول‌ها باشند.
همچنین می‌توانید از شکل جایگزین این گزینه استفاده کنید: \f[CB]\-p\f[R].
.RS 2
.PP
برای جزئیات بیشتر دربارهٔ نحوهٔ تغییر پیکربندی پیش‌فرض ماژول‌های کتابخانه‌ای، \f[B]Configuring the Module System\f[R] را ببینید.
.RE
.PP
\f[B]نکته\f[R]: گزینه‌های مربوط به مسیر کلاس و مسیر ماژول مانعة‌الجمع نیستند، اگرچه هنگام کامپایل کد برای یک یا چند ماژول، مشخص کردن مسیر کلاس مرسوم نیست.
.SS فایل‌های منبع اضافی
.PP
کدی که قرار است کامپایل شود ممکن است به انواعی در فایل‌های منبع اضافی که در خط فرمان مشخص نشده‌اند ارجاع دهد.
اگر چنین است، باید آن فایل‌های منبع را در مسیر منبع یا مسیر ماژول قرار دهید.
تنها می‌توانید یکی از این گزینه‌ها را مشخص کنید: اگر کدی را برای یک ماژول کامپایل نمی‌کنید، یا تنها برای یک ماژول واحد کد کامپایل می‌کنید، از مسیر منبع استفاده کنید؛ اگر کد را برای چند ماژول کامپایل می‌کنید، از مسیر منبع ماژول بهره ببرید.
.IP \[bu] 2
از گزینهٔ \f[B]\f[BC]\-\-source\-path\f[B]\f[R] برای مشخص کردن مکان‌های فایل‌های منبع تکمیلی که ممکن است توسط javac خوانده شوند استفاده کنید.
مکان‌ها در مسیر منبع باید در یک \f[B]سلسله‌مراتب بسته\f[R] سازمان‌دهی شوند.
همچنین می‌توانید از شکل دیگر این گزینه استفاده کنید: \f[CB]\-sourcepath\f[R].
.IP \[bu] 2
از گزینهٔ \f[B]\f[BC]\-\-module\-source\-path\f[B]\f[R] یک یا چند بار برای مشخص کردن مکان فایل‌های منبع اضافی در ماژول‌های مختلف که ممکن است توسط javac خوانده شوند، یا هنگام کامپایل فایل‌های منبع در چندین ماژول استفاده کنید.
می‌توانید مکان‌ها را برای هر ماژول به‌صورت \f[B]جداگانه\f[R] مشخص کنید، یا فایل‌های منبع را طوری سازمان‌دهی کنید که بتوانید تمام مکان‌ها را به‌طور \f[B]یک‌جا\f[R] تعیین نمایید.
برای جزئیات بیشتر، \f[B]The Module Source Path Option\f[R] را ببینید.
.PP
اگر می‌خواهید بتوانید به انواع در فایل‌های منبع اضافی ارجاع دهید اما مایل نیستید آن‌ها کامپایل شوند، از گزینهٔ \f[B]\f[BC]\-implicit\f[B]\f[R] استفاده کنید.
.PP
\f[B]نکته\f[R]: اگر کدی را برای چندین ماژول کامپایل می‌کنید، همیشه باید مسیر منبع ماژول را مشخص نمایید، و تمام فایل‌های منبع مشخص‌شده در خط فرمان باید درون یکی از دایرکتوری‌های واقع در مسیر منبع ماژول یا زیردایرکتوری‌های آن باشند.
.SS مثال کامپایل چندین فایل منبع
.PP
این مثال فایل‌های منبع \f[CB]Aloha.java\f[R]، \f[CB]GutenTag.java\f[R]، \f[CB]Hello.java\f[R] و \f[CB]Hi.java\f[R] را در بستهٔ \f[CB]greetings\f[R] کامپایل می‌کند.
.PP
\f[B]لینوکس و macOS:\f[R]
.IP
.nf
\f[CB]
%\ javac\ greetings/*.java
%\ ls\ greetings
Aloha.class\ \ \ \ \ \ \ \ \ GutenTag.class\ \ \ \ \ \ Hello.class\ \ \ \ \ \ \ \ \ Hi.class
Aloha.java\ \ \ \ \ \ \ \ \ \ GutenTag.java\ \ \ \ \ \ \ Hello.java\ \ \ \ \ \ \ \ \ \ Hi.java
\f[R]
.fi
.PP
\f[B]ویندوز:\f[R]
.IP
.nf
\f[CB]
C:\\>javac\ greetings\\*.java
C:\\>dir\ greetings
Aloha.class\ \ \ \ \ \ \ \ \ GutenTag.class\ \ \ \ \ \ Hello.class\ \ \ \ \ \ \ \ \ Hi.class
Aloha.java\ \ \ \ \ \ \ \ \ \ GutenTag.java\ \ \ \ \ \ \ Hello.java\ \ \ \ \ \ \ \ \ \ Hi.java
\f[R]
.fi
.SS مثال تعیین مسیر کلاس کاربر
.PP
پس از ایجاد تغییر در یکی از فایل‌های منبع در مثال قبلی، آن را دوباره کامپایل کنید:
.PP
\f[B]لینوکس و macOS:\f[R]
.IP
.nf
\f[CB]
pwd
/examples
javac\ greetings/Hi.java
\f[R]
.fi
.PP
\f[B]ویندوز:\f[R]
.IP
.nf
\f[CB]
C:\\>cd
\\examples
C:\\>javac\ greetings\\Hi.java
\f[R]
.fi
.PP
از آنجا که \f[CB]greetings.Hi\f[R] به کلاس‌های دیگر در بستهٔ \f[CB]greetings\f[R] ارجاع می‌دهد، کامپایلر باید این کلاس‌های دیگر را پیدا کند.
مثال قبلی به این دلیل کار می‌کند که مسیر پیش‌فرض کلاس کاربر، همان دایرکتوری‌ای است که دایرکتوری بسته را در بر دارد.
اگر می‌خواهید این فایل را بدون نگرانی از اینکه در کدام دایرکتوری قرار دارید دوباره کامپایل کنید، دایرکتوری examples را با تنظیم متغیر محیطی \f[CB]CLASSPATH\f[R] به مسیر کلاس کاربر اضافه نمایید.
این مثال از گزینهٔ \f[CB]\-classpath\f[R] استفاده می‌کند.
.PP
\f[B]لینوکس و macOS:\f[R]
.RS
.PP
\f[CB]javac\ \-classpath\ /examples\ /examples/greetings/Hi.java\f[R]
.RE
.PP
\f[B]ویندوز:\f[R]
.RS
.PP
\f[CB]C:\\>javac\ \-classpath\ \\examples\ \\examples\\greetings\\Hi.java\f[R]
.RE
.PP
اگر \f[CB]greetings.Hi\f[R] را تغییر دهید تا از یک ابزار بنر استفاده کند، آن ابزار نیز باید از طریق مسیر کلاس کاربر در دسترس باشد.
.PP
\f[B]لینوکس و macOS:\f[R]
.IP
.nf
\f[CB]
javac\ \-classpath\ /examples:/lib/Banners.jar\ \\
\ \ \ \ \ \ \ \ \ \ \ \ /examples/greetings/Hi.java
\f[R]
.fi
.PP
\f[B]ویندوز:\f[R]
.IP
.nf
\f[CB]
C:\\>javac\ \-classpath\ \\examples;\\lib\\Banners.jar\ ^
\ \ \ \ \ \ \ \ \ \ \ \ \\examples\\greetings\\Hi.java
\f[R]
.fi
.PP
برای اجرای یک کلاس در بستهٔ \f[CB]greetings\f[R]، برنامه نیازمند دسترسی به بستهٔ \f[CB]greetings\f[R] و همچنین کلاس‌هایی است که کلاس‌های درون \f[CB]greetings\f[R] از آن‌ها استفاده می‌کنند.
.PP
\f[B]لینوکس و macOS:\f[R]
.RS
.PP
\f[CB]java\ \-classpath\ /examples:/lib/Banners.jar\ greetings.Hi\f[R]
.RE
.PP
\f[B]ویندوز:\f[R]
.RS
.PP
\f[CB]C:\\>java\ \-classpath\ \\examples;\\lib\\Banners.jar\ greetings.Hi\f[R]
.RE.SH "پیکربندی سامانه ماژول (CONFIGURING THE MODULE SYSTEM)"
.PP
اگر می‌خواهید ماژول‌های بیشتری را در کامپایل خود بگنجانید، از گزینهٔ
\f[B]\f[BC]\-\-add\-modules\f[B]\f[R] استفاده کنید.
این کار ممکن است زمانی لازم باشد که در حال کامپایل کدی هستید که درون یک
ماژول نیست، یا درون یک ماژول خودکار (automatic module) قرار دارد، و کد به
API موجود در ماژول‌های اضافی ارجاع می‌دهد.
.PP
اگر می‌خواهید مجموعه ماژول‌ها را در کامپایل خود محدود کنید، از گزینهٔ
\f[B]\f[BC]\-\-limit\-modules\f[B]\f[R] استفاده کنید.
این کار در صورتی مفید است که بخواهید اطمینان حاصل کنید کدی که کامپایل
می‌کنید قادر است روی سیستمی با مجموعهٔ محدودی از ماژول‌های نصب‌شده اجرا شود.
.PP
اگر می‌خواهید کپسوله‌سازی (encapsulation) را بشکنید و مشخص کنید که بسته‌های
اضافی باید به عنوان صادرشده (exported) از یک ماژول در نظر گرفته شوند، از
گزینهٔ \f[B]\f[BC]\-\-add\-exports\f[B]\f[R] استفاده کنید.
این کار ممکن است هنگام انجام آزمون جعبه‌سفید (white\-box testing) مفید باشد؛
اتکا به دسترسی به API داخلی در کد محیط عملیاتی اکیداً توصیه نمی‌شود.
.PP
اگر می‌خواهید مشخص کنید که بسته‌های اضافی باید به عنوان نیازمندی توسط یک
ماژول در نظر گرفته شوند، از گزینهٔ \f[B]\f[BC]\-\-add\-reads\f[B]\f[R]
استفاده کنید.
این کار ممکن است هنگام انجام آزمون جعبه‌سفید مفید باشد؛ اتکا به دسترسی به
API داخلی در کد محیط عملیاتی اکیداً توصیه نمی‌شود.
.PP
می‌توانید با استفاده از گزینهٔ \f[B]\f[BC]\-\-patch\-module\f[B]\f[R]
محتوای اضافی را به درون هر ماژولی وصله کنید.
برای جزئیات بیشتر به [Patching a Module] مراجعه کنید.
.SH "جستجوی اعلان‌های ماژول، بسته و نوع (SEARCHING FOR MODULE, PACKAGE AND TYPE DECLARATIONS)"
.PP
برای کامپایل یک فایل منبع، کامپایلر اغلب به اطلاعاتی دربارهٔ یک ماژول یا
نوع (type) نیاز دارد، در حالی که اعلان آن در فایل‌های منبعِ مشخص‌شده در خط
فرمان وجود ندارد.
.PP
\f[CB]javac\f[R] برای هر کلاس یا واسطی (interface) که در فایل منبع استفاده
شده، گسترش یافته (extended)، یا پیاده‌سازی شده (implemented) است، به اطلاعات
نوع نیاز دارد.
این شامل کلاس‌ها و واسط‌هایی نیز می‌شود که به صراحت در فایل منبع ذکر نشده‌اند،
اما اطلاعات را از طریق وراثت ارائه می‌دهند.
.PP
برای نمونه، هنگامی که یک زیرکلاس از \f[CB]java.awt.Window\f[R] ایجاد می‌کنید،
از کلاس‌های والد \f[CB]Window\f[R] نیز استفاده می‌کنید:
\f[CB]java.awt.Container\f[R]، \f[CB]java.awt.Component\f[R]، و
\f[CB]java.lang.Object\f[R].
.PP
هنگام کامپایل کد برای یک ماژول، کامپایلر همچنین نیاز دارد که اعلان آن ماژول را
در دسترس داشته باشد.
.PP
یک جستجوی موفق ممکن است یک فایل کلاس، یک فایل منبع، یا هر دو را پیدا کند.
اگر هر دو یافت شوند، می‌توانید از گزینهٔ \f[B]\f[BC]\-Xprefer\f[B]\f[R]
استفاده کنید تا به کامپایلر دستور دهید از کدام‌یک استفاده کند.
.PP
اگر جستجو یک فایل منبع را پیدا کند و به کار ببرد، به طور پیش‌فرض
\f[CB]javac\f[R] آن فایل منبع را کامپایل می‌کند.
این رفتار را می‌توان با \f[B]\f[BC]\-implicit\f[B]\f[R] تغییر داد.
.PP
ممکن است کامپایلر تا پس از اتمام پردازش یادداشت‌ها (annotation processing)
پی به نیاز به برخی اطلاعات نوع نبرد.
هنگامی که اطلاعات نوع در یک فایل منبع یافت شود و هیچ گزینهٔ
\f[B]\f[BC]\-implicit\f[B]\f[R] مشخص نشده باشد، کامپایلر هشداری می‌دهد مبنی
بر اینکه فایل بدون قرار گرفتن تحت پردازش یادداشت‌ها در حال کامپایل شدن است.
برای غیرفعال کردن این هشدار، یا فایل را در خط فرمان مشخص کنید (تا مشمول
پردازش یادداشت‌ها شود) یا از گزینهٔ \f[B]\f[BC]\-implicit\f[B]\f[R] برای
تعیین اینکه آیا باید برای چنین فایل‌های منبعی فایل کلاس تولید شود یا خیر،
استفاده نمایید.
.PP
روشی که \f[CB]javac\f[R] اعلان‌های آن نوع‌ها را پیدا می‌کند به این بستگی
دارد که آیا ارجاع در درون کد یک ماژول قرار دارد یا خیر.
.SS "جستجوی مسیرهای بسته‌محور (Searching Package Oriented Paths)"
.PP
هنگام جستجو برای یک فایل منبع یا کلاس در مسیری متشکل از مکان‌های بسته‌محور،
\f[CB]javac\f[R] هر مکان در مسیر را به نوبت برای احتمال حضور فایل بررسی
می‌کند.
اولین رخداد از یک فایل خاص، هرگونه رخداد بعدی فایل‌های هم‌نام را سایه‌اندازی
(پنهان) می‌کند.
این سایه‌اندازی بر جستجو برای فایل‌هایی با نام متفاوت تأثیری نمی‌گذارد.
این ویژگی هنگام جستجوی فایل‌های منبع که ممکن است در مکان‌های متفاوتی گروه‌بندی
شده باشند—مانند کد اشتراکی، کد مختص پلتفرم و کد تولیدشده—می‌تواند بسیار
کارآمد باشد.
همچنین می‌تواند هنگام تزریق نسخه‌های جایگزین یک فایل کلاس به یک بسته، برای
اشکال‌زدایی یا سایر دلایل ابزارسازی (instrumentation) مفید باشد.
اما این کار می‌تواند خطرناک نیز باشد، مانند زمانی که نسخه‌های ناسازگار متفاوتی
از یک کتابخانه در مسیر کلاس (class path) قرار می‌گیرند.
.SS "جستجوی مسیرهای ماژول‌محور (Searching Module Oriented Paths)"
.PP
پیش از پویش هر یک از مسیرهای ماژول برای اعلان‌های بسته یا نوع،
\f[CB]javac\f[R] به صورت تنبل (lazy) مسیرها و مکان‌های زیر را پویش می‌کند تا
ماژول‌هایی را که در کامپایل استفاده خواهند شد مشخص کند:
.IP \[bu] 2
مسیر منبع ماژول (گزینهٔ
\f[B]\f[BC]\-\-module\-source\-path\f[B]\f[R] را ببینید)
.IP \[bu] 2
مسیر ماژول‌های ارتقاپذیر (گزینهٔ
\f[B]\f[BC]\-\-upgrade\-module\-path\f[B]\f[R] را ببینید)
.IP \[bu] 2
ماژول‌های سامانه (گزینهٔ \f[B]\f[BC]\-\-system\f[B]\f[R] را ببینید)
.IP \[bu] 2
مسیر ماژول کاربر (گزینهٔ \f[B]\f[BC]\-\-module\-path\f[B]\f[R]
را ببینید)
.PP
برای هر ماژول، اولین رخداد ماژول در طول پویش، هرگونه ظهور بعدی ماژولی با نام
مشابه را کاملاً سایه‌اندازی (پنهان) می‌کند.
در حین مکان‌یابی ماژول‌ها، \f[CB]javac\f[R] قادر است بسته‌های صادرشده توسط
ماژول را تعیین کرده و به هر ماژول یک مسیر بسته‌محور برای محتویات آن اختصاص دهد.
برای هر ماژول که قبلاً کامپایل شده است، این مسیر معمولاً یک ورودی تکی برای
یک دایرکتوری یا فایلی است که سلسله‌مراتبی دایرکتوری‌مانند درونی فراهم می‌کند،
مانند یک فایل JAR.
بنابراین، هنگام جستجو برای نوعی که در بسته‌ای قرار دارد که صادر شدن آن توسط
یک ماژول مشخص است، \f[CB]javac\f[R] می‌تواند اعلان را مستقیماً و به شکلی
کارآمد پیدا کند.
.SS "جستجو برای اعلان یک ماژول (Searching for the Declaration of a Module)"
.PP
اگر ماژول قبلاً کامپایل شده باشد، اعلان ماژول در فایلی به نام
\f[CB]module\-info.class\f[R] در ریشهٔ سلسله‌مراتب بسته برای محتوای ماژول
قرار دارد.
.PP
اگر ماژول یکی از مواردی باشد که هم‌اکنون در حال کامپایل شدن است، اعلان ماژول
یا فایلی به نام \f[CB]module\-info.class\f[R] در ریشهٔ سلسله‌مراتب بسته برای
ماژول در دایرکتوری خروجی کلاس‌ها خواهد بود، یا فایلی به نام
\f[CB]module\-info.java\f[R] در یکی از مکان‌های موجود در مسیر منبع یا مسیر
منبع ماژول برای آن ماژول..SS "جستجوی اعلان یک نوع هنگامی که ارجاع در یک ماژول نیست"
.PP
هنگام جستجو برای نوعی که در کدی خارج از یک ماژول به آن ارجاع داده شده است، \f[CB]javac\f[R] در مکان‌های زیر جستجو خواهد کرد:
.IP \[bu] 2
کلاس‌های پلتفرم (یا نوع‌های موجود در بسته‌های صادرشدهٔ ماژول‌های پلتفرم) (این مورد تنها برای فایل‌های کلاس کامپایل‌شده است.)
.IP \[bu] 2
نوع‌های موجود در بسته‌های صادرشدهٔ هر یک از ماژول‌های موجود در مسیر ماژول (module path)، در صورت وجود.
(این مورد تنها برای فایل‌های کلاس کامپایل‌شده است.)
.IP \[bu] 2
نوع‌های موجود در بسته‌های روی مسیر کلاس (class path) و/یا مسیر منبع (source path):
.RS 2
.IP \[bu] 2
اگر هر دو مشخص شده باشند، \f[CB]javac\f[R] به دنبال فایل‌های کلاس کامپایل‌شده در مسیر کلاس و فایل‌های منبع در مسیر منبع می‌گردد.
.IP \[bu] 2
اگر مسیر کلاس مشخص شده باشد اما مسیر منبع مشخص نشده باشد، \f[CB]javac\f[R] به دنبال هر دو مورد، یعنی فایل‌های کلاس کامپایل‌شده و فایل‌های منبع در مسیر کلاس می‌گردد.
.IP \[bu] 2
اگر مسیر کلاس مشخص نشده باشد، مقدار پیش‌فرض آن دایرکتوری جاری خواهد بود.
.RE
.PP
هنگام جستجوی یک نوع در مسیر کلاس و/یا مسیر منبع، اگر هم فایل کلاس کامپایل‌شده و هم فایل منبع یافت شوند، به‌طور پیش‌فرض فایلی که اخیراً تغییر یافته استفاده خواهد شد.
اگر فایل منبع جدیدتر باشد، کامپایل خواهد شد و ممکن است جایگزین هر نسخهٔ از قبل کامپایل‌شده‌ای از آن فایل شود.
می‌توانید از گزینهٔ \f[B]\f[BC]\-Xprefer\f[B]\f[R] برای لغو رفتار پیش‌فرض استفاده کنید.
.SS "جستجوی اعلان یک نوع هنگامی که ارجاع در یک ماژول است"
.PP
هنگام جستجو برای نوعی که در کدِ درون یک ماژول به آن ارجاع داده شده است، \f[CB]javac\f[R] اعلان ماژولِ دربرگیرنده را بررسی می‌کند تا مشخص کند آیا آن نوع در بسته‌ای قرار دارد که از ماژول دیگری صادر شده و توسط ماژول دربرگیرنده خواندنی است یا خیر.
در این صورت، \f[CB]javac\f[R] به‌سادگی و به‌طور مستقیم به تعریف آن ماژول می‌رود تا تعریف نوع مورد نیاز را پیدا کند.
مگر اینکه آن ماژول یکی دیگر از ماژول‌های در حال کامپایل باشد، \f[CB]javac\f[R] تنها به دنبال فایل‌های کلاس کامپایل‌شده خواهد گشت.
به عبارت دیگر، \f[CB]javac\f[R] به دنبال فایل‌های منبع در ماژول‌های پلتفرم یا ماژول‌های موجود در مسیر ماژول نخواهد گشت.
.PP
اگر نوع مورد ارجاع در ماژول خواندنی دیگری نباشد، \f[CB]javac\f[R] ماژول در حال کامپایل را بررسی می‌کند تا اعلان آن نوع را بیابد.
\f[CB]javac\f[R] به دنبال اعلان نوع به صورت زیر خواهد گشت:
.IP \[bu] 2
فایل‌های منبع مشخص‌شده در خط فرمان یا در مسیر منبع (source path) یا مسیر منبع ماژول (module source path).
.IP \[bu] 2
فایل‌های از قبل کامپایل‌شده در دایرکتوری خروجی.
.SH "سلسله‌مراتب‌های دایرکتوری (DIRECTORY HIERARCHIES)"
.PP
\f[CB]javac\f[R] به‌طور کلی فرض می‌کند که فایل‌های منبع و فایل‌های کلاس کامپایل‌شده در سلسله‌مراتب دایرکتوریِ سیستم فایل، یا در نوعی فایل که از سلسله‌مراتب دایرکتوری داخلی پشتیبانی می‌کند (مانند فایل JAR)، سازمان‌دهی خواهند شد.
سه نوع سلسله‌مراتب مختلف پشتیبانی می‌شود: \f[I]سلسله‌مراتب بسته (package hierarchy)\f[R]، \f[I]سلسله‌مراتب ماژول (module hierarchy)\f[R]، و \f[I]سلسله‌مراتب منبع ماژول (module source hierarchy)\f[R].
.PP
اگرچه \f[CB]javac\f[R] در مورد سازمان‌دهی کد منبع (فراتر از این انتظار که منبع در یک یا چند سلسله‌مراتب بسته سازمان‌دهی شود) رفتار نسبتاً منعطفی دارد و عموماً می‌تواند با ساختارهای تعیین‌شده توسط محیط‌های توسعه و ابزارهای ساخت سازگار شود، اما ابزارهای جاوا به‌طور کلی، و \f[CB]javac\f[R] و راه‌انداز جاوا به‌طور خاص، در رابطه با سازمان‌دهی فایل‌های کلاس کامپایل‌شده سخت‌گیرتر هستند و آنها را بر حسب مورد، در سلسله‌مراتب‌های بسته یا سلسله‌مراتب‌های ماژول سازمان‌دهی می‌کنند.
.PP
مکان این سلسله‌مراتب‌ها با گزینه‌های خط فرمان به \f[CB]javac\f[R] مشخص می‌شود؛ گزینه‌هایی که نام آن‌ها معمولاً به «path» ختم می‌شود، مانند \f[B]\f[BC]\-\-source\-path\f[B]\f[R] یا \f[B]\f[BC]\-\-class\-path\f[B]\f[R].
همچنین به عنوان یک قاعده کلی، گزینه‌های مسیری که نام آن‌ها شامل واژهٔ \f[CB]module\f[R] است، مانند \f[B]\f[BC]\-\-module\-path\f[B]\f[R]، برای مشخص کردن سلسله‌مراتب‌های ماژول به کار می‌روند، اگرچه برخی از گزینه‌های مسیر مرتبط با ماژول اجازه می‌دهند سلسله‌مراتب بسته به ازای هر ماژول تعیین شود.
تمام گزینه‌های مسیر دیگر برای تعیین سلسله‌مراتب‌های بسته استفاده می‌شوند.
.SS "سلسله‌مراتب بسته (Package Hierarchy)"
.PP
در یک سلسله‌مراتب بسته، از دایرکتوری‌ها و زیردایرکتوری‌ها برای نمایش بخش‌های تشکیل‌دهندهٔ نام بسته استفاده می‌شود، به‌طوری که فایل منبع یا فایل کلاس کامپایل‌شده برای یک نوع به صورت فایلی با پسوند \f[CB]\&.java\f[R] یا \f[CB]\&.class\f[R] در تو در تو ترین دایرکتوری ذخیره می‌شود.
.PP
برای نمونه، در یک سلسله‌مراتب بسته، فایل منبع برای کلاس \f[CB]com.example.MyClass\f[R] در فایل \f[I]com/example/MyClass.java\f[R] ذخیره خواهد شد.
.SS "سلسله‌مراتب ماژول (Module Hierarchy)"
.PP
در یک سلسله‌مراتب ماژول، سطح اول دایرکتوری‌ها با نام ماژول‌های موجود در سلسله‌مراتب نام‌گذاری می‌شوند؛ درون هر یک از آن دایرکتوری‌ها، محتویات ماژول در سلسله‌مراتب‌های بسته سازمان‌دهی می‌شوند.
.PP
برای نمونه، در یک سلسله‌مراتب ماژول، فایل کلاس کامپایل‌شده برای نوعی به نام \f[CB]com.example.MyClass\f[R] در ماژولی به نام \f[CB]my.library\f[R] در \f[I]my.library/com/example/MyClass.class\f[R] ذخیره خواهد شد.
.PP
دایرکتوری‌های خروجی گوناگونی که توسط \f[CB]javac\f[R] استفاده می‌شوند (دایرکتوری خروجی کلاس، دایرکتوری خروجی منبع، و دایرکتوری خروجی سرایند بومی/native header) هنگامی که چندین ماژول کامپایل می‌شوند، همگی در یک سلسله‌مراتب ماژول سازمان‌دهی خواهند شد.
.SS "سلسله‌مراتب منبع ماژول (Module Source Hierarchy)"
.PP
اگرچه منبع هر ماژول مجزا همیشه باید در یک سلسله‌مراتب بسته سازمان‌دهی شود، ممکن است گروه‌بندی این سلسله‌مراتب‌ها در یک سلسله‌مراتب منبع ماژول راحت‌تر باشد.
این ساختار شبیه به یک سلسله‌مراتب ماژول است، با این تفاوت که ممکن است دایرکتوری‌های واسطه‌ای بین دایرکتوری مربوط به ماژول و دایرکتوری ریشهٔ سلسله‌مراتب بسته برای کد منبع ماژول وجود داشته باشد.
.PP
برای نمونه، در یک سلسله‌مراتب منبع ماژول، فایل منبع نوعی به نام \f[CB]com.example.MyClass\f[R] در ماژولی به نام \f[CB]my.library\f[R] ممکن است در فایلی مانند \f[I]my.library/src/main/java/com/example/MyClass.java\f[R] ذخیره شود..SH "گزینه مسیر منبع ماژول (THE MODULE SOURCE PATH OPTION)"
.PP
گزینهٔ \f[B]\f[BC]\-\-module\-source\-path\f[B]\f[R] دارای دو شکل است: یک
\f[I]شکل مختص ماژول (module\-specific)\f[R] که در آن برای هر ماژولِ
حاوی کدی که باید کامپایل شود، یک مسیر بسته مشخص می‌گردد، و یک
شکل \f[I]الگوی ماژول (module\-pattern)\f[R] که در آن مسیر منبع برای هر
ماژول توسط یک الگو تعیین می‌شود.
شکل مختص ماژول معمولاً زمانی که تنها تعداد کمی ماژول در کار باشند ساده‌تر
است؛ شکل الگوی ماژول ممکن است زمانی که تعداد ماژول‌ها زیاد باشد و ماژول‌ها
به شیوه‌ای منظم و قابل توصیف با یک الگو سازمان‌دهی شده باشند، راحت‌تر باشد.
.PP
می‌توان چندین نمونه از گزینهٔ \f[CB]\-\-module\-source\-path\f[R] را
مشخص کرد که هر یک از شکل الگوی ماژول یا شکل مختص ماژول استفاده می‌کند،
مشروط بر محدودیت‌های زیر:
.IP \[bu] 2
شکل الگوی ماژول حداکثر یک بار می‌تواند استفاده شود
.IP \[bu] 2
شکل مختص ماژول برای هر ماژول داده‌شده حداکثر یک بار می‌تواند استفاده شود
.PP
اگر از شکل مختص ماژول برای هر ماژولی استفاده شود، مسیر جستجوی مرتبط با آن
بر هر مسیری که در غیر این صورت ممکن بود از شکل الگوی ماژول استنباط شود،
اولویت خواهد داشت.
.SS "شکل مختص ماژول (Module\-specific form)"
.PP
شکل مختص ماژول امکان تعیین یک مسیر جستجوی صریح را برای هر ماژول خاص فراهم
می‌کند.
این شکل به صورت زیر است:
.IP \[bu] 2
\f[CB]\-\-module\-source\-path\f[R]
\f[I]module\-name\f[R]\f[CB]=\f[R]\f[I]file\-path\f[R]
(\f[I]path\-separator\f[R] \f[I]file\-path\f[R])*
.PP
نویسهٔ جداکننده مسیر در ویندوز \f[CB];\f[R] و در غیر این صورت \f[CB]:\f[R]
است.
.PP
\f[B]نکته:\f[R] این ساختار شبیه شکلی است که برای گزینهٔ
\f[B]\f[BC]\-\-patch\-module\f[B]\f[R] استفاده می‌شود.
.SS "شکل الگوی ماژول (Module\-pattern form)"
.PP
شکل الگوی ماژول امکان تعریف موجز مسیر منبع ماژول را برای هر تعداد ماژول که
به شیوه‌ای منظم سازمان‌یافته‌اند فراهم می‌کند.
.IP \[bu] 2
\f[CB]\-\-module\-source\-path\f[R] \f[I]pattern\f[R]
.PP
الگو بر اساس قواعد زیر که به ترتیب اعمال می‌شوند، تعریف می‌گردد:
.IP \[bu] 2
آرگومان به عنوان مجموعه‌ای از بخش‌ها در نظر گرفته می‌شود که با نویسهٔ
جداکنندهٔ مسیر (\f[CB];\f[R] در ویندوز، و در غیر این صورت \f[CB]:\f[R])
از هم جدا شده‌اند.
.IP \[bu] 2
هر بخش حاوی آکولادهایی به شکل
.RS 2
.IP
.nf
\f[CB]
string1{alt1\ (\ ,alt2\ )*\ }\ string2
\f[R]
.fi
.PP
به‌گونه‌ای در نظر گرفته می‌شود که با مجموعه‌ای از بخش‌ها که با «بسط دادن»
آکولادها حاصل می‌شوند جایگزین می‌گردد:
.IP
.nf
\f[CB]
string1\ alt1\ string2
string1\ alt2\ string2
and\ so\ on...
\f[R]
.fi
.PP
آکولادها می‌توانند تودرتو باشند.
.PP
این قاعده برای تمام چنین کاربردهایی از آکولادها اعمال می‌شود.
.RE
.IP \[bu] 2
هر بخش باید حداکثر یک ستاره (\f[CB]*\f[R]) داشته باشد.
اگر بخشی فاقد ستاره باشد، چنان در نظر گرفته می‌شود که گویی نویسهٔ جداکنندهٔ
پرونده و یک ستاره به انتهای آن ضمیمه شده است.
.RS 2
.PP
برای هر ماژول \f[I]M\f[R]، مسیر منبع برای آن ماژول از مجموعه‌ای از بخش‌ها
تشکیل می‌شود که با جایگزین کردن نام ماژول \f[I]M\f[R] به‌جای ستاره در هر
بخش به دست می‌آیند.
.PP
\f[B]نکته\f[R]: در این زمینه، ستاره صرفاً به عنوان یک نشانگر ویژه جهت
مشخص کردن جایگاه نام ماژول در مسیر به کار می‌رود.
نباید آن را با کاربرد \f[CB]*\f[R] به عنوان نویسه عمومی نام پرونده
(wildcard) که در اکثر سیستم‌عامل‌ها مرسوم است، اشتباه گرفت.
.RE
.SH "وصله‌کردن ماژول‌ها (PATCHING MODULES)"
.PP
دستور javac اجازه می‌دهد هر محتوایی، چه در قالب کد مبدا و چه به شکل
کامپایل‌شده، با استفاده از گزینهٔ \f[B]\f[BC]\-\-patch\-module\f[B]\f[R]
به هر ماژولی وصله شود.
ممکن است بخواهید این کار را برای کامپایل کردن پیاده‌سازی‌های جایگزین از یک
کلاس به منظور وصله‌شدن در زمان اجرا به یک JVM، یا برای تزریق کلاس‌های اضافی
به ماژول (مانند زمان آزمودن) انجام دهید.
.PP
شکل این گزینه عبارت است از:
.IP \[bu] 2
\f[CB]\-\-patch\-module\f[R]
\f[I]module\-name\f[R]\f[CB]=\f[R]\f[I]file\-path\f[R]
(\f[I]path\-separator\f[R] \f[I]file\-path\f[R] )*
.PP
نویسهٔ جداکننده مسیر در ویندوز \f[CB];\f[R] و در غیر این صورت \f[CB]:\f[R]
است.
مسیرهای داده‌شده برای ماژول باید ریشه سلسله‌مراتب بسته را برای محتویات آن
ماژول مشخص کنند.
.PP
این گزینه برای هر ماژول مشخص حداکثر می‌تواند یک بار داده شود.
هر محتوایی در این مسیر، محتوای هم‌نام بعدی در مسیر و در ماژول وصله‌شده را
پنهان خواهد کرد.
.PP
هنگام وصله‌کردن کد مبدا به بیش از یک ماژول، گزینهٔ
\f[B]\f[BC]\-\-module\-source\-path\f[B]\f[R] نیز باید به کار رود تا
دایرکتوری خروجی در یک سلسله‌مراتب ماژول سازمان‌دهی شده و توانایی نگهداری
پرونده‌های کلاس کامپایل‌شده را برای ماژول‌های در حال کامپایل داشته باشد.
.SH "پردازش حاشیه‌نویسی (ANNOTATION PROCESSING)"
.PP
دستور \f[CB]javac\f[R] پشتیبانی مستقیمی را از پردازش حاشیه‌نویسی‌ها
(annotation processing) فراهم می‌کند.
.PP
رابط برنامه‌نویسی (API) مربوط به پردازنده‌های حاشیه‌نویسی در بسته‌ها و
زیربسته‌های \f[CB]javax.annotation.processing\f[R] و
\f[CB]javax.lang.model\f[R] تعریف شده است..SS سازوکار پردازش حاشیه‌نویسی‌ها (How Annotation Processing Works)
.PP
مگر آن‌که پردازش حاشیه‌نویسی با گزینهٔ \f[B]\f[BC]\-proc:none\f[B]\f[R]
غیرفعال شده باشد، کامپایلر برای یافتن پردازشگرهای حاشیه‌نویسی در دسترس
جستجو می‌کند.
مسیر جستجو را می‌توان با گزینهٔ \f[B]\f[BC]\-processorpath\f[B]\f[R]
مشخص کرد.
اگر مسیری مشخص نشود، از مسیر کلاس کاربر (user class path) استفاده می‌شود.
پردازشگرها با استفاده از فایل‌های پیکربندی ارائه‌دهندهٔ خدمات به نام
\f[CB]META\-INF/services/javax.annotation.processing\f[R].Processor
در مسیر جستجو یافته می‌شوند.
چنین فایل‌هایی باید حاوی نام‌های پردازشگرهای حاشیه‌نویسیِ مورد استفاده باشند
که در هر سطر یک نام درج شده است.
همچنین می‌توان پردازشگرها را صراحتاً با استفاده از گزینهٔ
\f[B]\f[BC]\-processor\f[B]\f[R] مشخص کرد.
.PP
پس از بررسی فایل‌های منبع و کلاس‌ها در خط فرمان برای تعیین حاشیه‌نویسی‌های
موجود، کامپایلر پردازشگرها را وارسی می‌کند تا مشخص کند چه حاشیه‌نویسی‌هایی
را پردازش می‌کنند.
هنگامی که یک تطابق پیدا شود، آن پردازشگر فراخوانی می‌شود.
یک پردازشگر می‌تواند مدعی مالکیت (claim) حاشیه‌نویسی‌هایی شود که پردازش می‌کند؛
در این صورت تلاش دیگری برای یافتن پردازشگر برای آن حاشیه‌نویسی‌ها انجام نمی‌شود.
پس از آن‌که ادعای مالکیت تمام حاشیه‌نویسی‌ها انجام شد، کامپایلر به دنبال
پردازشگرهای بیشتری نمی‌گردد.
.PP
اگر پردازشگری فایل‌های منبع جدیدی تولید کند، دور دیگری از پردازش حاشیه‌نویسی
رخ می‌دهد: تمامی فایل‌های منبع تازه تولیدشده بررسی شده و حاشیه‌نویسی‌ها
همانند قبل پردازش می‌شوند.
هر پردازشگری که در دورهای پیشین فراخوانی شده باشد، در تمامی دورهای بعدی نیز
فراخوانی می‌شود.
این روند تا زمانی که هیچ فایل منبع جدیدی تولید نشود ادامه می‌یابد.
.PP
پس از پایان دوری که در آن هیچ فایل منبع جدیدی تولید نشده باشد، پردازشگرهای
حاشیه‌نویسی برای آخرین بار فراخوانی می‌شوند تا فرصتی برای تکمیل کارهای باقی‌مانده
داشته باشند.
در نهایت، مگر در صورتی که از گزینهٔ \f[B]\f[BC]\-proc:only\f[B]\f[R] استفاده
شده باشد، کامپایلر فایل‌های منبع اصلی و تمامی فایل‌های تولیدشده را کامپایل می‌کند.
.PP
اگر از یک پردازشگر حاشیه‌نویسی استفاده می‌کنید که فایل‌های منبع اضافی را برای
گنجانده شدن در کامپایل تولید می‌کند، می‌توانید یک ماژول پیش‌فرض را برای فایل‌های
تازه تولیدشده تعیین کنید تا در مواردی که اعلان ماژول تولید نشده است استفاده شود.
در این حالت، از گزینهٔ
\f[B]\f[BC]\-\-default\-module\-for\-created\-files\f[B]\f[R] استفاده کنید.
.SS محیط کامپایل و محیط زمان اجرا (Compilation Environment and Runtime Environment)
.PP
اعلان‌های موجود در فایل‌های منبع و فایل‌های کلاس کامپایل‌شدهٔ قبلی توسط
\f[CB]javac\f[R] در یک \f[I]محیط کامپایل\f[R] تحلیل می‌شوند که از
\f[I]محیط زمان اجرا\f[R] مورد استفاده برای اجرای خودِ \f[CB]javac\f[R] متمایز است.
اگرچه شباهت عمدی میان بسیاری از گزینه‌های \f[CB]javac\f[R] و گزینه‌های هم‌نام
برای \f[B]launcher\f[R] جاوا وجود دارد، مانند \f[CB]\-\-class\-path\f[R]،
\f[CB]\-\-module\-path\f[R] و غیره، اما درک این نکته اهمیت دارد که به طور کلی
گزینه‌های \f[CB]javac\f[R] تنها بر محیطی که فایل‌های منبع در آن کامپایل می‌شوند
تأثیر می‌گذارند و بر عملکرد خود \f[CB]javac\f[R] اثری ندارند.
.PP
تمایز میان محیط کامپایل و محیط زمان اجرا هنگام استفاده از پردازشگرهای حاشیه‌نویسی
اهمیت زیادی دارد.
اگرچه پردازشگرهای حاشیه‌نویسی عناصری (اعلان‌هایی) را پردازش می‌کنند که در محیط
کامپایل وجود دارند، اما خودِ پردازشگر حاشیه‌نویسی در محیط زمان اجرا اجرا می‌شود.
اگر یک پردازشگر حاشیه‌نویسی به کتابخانه‌هایی وابسته باشد که درون ماژول‌ها نیستند،
این کتابخانه‌ها را می‌توان به همراه خود پردازشگر در مسیر پردازشگر قرار داد.
(گزینهٔ \f[B]\f[BC]\-\-processor\-path\f[B]\f[R] را ببینید.) اگر پردازشگر
حاشیه‌نویسی و وابستگی‌های آن در ماژول‌ها باشند، باید در عوض از مسیر ماژول
پردازشگر استفاده کنید.
(گزینهٔ \f[B]\f[BC]\-\-processor\-module\-path\f[B]\f[R] را ببینید.) در صورتی
که این موارد ناکافی باشند، ممکن است پیکربندی بیشتری برای محیط زمان اجرا لازم باشد.
این کار را می‌توان به دو روش انجام داد:
.IP "1." 3
اگر \f[CB]javac\f[R] از خط فرمان فراخوانی شود، می‌توان با افزودن پیشوند
\f[B]\f[BC]\-J\f[B]\f[R] به گزینه، آن را به زمان اجرای زیرین منتقل کرد.
.IP "2." 3
می‌توانید یک نمونه از Java Virtual Machine را مستقیماً راه‌اندازی کرده و از
گزینه‌های خط فرمان و API برای پیکربندی محیطی استفاده کنید که در آن
\f[CB]javac\f[R] از طریق یکی از \f[B]API\f[R]های خود فراخوانی شود.
.SH "کامپایل برای نگارش‌های پیشین پلتفرم (COMPILING FOR EARLIER RELEASES OF THE PLATFORM)"
.PP
دستور \f[CB]javac\f[R] می‌تواند کدهایی را که قرار است در سایر نگارش‌های
پلتفرم استفاده شوند، با استفاده از گزینهٔ \f[B]\f[BC]\-\-release\f[B]\f[R]،
یا گزینه‌های \f[B]\f[BC]\-\-source\f[B]\f[R]/\f[CB]\-source\f[R] و
\f[B]\f[BC]\-\-target\f[B]\f[R]/\f[CB]\-target\f[R] به همراه گزینه‌های اضافی
جهت تعیین کلاس‌های پلتفرم کامپایل کند.
.PP
بسته به نگارش پلتفرم مورد نظر، محدودیت‌هایی در مورد برخی از گزینه‌های قابل
استفاده وجود دارد.
.IP \[bu] 2
هنگام کامپایل برای JDK 8 و نگارش‌های پیشین آن، نمی‌توانید از هیچ گزینه‌ای که
برای استفاده با سیستم ماژول در نظر گرفته شده است استفاده کنید.
این شامل تمام گزینه‌های زیر است:
.RS 2
.IP \[bu] 2
\f[B]\f[BC]\-\-module\-source\-path\f[B]\f[R],
\f[B]\f[BC]\-\-upgrade\-module\-path\f[B]\f[R],
\f[B]\f[BC]\-\-system\f[B]\f[R], \f[B]\f[BC]\-\-module\-path\f[B]\f[R],
\f[B]\f[BC]\-\-add\-modules\f[B]\f[R],
\f[B]\f[BC]\-\-add\-exports\f[B]\f[R], \f[CB]\-\-add\-opens\f[R],
\f[B]\f[BC]\-\-add\-reads\f[B]\f[R],
\f[B]\f[BC]\-\-limit\-modules\f[B]\f[R],
\f[B]\f[BC]\-\-patch\-module\f[B]\f[R]
.PP
اگر از گزینه‌های \f[CB]\-\-source\f[R]/\f[CB]\-source\f[R] یا
\f[CB]\-\-target\f[R]/\f[CB]\-target\f[R] استفاده می‌کنید، باید کلاس‌های
مناسب پلتفرم را نیز با استفاده از خانوادهٔ گزینه‌های boot class path تنظیم کنید.
.RE
.IP \[bu] 2
هنگام کامپایل برای JDK 9 و نگارش‌های پس از آن، نمی‌توانید از هیچ گزینه‌ای که
برای پیکربندی boot class path در نظر گرفته شده است استفاده کنید.
این شامل تمام گزینه‌های زیر است:
.RS 2
.IP \[bu] 2
\f[B]\f[BC]\-Xbootclasspath/p:\f[B]\f[R],
\f[B]\f[BC]\-Xbootclasspath\f[B]\f[R],
\f[B]\f[BC]\-Xbootclasspath/a:\f[B]\f[R],
\f[B]\f[BC]\-endorseddirs\f[B]\f[R],
\f[B]\f[BC]\-Djava.endorsed.dirs\f[B]\f[R],
\f[B]\f[BC]\-extdirs\f[B]\f[R], \f[B]\f[BC]\-Djava.ext.dirs\f[B]\f[R],
\f[B]\f[BC]\-profile\f[B]\f[R]
.PP
اگر از گزینه‌های \f[CB]\-\-source\f[R]/\f[CB]\-source\f[R] یا
\f[CB]\-\-target\f[R]/\f[CB]\-target\f[R] استفاده می‌کنید، باید کلاس‌های
مناسب پلتفرم را نیز با استفاده از گزینهٔ \f[CB]\-\-system\f[R] مشخص کنید تا
محل نگارش نصب‌شدهٔ مناسب JDK تعیین گردد.
.RE
.PP
هنگام استفاده از گزینهٔ \f[CB]\-\-release\f[R]، تنها APIهای مستند و
پشتیبانی‌شده برای آن نگارش قابل استفاده هستند؛ شما نمی‌توانید از هیچ گزینه‌ای
برای شکستن کپسوله‌سازی به منظور دسترسی به کلاس‌های داخلی استفاده کنید..SH "رابط‌های برنامه‌نویسی (APIS)"
.PP
کامپایلر \f[CB]javac\f[R] می‌تواند با استفاده از یک API به سه روش مختلف فراخوانی شود:
.TP
.B رابط \f[B]Java Compiler API\f[R]
این مورد، منعطف‌ترین روش را برای فراخوانی کامپایلر فراهم می‌کند، از جمله توانایی کامپایل فایل‌های منبع ارائه‌شده در بافرهای حافظه یا سایر سیستم‌های فایل غیراستاندارد.
.RS
.RE
.TP
.B رابط \f[B]ToolProvider API\f[R]
یک \f[CB]ToolProvider\f[R] برای \f[CB]javac\f[R] را می‌توان با فراخوانی \f[CB]ToolProvider.findFirst("javac")\f[R] به دست آورد.
این فراخوانی شیئی با قابلیت‌های معادل ابزار خط فرمان برمی‌گرداند.
.RS
.PP
\f[B]نکته\f[R]: این API نباید با API هم‌نام در بسته \f[B]\f[BC]javax.tools\f[B]\f[R] اشتباه گرفته شود.
.RE
.TP
.B رابط قدیمی \f[CB]javac\f[R] (\f[B]Legacy API\f[R])
این API تنها برای سازگاری با نسخه‌های پیشین حفظ شده است.
تمام کدهای جدید باید از Java Compiler API یا ToolProvider API استفاده کنند.
.RS
.RE
.PP
\f[B]نکته:\f[R] تمام کلاس‌ها و متدهای دیگری که در بسته‌هایی با نام‌های آغازشونده با \f[CB]com.sun.tools.javac\f[R] (زیربسته‌های \f[CB]com.sun.tools.javac\f[R]) یافت می‌شوند، کاملاً داخلی بوده و در هر زمانی ممکن است تغییر کنند.
.SH "مثال‌های استفاده از کلیدهای \-XLINT (EXAMPLES OF USING \-XLINT KEYS)"
.TP
.B \f[CB]cast\f[R]
درباره تبدیل نوع‌های (cast) غیرضروری و زائد هشدار می‌دهد، برای مثال:
.RS
.RS
.PP
\f[CB]String\ s\ =\ (String)\ "Hello!"\f[R]
.RE
.RE
.TP
.B \f[CB]classfile\f[R]
درباره مسائل مربوط به محتوای فایل‌های کلاس (class file) هشدار می‌دهد.
.RS
.RE
.TP
.B \f[CB]deprecation\f[R]
درباره استفاده از موارد منسوخ‌شده (deprecated) هشدار می‌دهد.
برای مثال:
.RS
.IP
.nf
\f[CB]
java.util.Date\ myDate\ =\ new\ java.util.Date();
int\ currentDay\ =\ myDate.getDay();
\f[R]
.fi
.PP
متد \f[CB]java.util.Date.getDay\f[R] از زمان JDK 1.1 منسوخ شده است.
.RE
.TP
.B \f[CB]dep\-ann\f[R]
درباره مواردی هشدار می‌دهد که با کامنت Javadoc با عنوان \f[CB]\@deprecated\f[R] مستند شده‌اند، اما فاقد حاشیه‌نویسی (annotation) \f[CB]\@Deprecated\f[R] هستند، برای مثال:
.RS
.IP
.nf
\f[CB]
/**
\ \ *\ \@deprecated\ As\ of\ Java\ SE\ 7,\ replaced\ by\ {\@link\ #newMethod()}
\ \ */
public\ static\ void\ deprecatedMethod()\ {\ }
public\ static\ void\ newMethod()\ {\ }
\f[R]
.fi
.RE
.TP
.B \f[CB]divzero\f[R]
درباره تقسیم بر عدد صحیح ثابت 0 هشدار می‌دهد، برای مثال:
.RS
.RS
.PP
\f[CB]int\ divideByZero\ =\ 42\ /\ 0;\f[R]
.RE
.RE
.TP
.B \f[CB]empty\f[R]
درباره دستورهای خالی پس از عبارت‌های \f[CB]if\f[R] هشدار می‌دهد، برای مثال:
.RS
.IP
.nf
\f[CB]
class\ E\ {
\ \ \ \ void\ m()\ {
\ \ \ \ \ \ \ \ \ if\ (true)\ ;
\ \ \ \ }
}
\f[R]
.fi
.RE
.TP
.B \f[CB]fallthrough\f[R]
بلوک‌های switch را برای حالت‌های fall\-through بررسی کرده و برای هر موردی که یافت شود، یک پیام هشدار ارائه می‌دهد.
حالت‌های fall\-through مواردی در یک بلوک switch، به جز آخرین case در بلوک هستند که کد آن‌ها شامل دستور \f[CB]break\f[R] نیست، و باعث می‌شود اجرای کد از آن مورد به case بعدی سرازیر شود (fall through).
برای مثال، کد پس از برچسب case 1 در این بلوک switch با یک دستور \f[CB]break\f[R] پایان نمی‌یابد:
.RS
.IP
.nf
\f[CB]
switch\ (x)\ {
case\ 1:
\ \ System.out.println("1");
\ \ //\ No\ break\ statement\ here.
case\ 2:
\ \ System.out.println("2");
}
\f[R]
.fi
.PP
اگر هنگام کامپایل این کد از گزینه \f[CB]\-Xlint:fallthrough\f[R] استفاده شده باشد، کامپایلر هشداری درباره امکان fall\-through به case بعدی، همراه با شماره خط مورد بحث صادر می‌کند.
.RE
.TP
.B \f[CB]finally\f[R]
درباره بندهای \f[CB]finally\f[R] که نمی‌توانند به‌صورت عادی کامل شوند هشدار می‌دهد، برای مثال:
.RS
.IP
.nf
\f[CB]
public\ static\ int\ m()\ {
\ \ try\ {
\ \ \ \ \ throw\ new\ NullPointerException();
\ \ }\ \ catch\ (NullPointerException();\ {
\ \ \ \ \ System.err.println("Caught\ NullPointerException.");
\ \ \ \ \ return\ 1;
\ \ }\ finally\ {
\ \ \ \ \ return\ 0;
\ \ }
\ \ }
\f[R]
.fi
.PP
کامپایلر برای بلوک \f[CB]finally\f[R] در این مثال یک هشدار تولید می‌کند.
هنگامی که متد \f[CB]int\f[R] فراخوانی می‌شود، مقدار 0 را برمی‌گرداند.
یک بلوک \f[CB]finally\f[R] زمانی اجرا می‌شود که بلوک \f[CB]try\f[R] خارج شود.
در این مثال، هنگامی که کنترل به بلوک \f[CB]catch\f[R] منتقل می‌شود، متد \f[CB]int\f[R] خاتمه می‌یابد.
با این حال، بلوک \f[CB]finally\f[R] باید اجرا شود، بنابراین حتی با وجود اینکه کنترل به خارج از متد منتقل شده است، اجرا می‌گردد.
.RE
.TP
.B \f[CB]options\f[R]
درباره مسائل مربوط به استفاده از گزینه‌های خط فرمان هشدار می‌دهد.
بخش \f[B]Compiling for Earlier Releases of the Platform\f[R] را ببینید.
.RS
.RE
.TP
.B \f[CB]overrides\f[R]
درباره مسائل مربوط به رونویسی (override) متدها هشدار می‌دهد.
برای مثال، دو کلاس زیر را در نظر بگیرید:
.RS
.IP
.nf
\f[CB]
public\ class\ ClassWithVarargsMethod\ {
\ \ void\ varargsMethod(String...\ s)\ {\ }
}

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

\@SupportedAnnotationTypes("NotAnno")
public\ class\ AnnoProc\ extends\ AbstractProcessor\ {
\ \ public\ boolean\ process(Set<?\ extends\ TypeElement>\ elems,\ RoundEnvironment\ renv){
\ \ \ \ \ return\ true;
\ \ }

\ \ public\ SourceVersion\ getSupportedSourceVersion()\ {
\ \ \ \ \ return\ SourceVersion.latest();
\ \ \ }
}
\f[R]
.fi
.PP
\f[B]فایل مبدأ AnnosWithoutProcessors.java\f[R]:
.IP
.nf
\f[CB]
\@interface\ Anno\ {\ }

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

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

\ \ \ public\ Date\ getTime()\ {
\ \ \ \ \ return\ time;
\ \ \ }
}
\f[R]
.fi
.PP
کامپایلر هشدار زیر را صادر می‌کند:
.IP
.nf
\f[CB]
warning:\ [serial]\ serializable\ class\ PersistentTime\ has\ no\ definition\ of
serialVersionUID
\f[R]
.fi
.PP
اگر یک کلاس سریال‌پذیر به‌طور صریح فیلدی با نام \f[CB]serialVersionUID\f[R] اعلان نکند، محیط زمان اجرای سریال‌سازی مقدار پیش‌فرضی را بر اساس جنبه‌های مختلف کلاس (همان‌گونه که در Java Object Serialization Specification شرح داده شده است) برای \f[CB]serialVersionUID\f[R] آن کلاس محاسبه می‌کند.
با این حال، اکیداً توصیه می‌شود که همه کلاس‌های سریال‌پذیر به‌طور صریح مقادیر \f[CB]serialVersionUID\f[R] را اعلان کنند؛ زیرا فرایند پیش‌فرض محاسبه مقادیر \f[CB]serialVersionUID\f[R] به‌شدت به جزئیات کلاس وابسته است و ممکن است بسته به پیاده‌سازی‌های کامپایلر متفاوت باشد.
در نتیجه، این امر ممکن است منجر به بروز استثناهای غیرمنتظره \f[CB]InvalidClassExceptions\f[R] در طول فرایند سریال‌زدایی (deserialization) شود.
برای تضمین یک مقدار \f[CB]serialVersionUID\f[R] یکدست در میان پیاده‌سازی‌های مختلف کامپایلر جاوا، کلاس سریال‌پذیر باید صریحاً مقدار \f[CB]serialVersionUID\f[R] را اعلان کند.
.RE
.TP
.B \f[CB]static\f[R]
درباره مسائل مربوط به استفاده از متغیرهای ایستا (static) هشدار می‌دهد، برای مثال:
.RS
.IP
.nf
\f[CB]
class\ XLintStatic\ {
\ \ \ \ static\ void\ m1()\ {\ }
\ \ \ \ void\ m2()\ {\ this.m1();\ }
}
\f[R]
.fi
.PP
کامپایلر هشدار زیر را صادر می‌کند:
.IP
.nf
\f[CB]
warning:\ [static]\ static\ method\ should\ be\ qualified\ by\ type\ name,
XLintStatic,\ instead\ of\ by\ an\ expression
\f[R]
.fi
.PP
برای برطرف کردن این مورد، می‌توانید متد \f[CB]static\f[R] با نام \f[CB]m1\f[R] را به این شکل فراخوانی کنید:
.RS
.PP
\f[CB]XLintStatic.m1();\f[R]
.RE
.PP
همچنین، می‌توانید کلمه کلیدی \f[CB]static\f[R] را از اعلان متد \f[CB]m1\f[R] حذف کنید.
.RE
.TP
.B \f[CB]try\f[R]
درباره مسائل مربوط به استفاده از بلوک‌های \f[CB]try\f[R]، شامل دستورهای try\-with\-resources هشدار می‌دهد.
برای مثال، برای عبارت زیر یک هشدار تولید می‌شود زیرا منبع \f[CB]ac\f[R] اعلان‌شده در بلوک \f[CB]try\f[R] استفاده نشده است:
.RS
.IP
.nf
\f[CB]
try\ (\ AutoCloseable\ ac\ =\ getResource()\ )\ {\ \ \ \ //\ do\ nothing}
\f[R]
.fi
.RE.TP
.B \f[CB]unchecked\f[R]
جزئیات بیشتری دربارهٔ هشدارهای تبدیل بررسی‌نشده (unchecked conversion) که توسط Java Language Specification الزامی شده‌اند ارائه می‌دهد؛ برای مثال:
.RS
.IP
.nf
\f[CB]
List\ l\ =\ new\ ArrayList<Number>();
List<String>\ ls\ =\ l;\ \ \ \ \ \ \ //\ unchecked\ warning
\f[R]
.fi
.PP
در طول پاک‌سازی نوع (type erasure)، انواع \f[CB]ArrayList<Number>\f[R] و
\f[CB]List<String>\f[R] به‌ترتیب تبدیل به \f[CB]ArrayList\f[R] و \f[CB]List\f[R]
می‌شوند.
.PP
دستور \f[CB]ls\f[R] دارای نوع پارامتری‌شدهٔ
\f[CB]List<String>\f[R] است.
هنگامی که \f[CB]List\f[R] ارجاع‌داده‌شده توسط \f[CB]l\f[R] به
\f[CB]ls\f[R] انتساب می‌یابد، کامپایلر یک هشدار unchecked ایجاد می‌کند.
در زمان کامپایل، کامپایلر و JVM نمی‌توانند تعیین کنند که آیا
\f[CB]l\f[R] به یک نوع \f[CB]List<String>\f[R] ارجاع دارد یا خیر.
در این حالت، \f[CB]l\f[R] به نوع \f[CB]List<String>\f[R] ارجاع ندارد.
در نتیجه، آلودگی هیپ (heap pollution) رخ می‌دهد.
.PP
وضعیت آلودگی هیپ زمانی رخ می‌دهد که شیء \f[CB]List\f[R] یعنی
\f[CB]l\f[R]، که نوع ایستای آن \f[CB]List<Number>\f[R] است، به
شیء \f[CB]List\f[R] دیگری یعنی \f[CB]ls\f[R] که نوع ایستای متفاوتی
(\f[CB]List<String>\f[R]) دارد، انتساب یابد.
با این حال، کامپایلر همچنان این انتساب را مجاز می‌داند.
کامپایلر باید این انتساب را مجاز بداند تا سازگاری رو به عقب (backward compatibility) با
نسخه‌هایی از Java SE که از generics پشتیبانی نمی‌کنند حفظ شود.
به دلیل پاک‌سازی نوع (type erasure)، هر دو نوع \f[CB]List<Number>\f[R] و \f[CB]List<String>\f[R]
تبدیل به \f[CB]List\f[R] می‌شوند.
در نتیجه، کامپایلر انتساب شیء \f[CB]l\f[R] را، که دارای نوع خام (raw type) از
\f[CB]List\f[R] است، به شیء \f[CB]ls\f[R] مجاز می‌داند.
.RE
.TP
.B \f[CB]varargs\f[R]
دربارهٔ استفادهٔ ناامن از متدهای دارای آرگومان‌های متغیر (\f[CB]varargs\f[R])،
به‌ویژه مواردی که حاوی آرگومان‌های تحقق‌ناپذیر (non\-reifiable) هستند، هشدار می‌دهد؛ برای مثال:
.RS
.IP
.nf
\f[CB]
public\ class\ ArrayBuilder\ {
\ \ public\ static\ <T>\ void\ addToList\ (List<T>\ listArg,\ T...\ elements)\ {
\ \ \ \ for\ (T\ x\ :\ elements)\ {
\ \ \ \ \ \ listArg.add(x);
\ \ \ \ }
\ \ }
}
\f[R]
.fi
.PP
یک نوع تحقق‌ناپذیر (non\-reifiable) نوعی است که اطلاعات نوع آن در زمان اجرا به‌طور کامل
در دسترس نیست.
.PP
کامپایلر برای تعریف متد \f[CB]ArrayBuilder.addToList\f[R]
هشدار زیر را صادر می‌کند:
.IP
.nf
\f[CB]
warning:\ [varargs]\ Possible\ heap\ pollution\ from\ parameterized\ vararg\ type\ T
\f[R]
.fi
.PP
هنگامی که کامپایلر با یک متد varargs مواجه می‌شود، پارامتر صوری
\f[CB]varargs\f[R] را به یک آرایه تبدیل می‌کند.
با این حال، زبان برنامه‌نویسی جاوا ایجاد آرایه‌هایی از انواع پارامتری‌شده را
مجاز نمی‌داند.
در متد \f[CB]ArrayBuilder.addToList\f[R]، کامپایلر پارامتر صوری
\f[CB]varargs\f[R] با عنوان \f[CB]T...\f[R] elements را به پارامتر صوری
\f[CB]T[]\f[R] elements که یک آرایه است، تبدیل می‌کند.
با این وجود، به دلیل پاک‌سازی نوع (type erasure)، کامپایلر پارامتر صوری
\f[CB]varargs\f[R] را به \f[CB]Object[]\f[R] elements تبدیل می‌کند.
در نتیجه، احتمال وقوع آلودگی هیپ (heap pollution) وجود دارد.
.RE