.\" Copyright (c) 1994, 2023, 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.19.2 .\" .\" Define V font for inline verbatim, using C font in formats .\" that render this, and otherwise B font. .ie "\f[CB]x\f[R]"x" \{\ . ftr V B . ftr VI BI . ftr VB B . ftr VBI BI .\} .el \{\ . ftr V CR . ftr VI CI . ftr VB CB . ftr VBI CBI .\} .TH "JAVAC" "1" "2023" "JDK 21" "JDK Commands" .hy .SH "نام (NAME)" .PP javac \- خواندن اعلان‌های جاوا و کامپایل آن‌ها به فایل‌های کلاس .SH "خلاصه دستور (SYNOPSIS)" .PP \f[V]javac\f[R] [\f[I]options\f[R]] [\f[I]sourcefiles-or-classnames\f[R]] .TP \f[I]options\f[R] گزینه‌های خط فرمان. .TP \f[I]sourcefiles-or-classnames\f[R] فایل‌های مبدأ برای کامپایل (برای نمونه، \f[V]Shape.java\f[R]) یا نام کلاس‌های قبلاً کامپایل‌شده جهت پردازش حاشیه‌نویسی‌ها (برای نمونه، \f[V]geometry.MyShape\f[R]). .SH "توضیحات (DESCRIPTION)" .PP دستور \f[V]javac\f[R] \f[I]فایل‌های مبدأ\f[R] حاوی اعلان‌های ماژول، پکیج و نوعِ نوشته‌شده به زبان برنامه‌نویسی Java را می‌خواند و آن‌ها را به \f[I]فایل‌های کلاس\f[R] کامپایل می‌کند تا روی ماشین مجازی جاوا (JVM) اجرا شوند. .PP دستور \f[V]javac\f[R] همچنین می‌تواند \f[B]حاشیه‌نویسی‌ها (annotations) را در فایل‌های مبدأ و کلاس‌های جاوا پردازش کند\f[R]. .PP فایل‌های مبدأ باید پسوند نام فایل \f[V].java\f[R] داشته باشند. فایل‌های کلاس پسوند نام فایل \f[V].class\f[R] دارند. معمولاً هر دو فایل‌های مبدأ و کلاس دارای نام‌هایی هستند که محتوای آن‌ها را مشخص می‌سازد. برای نمونه، کلاسی به نام \f[V]Shape\f[R] در فایل مبدأیی به نام \f[V]Shape.java\f[R] اعلان می‌شود و در یک فایل کلاس به نام \f[V]Shape.class\f[R] کامپایل خواهد شد. .PP دو روش برای مشخص کردن فایل‌های مبدأ به \f[V]javac\f[R] وجود دارد: .IP \[bu] 2 برای تعداد کمی از فایل‌های مبدأ، می‌توانید نام آن‌ها را در خط فرمان درج کنید. .IP \[bu] 2 برای تعداد زیادی از فایل‌های مبدأ، می‌توانید از گزینهٔ \f[B]\f[VB]\[at]\f[B]\f[BI]filename\f[B]\f[R] در خط فرمان برای تعیین یک \f[I]فایل آرگومان\f[R] استفاده کنید که نام آن فایل‌ها در آن فهرست شده است. برای شرح این گزینه به بخش \f[B]گزینه‌های استاندارد (Standard Options)\f[R] و برای شرح فایل‌های آرگومان \f[V]javac\f[R] به \f[B]فایل‌های آرگومان خط فرمان (Command-Line Argument Files)\f[R] مراجعه نمایید. .PP ترتیب فایل‌های مبدأ مشخص‌شده در خط فرمان یا در یک فایل آرگومان اهمیتی ندارد. \f[V]javac\f[R] فایل‌ها را با هم و به صورت گروهی کامپایل می‌کند و وابستگی‌های میان اعلان‌ها در فایل‌های مبدأ گوناگون را به‌طور خودکار برطرف می‌سازد. .PP \f[V]javac\f[R] انتظار دارد که فایل‌های مبدأ در یک یا چند ساختار سلسله‌مراتبی دایرکتوری در سیستم فایل چیده شده باشند، همان‌گونه که در \f[B]چیدمان کد مبدأ (Arrangement of Source Code)\f[R] شرح داده شده است. .PP برای کامپایل یک فایل مبدأ، \f[V]javac\f[R] باید اعلان هر کلاس یا رابطی (اینترفیسی) را که توسط کد موجود در فایل مبدأ استفاده شده، گسترش یافته (extended) یا پیاده‌سازی شده (implemented) است پیدا کند. این کار به \f[V]javac\f[R] امکان می‌دهد بررسی کند که آیا کد، حق دسترسی به آن کلاس‌ها و رابط‌ها را دارد یا خیر. به جای مشخص کردن مستقیم فایل‌های مبدأ آن کلاس‌ها و رابط‌ها، می‌توانید از گزینه‌های خط فرمان استفاده کنید تا به \f[V]javac\f[R] اعلام کنید کجا به دنبال فایل‌های مبدأ آن‌ها بگردد. اگر آن فایل‌های مبدأ را قبلاً کامپایل کرده‌اید، می‌توانید از گزینه‌ها استفاده کنید تا به \f[V]javac\f[R] بگویید کجا به دنبال فایل‌های کلاس متناظر جستجو کند. این گزینه‌ها که همگی نام‌هایی ختم‌شده به \[dq]path\[dq] دارند، در بخش \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[V]javac\f[R] هر فایل مبدأ را به یک فایل کلاس در همان دایرکتوری فایل مبدأ کامپایل می‌کند. با این حال، توصیه می‌شود یک دایرکتوری مقصد مجزا با استفاده از گزینهٔ \f[B]\f[VB]-d\f[B]\f[R] تعیین شود. .PP \f[B]گزینه‌ها\f[R] و \f[B]متغیرهای محیطی\f[R] خط فرمان نیز نحوهٔ انجام وظایف گوناگون توسط \f[V]javac\f[R] را کنترل می‌کنند: .IP \[bu] 2 کامپایل کد جهت اجرا روی نگارش‌های پیشین JDK. .IP \[bu] 2 کامپایل کد جهت اجرا تحت یک دیباگر. .IP \[bu] 2 بررسی ایرادات سبکی و نگارشی در کد مبدأ جاوا. .IP \[bu] 2 بررسی اشکالات موجود در یادداشت‌های \f[V]javadoc\f[R] (\f[V]/** ... */\f[R]). .IP \[bu] 2 پردازش حاشیه‌نویسی‌ها در فایل‌های مبدأ و فایل‌های کلاس. .IP \[bu] 2 ارتقا و وصله کردن ماژول‌ها در محیط زمان کامپایل. .PP دستور \f[V]javac\f[R] از \f[B]کامپایل برای نگارش‌های قبلی پلتفرم (Compiling for Earlier Releases Of The Platform)\f[R] پشتیبانی می‌کند و همچنین می‌تواند از داخل کد جاوا با بهره‌گیری از شماری از \f[B]APIها\f[R] فراخوانی شود..SH "گزینه‌ها (OPTIONS)" .PP دستور \f[V]javac\f[R] \f[B]گزینه‌های استاندارد\f[R] و همچنین \f[B]گزینه‌های اضافی\f[R] را که غیراستاندارد بوده یا برای استفاده پیشرفته هستند، ارائه می‌دهد. .PP برخی گزینه‌ها یک یا چند آرگومان دریافت می‌کنند. اگر یک آرگومان حاوی فاصله یا دیگر نویسه‌های فاصله‌ساز باشد، مقدار آن باید مطابق با قواعد محیطی که برای فراخوانی javac به کار می‌رود، درون علامت نقل‌قول قرار گیرد. اگر گزینه با یک خط تیره منفرد (\f[V]-\f[R]) آغاز شود، آرگومان باید بسته به نوع گزینه، یا بلافاصله پس از نام گزینه بیاید، یا با یک دونقطه (\f[V]:\f[R]) یا فاصله سفید جدا شود. اگر گزینه با دو خط تیره (\f[V]--\f[R]) آغاز شود، آرگومان می‌تواند با فاصله سفید یا با نویسه مساوی (\f[V]=\f[R]) بدون هیچ‌گونه فاصله سفید اضافی جدا شود. برای مثال، .IP .nf \f[CB] -Aname=\[dq]J. Duke\[dq] -proc:only -d myDirectory --module-version 3 --module-version=3 \f[R] .fi .PP در فهرست‌های گزینه‌های زیر، آرگومان \f[I]path\f[R] نشان‌دهنده یک مسیر جست‌وجو است که از فهرستی از مکان‌های سیستم‌فایل تشکیل شده و با نویسه جداکننده مسیر پلتفرم (نقطه‌ویرگول \f[V];\f[R] در Windows، یا دونقطه \f[V]:\f[R] در سایر سیستم‌ها) از هم جدا می‌شوند. بسته به گزینه، مکان‌های سیستم‌فایل می‌توانند دایرکتوری‌ها، فایل‌های JAR یا فایل‌های JMOD باشند. .SS "گزینه‌های استاندارد (Standard Options)" .TP \f[V]\[at]\f[R]\f[I]filename\f[R] گزینه‌ها و نام‌های فایل را از یک فایل می‌خواند. برای کوتاه‌تر کردن یا ساده‌سازی دستور \f[V]javac\f[R]، می‌توانید یک یا چند فایل حاوی آرگومان‌های دستور \f[V]javac\f[R] (به‌جز گزینه‌های \f[B]\f[VB]-J\f[B]\f[R]) را مشخص کنید. این کار به شما امکان می‌دهد دستورهای \f[V]javac\f[R] با هر طولی را روی هر سیستم‌عاملی ایجاد کنید. بخش \f[B]Command-Line Argument Files\f[R] را ببینید. .TP \f[V]-A\f[R]\f[I]key\f[R][\f[V]=\f[R]\f[I]value\f[R]] گزینه‌هایی را برای ارسال به پردازنده‌های حاشیه‌نویسی (annotation processors) مشخص می‌کند. این گزینه‌ها مستقیماً توسط \f[V]javac\f[R] تفسیر نمی‌شوند، بلکه در دسترس پردازنده‌ها قرار می‌گیرند. مقدار \f[I]key\f[R] باید یک یا چند شناسه باشد که با نقطه (\f[V].\f[R]) از هم جدا شده‌اند. .TP \f[V]--add-modules\f[R] \f[I]module\f[R]\f[V],\f[R]\f[I]module\f[R] ماژول‌های ریشه را علاوه بر ماژول‌های اولیه برای تفکیک (resolve) مشخص می‌کند، یا در صورتی که \f[I]module\f[R] برابر با \f[V]ALL-MODULE-PATH\f[R] باشد، تمام ماژول‌های موجود در مسیر ماژول را تعیین می‌کند. .TP \f[V]--boot-class-path\f[R] \f[I]path\f[R] یا \f[V]-bootclasspath\f[R] \f[I]path\f[R] مکان فایل‌های کلاس راه‌اندازی (bootstrap class files) را جایگزین می‌کند. .RS .PP \f[B]نکته:\f[R] این گزینه تنها هنگام کامپایل برای نسخه‌های پیش از JDK 9 قابل استفاده است. در صورت لزوم، برای جزئیات به توضیحات موجود در \f[B]\f[VB]--release\f[B]\f[R]، \f[B]\f[VB]-source\f[B]\f[R] یا \f[B]\f[VB]-target\f[B]\f[R] مراجعه کنید. برای JDK 9 یا جدیدتر، به \f[B]\f[VB]--system\f[B]\f[R] مراجعه کنید. .RE .TP \f[V]--class-path\f[R] \f[I]path\f[R]، \f[V]-classpath\f[R] \f[I]path\f[R]، یا \f[V]-cp\f[R] \f[I]path\f[R] مکان یافتن فایل‌های کلاس کاربری و پردازنده‌های حاشیه‌نویسی را مشخص می‌کند. این مسیر کلاس، مقدار مسیر کلاس کاربر را در متغیر محیطی \f[V]CLASSPATH\f[R] بازنویسی و لغو می‌کند. .RS .IP \[bu] 2 اگر \f[V]--class-path\f[R]، \f[V]-classpath\f[R] یا \f[V]-cp\f[R] مشخص نشده باشند، مسیر کلاس کاربر برابر با مقدار متغیر محیطی \f[V]CLASSPATH\f[R] (در صورت مقداردهی) یا دایرکتوری جاری خواهد بود. .IP \[bu] 2 در صورت عدم کامپایل کد برای ماژول‌ها، اگر گزینه \f[B]\f[VB]--source-path\f[B]\f[R] یا -sourcepath\[ga] مشخص نشده باشد، مسیر کلاس کاربر برای فایل‌های مبدأ نیز جست‌وجو می‌شود. .IP \[bu] 2 اگر گزینه \f[B]\f[VB]-processorpath\f[B]\f[R] مشخص نشده باشد، مسیر کلاس برای پردازنده‌های حاشیه‌نویسی نیز جست‌وجو می‌شود. .RE .TP \f[V]-d\f[R] \f[I]directory\f[R] دایرکتوری مقصد (یا \f[I]دایرکتوری خروجی کلاس\f[R]) را برای فایل‌های کلاس تعیین می‌کند. اگر کلاسی بخشی از یک بسته باشد، \f[V]javac\f[R] فایل کلاس را در زیردایرکتوری‌ای قرار می‌دهد که منعکس‌کننده نام ماژول (در صورت کاربرد) و نام بسته است. دایرکتوری و زیردایرکتوری‌های لازم در صورت عدم وجود، ایجاد خواهند شد. .RS .PP اگر گزینه \f[V]-d\f[R] مشخص نشده باشد، \f[V]javac\f[R] هر فایل کلاس را در همان دایرکتوری فایل مبدأ سازنده آن قرار می‌دهد. .PP به‌جز هنگام کامپایل کد برای چندین ماژول، محتویات دایرکتوری خروجی کلاس بر اساس سلسله‌مراتب بسته‌ها سازمان‌دهی خواهد شد. هنگام کامپایل کد برای چندین ماژول، محتویات دایرکتوری خروجی در یک سلسله‌مراتب ماژول سازمان‌دهی می‌شود، به‌طوری که محتویات هر ماژول در یک زیردایرکتوری جداگانه و بر اساس سلسله‌مراتب بسته مربوط به خود مرتب می‌شود. .PP \f[B]نکته:\f[R] هنگام کامپایل کد برای یک یا چند ماژول، دایرکتوری خروجی کلاس به‌طور خودکار هنگام جست‌وجو برای کلاس‌های از پیش کامپایل‌شده بررسی می‌شود. هنگامی که کامپایل برای ماژول‌ها انجام نمی‌شود، برای حفظ سازگاری با گذشته، دایرکتوری به‌طور خودکار برای کلاس‌های کامپایل‌شده پیشین بررسی \f[I]نمی‌شود\f[R]؛ بنابراین توصیه می‌شود دایرکتوری خروجی کلاس را با استفاده از گزینه \f[V]--class-path\f[R] یا یکی از شکل‌های جایگزین آن، به‌عنوان یکی از مکان‌های موجود در مسیر کلاس کاربر مشخص کنید. .RE .TP \f[V]-deprecation\f[R] توضیحاتی از هر مورد استفاده یا بازنویسی (override) یک عضو یا کلاس منسوخ‌شده را نمایش می‌دهد. بدون گزینه \f[V]-deprecation\f[R]، دستور \f[V]javac\f[R] خلاصه‌ای از فایل‌های مبدأ را که از اعضا یا کلاس‌های منسوخ‌شده استفاده کرده یا آنها را بازنویسی نموده‌اند نشان می‌دهد. گزینه \f[V]-deprecation\f[R] مخفف \f[V]-Xlint:deprecation\f[R] است. .TP \f[V]--enable-preview\f[R] ویژگی‌های پیش‌نمایش زبان را فعال می‌کند. به‌همراه یکی از گزینه‌های \f[B]\f[VB]-source\f[B]\f[R] یا \f[B]\f[VB]--release\f[B]\f[R] به کار می‌رود. .TP \f[V]-encoding\f[R] \f[I]encoding\f[R] کدگذاری نویسه مورد استفاده در فایل‌های مبدأ مانند EUC-JP و UTF-8 را مشخص می‌کند. اگر گزینه \f[V]-encoding\f[R] مشخص نشده باشد، از مبدل پیش‌فرض پلتفرم استفاده می‌شود. .TP \f[V]-endorseddirs\f[R] \f[I]directories\f[R] مکان مسیر استانداردهای تأییدشده (endorsed standards path) را جایگزین می‌کند. .RS .PP \f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نسخه‌های پیش از JDK 9 قابل استفاده است. در صورت لزوم، برای جزئیات به توضیحات \f[B]\f[VB]--release\f[B]\f[R]، \f[B]\f[VB]-source\f[B]\f[R] یا \f[B]\f[VB]-target\f[B]\f[R] مراجعه کنید. .RE .TP \f[V]-extdirs\f[R] \f[I]directories\f[R] مکان افزونه‌های نصب‌شده را جایگزین می‌کند. \f[V]directories\f[R] فهرستی از دایرکتوری‌ها است که با جداکننده مسیر پلتفرم (نقطه‌ویرگول \f[V];\f[R] در Windows، و دونقطه \f[V]:\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[VB]--release\f[B]\f[R]، \f[B]\f[VB]-source\f[B]\f[R] یا \f[B]\f[VB]-target\f[B]\f[R] مراجعه کنید. .RE .TP \f[V]-g\f[R] تمام اطلاعات اشکال‌زدایی، از جمله متغیرهای محلی را تولید می‌کند. به‌طور پیش‌فرض، فقط اطلاعات شماره خط و فایل مبدأ تولید می‌شود. .TP \f[V]-g:\f[R][\f[V]lines\f[R], \f[V]vars\f[R], \f[V]source\f[R]] تنها انواع اطلاعات اشکال‌زدایی مشخص‌شده توسط فهرست کلیدواژه‌های جداشده با کاما را تولید می‌کند. کلیدواژه‌های معتبر عبارتند از: .RS .TP \f[V]lines\f[R] اطلاعات اشکال‌زدایی شماره خط..TP \f[V]vars\f[R] اطلاعات اشکال‌زدایی متغیرهای محلی. .TP \f[V]source\f[R] اطلاعات اشکال‌زدایی پروندهٔ منبع. .RE .TP \f[V]-g:none\f[R] اطلاعات اشکال‌زدایی را تولید نمی‌کند. .TP \f[V]-h\f[R] \f[I]directory\f[R] محل قرارگیری پرونده‌های سرآیند بومی (native header) تولیدشده را مشخص می‌کند. .RS .PP هنگامی که این گزینه را مشخص می‌کنید، برای هر کلاسی که شامل متدهای بومی است یا دارای یک یا چند ثابت است که با حاشیه‌نویسی \f[B]\f[VB]java.lang.annotation.Native\f[B]\f[R] نشانه‌گذاری شده‌اند، یک پروندهٔ سرآیند بومی تولید می‌شود. اگر کلاس بخشی از یک بسته باشد، کامپایلر پروندهٔ سرآیند بومی را در یک زیرپوشه متناسب با نام پودمان (در صورت لزوم) و نام بسته قرار می‌دهد. اگر پوشه و زیرپوشه‌های لازم از پیش موجود نباشند، ایجاد خواهند شد. .RE .TP \f[V]--help\f[R]، \f[V]-help\f[R] یا \f[V]-?\f[R] خلاصه‌ای از گزینه‌های استاندارد را چاپ می‌کند. .TP \f[V]--help-extra\f[R] یا \f[V]-X\f[R] خلاصه‌ای از مجموعه گزینه‌های اضافی را چاپ می‌کند. .TP \f[V]--help-lint\f[R] کلیدهای پشتیبانی‌شده برای گزینهٔ \f[V]-Xlint\f[R] را چاپ می‌کند. .TP \f[V]-implicit:\f[R][\f[V]none\f[R], \f[V]class\f[R]] مشخص می‌کند که آیا برای پرونده‌های دارای ارجاع ضمنی، پرونده‌های کلاس تولید شوند یا خیر: .RS .IP \[bu] 2 \f[V]-implicit:class\f[R] --- به‌طور خودکار پرونده‌های کلاس را تولید می‌کند. .IP \[bu] 2 \f[V]-implicit:none\f[R] --- از تولید پرونده‌های کلاس جلوگیری می‌کند. .PP اگر این گزینه مشخص نشود، رفتار پیش‌فرض تولید خودکار پرونده‌های کلاس است. در این حالت، در صورت تولید هرگونه پروندهٔ کلاس در حین پردازش حاشیه‌نویسی، کامپایلر یک هشدار صادر می‌کند. هنگامی که گزینهٔ \f[V]-implicit\f[R] به‌طور صریح تنظیم شده باشد، این هشدار صادر نمی‌شود. بخش \f[B]Searching for Module, Package and Type Declarations\f[R] را ببینید. .RE .TP \f[V]-J\f[R]\f[I]option\f[R] گزینهٔ \f[I]option\f[R] را به سیستم زمان‌اجرا ارسال می‌کند، که در آن \f[I]option\f[R] یکی از گزینه‌های جاوای شرح‌داده‌شده در دستور \f[B]java\f[R] است. برای نمونه، \f[V]-J-Xms48m\f[R] مقدار حافظهٔ راه‌اندازی را روی ۴۸ مگابایت تنظیم می‌کند. .RS .PP \f[B]نکته:\f[R] متغیر محیطی \f[V]CLASSPATH\f[R]، گزینهٔ \f[V]-classpath\f[R]، گزینهٔ \f[V]-bootclasspath\f[R] و گزینهٔ \f[V]-extdirs\f[R] کلاس‌های مورد استفاده برای اجرای \f[V]javac\f[R] را مشخص نمی‌کنند. تلاش برای سفارشی‌سازی پیاده‌سازی کامپایلر با این گزینه‌ها و متغیرها پرخطر است و اغلب به نتیجهٔ مورد نظر شما منجر نمی‌شود. اگر حتماً باید پیاده‌سازی کامپایلر را سفارشی کنید، از گزینهٔ \f[V]-J\f[R] برای ارسال گزینه‌ها به راه‌انداز زیرین جاوا استفاده کنید. .RE .TP \f[V]--limit-modules\f[R] \f[I]module\f[R]\f[V],\f[R]\f[I]module\f[R]* محدودهٔ پودمان‌های قابل‌مشاهده را محدود می‌کند. .TP \f[V]--module\f[R] \f[I]module-name\f[R] (\f[V],\f[R]\f[I]module-name\f[R])* یا \f[V]-m\f[R] \f[I]module-name\f[R] (\f[V],\f[R]\f[I]module-name\f[R])* آن دسته از پرونده‌های منبع در پودمان‌های نام‌برده را که جدیدتر از پرونده‌های متناظر در پوشهٔ خروجی هستند، کامپایل می‌کند. .TP \f[V]--module-path\f[R] \f[I]path\f[R] یا \f[V]-p\f[R] \f[I]path\f[R] محل یافتن پودمان‌های برنامه کاربردی را مشخص می‌کند. .TP \f[V]--module-source-path\f[R] \f[I]module-source-path\f[R] محل یافتن پرونده‌های منبع را هنگام کامپایل کد در چند پودمان مشخص می‌کند. بخش‌های [Compilation Modes] و \f[B]The Module Source Path Option\f[R] را ببینید. .TP \f[V]--module-version\f[R] \f[I]version\f[R] نسخهٔ پودمان‌های در حال کامپایل را مشخص می‌کند. .TP \f[V]-nowarn\f[R] پیام‌های هشدار را غیرفعال می‌کند. عملکرد این گزینه مشابه گزینهٔ \f[V]-Xlint:none\f[R] است. .TP \f[V]-parameters\f[R] فرادهاده را برای بازتاب (reflection) روی پارامترهای متد تولید می‌کند. نام‌های صوری پارامترهای سازنده‌ها و متدها را در پروندهٔ کلاسِ تولیدشده ذخیره می‌کند تا متد \f[V]java.lang.reflect.Executable.getParameters\f[R] از API بازتاب بتواند آنها را بازیابی کند. .TP \f[V]-proc:\f[R][\f[V]none\f[R], \f[V]only\f[R], \f[V]full\f[R]] انجام پردازش حاشیه‌نویسی و کامپایل را کنترل می‌کند. مقدار \f[V]-proc:none\f[R] به این معنی است که کامپایل بدون پردازش حاشیه‌نویسی انجام می‌شود. مقدار \f[V]-proc:only\f[R] به این معنی است که تنها پردازش حاشیه‌نویسی انجام می‌شود، بدون اینکه کامپایل بعدی صورت گیرد. اگر از این گزینه استفاده نشود، یا \f[V]-proc:full\f[R] مشخص شده باشد، پردازش حاشیه‌نویسی و کامپایل هر دو انجام می‌شوند. .TP \f[V]-processor\f[R] \f[I]class1\f[R][\f[V],\f[R]\f[I]class2\f[R]\f[V],\f[R]\f[I]class3\f[R]...] نام‌های پردازنده‌های حاشیه‌نویسی برای اجرا. این کار فرایند پیش‌فرض اکتشاف (discovery) را دور می‌زند. .TP \f[V]--processor-module-path\f[R] \f[I]path\f[R] مسیر پودمانی مورد استفاده برای یافتن پردازنده‌های حاشیه‌نویسی را مشخص می‌کند. .TP \f[V]--processor-path\f[R] \f[I]path\f[R] یا \f[V]-processorpath\f[R] \f[I]path\f[R] محل یافتن پردازنده‌های حاشیه‌نویسی را مشخص می‌کند. اگر از این گزینه استفاده نشود، مسیر کلاس (class path) برای یافتن پردازنده‌ها جستجو می‌شود. .TP \f[V]-profile\f[R] \f[I]profile\f[R] بررسی می‌کند که آیا API استفاده‌شده در نمایهٔ (profile) مشخص‌شده موجود است یا خیر. این گزینه منسوخ شده است و ممکن است در نگارش‌های آینده حذف شود. .RS .PP \f[B]نکته:\f[R] این گزینه تنها هنگام کامپایل برای نگارش‌های پیش از JDK 9 قابل استفاده است. در صورت نیاز، برای جزئیات به توضیحات گزینه‌های \f[B]\f[VB]--release\f[B]\f[R]، \f[B]\f[VB]-source\f[B]\f[R] یا \f[B]\f[VB]-target\f[B]\f[R] مراجعه کنید. .RE .TP \f[V]--release\f[R] \f[I]release\f[R] کد منبع را مطابق با قواعد زبان برنامه‌نویسی جاوا برای نگارش مشخص‌شدهٔ Java SE کامپایل می‌کند و پرونده‌های کلاسی را تولید می‌کند که آن نگارش را هدف قرار می‌دهند. کد منبع در برابر API ترکیب‌شدهٔ Java SE و JDK برای نگارش مشخص‌شده کامپایل می‌شود. .RS .PP مقدارهای پشتیبانی‌شده برای \f[I]release\f[R] شامل نگارش کنونی Java SE و تعداد محدودی از نگارش‌های پیشین است که جزئیات آن در راهنمای خط فرمان آمده است. .PP برای نگارش کنونی، Java SE API شامل بسته‌های \f[V]java.*\f[R]، \f[V]javax.*\f[R] و \f[V]org.*\f[R] است که توسط پودمان‌های Java SE در آن نگارش صادر (export) شده‌اند؛ JDK API شامل بسته‌های \f[V]com.*\f[R] و \f[V]jdk.*\f[R] است که توسط پودمان‌های JDK در آن نگارش صادر شده‌اند، به همراه بسته‌های \f[V]javax.*\f[R] که توسط پودمان‌های استاندارد (اما غیر Java SE) در آن نگارش صادر شده‌اند. .PP برای نگارش‌های پیشین، Java SE API و JDK API همان‌گونه هستند که در آن نگارش تعریف شده‌اند. .PP \f[B]نکته:\f[R] هنگام استفاده از \f[V]--release\f[R]، نمی‌توانید هم‌زمان از گزینه‌های \f[B]\f[VB]--source\f[B]\f[R]/\f[V]-source\f[R] یا \f[B]\f[VB]--target\f[B]\f[R]/\f[V]-target\f[R] استفاده کنید. .PP \f[B]نکته:\f[R] هنگام استفاده از \f[V]--release\f[R] برای مشخص‌کردن نگارشی که از سامانهٔ پودمان پلتفرم جاوا (Java Platform Module System) پشتیبانی می‌کند، گزینهٔ \f[V]--add-exports\f[R] نمی‌تواند برای گسترش مجموعه بسته‌های صادرشده توسط پودمان‌های Java SE، JDK و پودمان‌های استاندارد در نگارش مشخص‌شده استفاده شود. .RE .TP \f[V]-s\f[R] \f[I]directory\f[R] پوشهٔ مورد استفاده برای قرار دادن پرونده‌های منبع تولیدشده را مشخص می‌کند. اگر کلاسی بخشی از یک بسته باشد، کامپایلر پروندهٔ منبع را در یک زیرپوشه متناسب با نام پودمان (در صورت لزوم) و نام بسته قرار می‌دهد. اگر پوشه و هرگونه زیرپوشهٔ لازم از پیش موجود نباشند، ایجاد خواهند شد. .RS .PP به جز در هنگام کامپایل کد برای چند پودمان، محتویات پوشهٔ خروجی منبع در یک سلسله‌مراتب بسته‌ای سازماندهی خواهند شد. هنگام کامپایل کد برای چند پودمان، محتویات پوشهٔ خروجی منبع در یک سلسله‌مراتب پودمانی سازماندهی خواهند شد، به‌طوری که محتویات هر پودمان در یک زیرپوشهٔ جداگانه قرار گرفته و هر یک به صورت یک سلسله‌مراتب بسته‌ای سازماندهی می‌شوند. .RE.TP \f[V]--source\f[R] \f[I]release\f[R] یا \f[V]-source\f[R] \f[I]release\f[R] کد منبع را بر اساس قوانین زبان برنامه‌نویسی Java برای نگارش (release) مشخص‌شدهٔ Java SE کامپایل می‌کند. مقادیر پشتیبانی‌شده برای \f[I]release\f[R] نگارش فعلی Java SE و تعداد محدودی از نگارش‌های پیشین هستند که جزئیات آن‌ها در راهنمای خط فرمان آمده است. .RS .PP اگر این گزینه مشخص نشود، مقدار پیش‌فرض کامپایل کردن کد منبع بر اساس قوانین زبان برنامه‌نویسی Java برای نگارش فعلی Java SE است. .RE .TP \f[V]--source-path\f[R] \f[I]path\f[R] یا \f[V]-sourcepath\f[R] \f[I]path\f[R] محل یافتن فایل‌های منبع را مشخص می‌کند. به جز در زمان کامپایل چندین ماژول با یکدیگر، این مسیر کد منبع است که برای جستجوی تعاریف کلاس یا واسط (interface) استفاده می‌شود. .RS .PP \f[B]نکته:\f[R] کلاس‌های یافت‌شده از طریق مسیر کلاس (class path) ممکن است در صورت پیدا شدن فایل‌های منبع آن‌ها، مجدداً کامپایل شوند. بخش \f[B]Searching for Module, Package and Type Declarations\f[R] را ببینید. .RE .TP \f[V]--system\f[R] \f[I]jdk\f[R] | \f[V]none\f[R] مکان ماژول‌های سیستمی را جایگزین می‌کند. .TP \f[V]--target\f[R] \f[I]release\f[R] یا \f[V]-target\f[R] \f[I]release\f[R] فایل‌های \f[V]class\f[R] مناسب برای نگارش مشخص‌شدهٔ Java SE تولید می‌کند. مقادیر پشتیبانی‌شده برای \f[I]release\f[R] نگارش فعلی Java SE و تعداد محدودی از نگارش‌های پیشین هستند که جزئیات آن‌ها در راهنمای خط فرمان آمده است. .RS .PP \f[B]نکته:\f[R] نگارش هدف باید مساوی یا بالاتر از نگارش منبع باشد. (\f[B]\f[VB]--source\f[B]\f[R] را ببینید.) .RE .TP \f[V]--upgrade-module-path\f[R] \f[I]path\f[R] مکان ماژول‌های ارتقاپذیر را جایگزین می‌کند. .TP \f[V]-verbose\f[R] پیام‌هایی دربارهٔ عملکرد کامپایلر در خروجی نمایش می‌دهد. پیام‌ها شامل اطلاعاتی دربارهٔ هر کلاس بارگذاری‌شده و هر فایل منبع کامپایل‌شده است. .TP \f[V]--version\f[R] یا \f[V]-version\f[R] اطلاعات نگارش را نمایش می‌دهد. .TP \f[V]-Werror\f[R] در صورت بروز هشدار، فرآیند کامپایل را متوقف می‌کند. .SS گزینه‌های اضافی (Extra Options) .TP \f[V]--add-exports\f[R] \f[I]module\f[R]\f[V]/\f[R]\f[I]package\f[R]\f[V]=\f[R]\f[I]other-module\f[R](\f[V],\f[R]\f[I]other-module\f[R])* بسته‌ای را مشخص می‌کند تا طوری در نظر گرفته شود که از ماژول تعریف‌کننده‌اش به ماژول‌های دیگر، یا در صورتی که مقدار \f[I]other-module\f[R] برابر با \f[V]ALL-UNNAMED\f[R] باشد به تمام ماژول‌های بی‌نام، صادر (export) شده است. .TP \f[V]--add-reads\f[R] \f[I]module\f[R]\f[V]=\f[R]\f[I]other-module\f[R](\f[V],\f[R]\f[I]other-module\f[R])* ماژول‌های اضافی را مشخص می‌کند تا به عنوان نیازمندی‌های یک ماژول داده‌شده در نظر گرفته شوند. .TP \f[V]--default-module-for-created-files\f[R] \f[I]module-name\f[R] ماژول هدف پیش‌فرض (fallback) را برای فایل‌های ایجادشده توسط پردازشگرهای حاشیه‌نویسی (annotation processors)، در صورتی که هیچ ماژولی مشخص یا استنباط نشده باشد، تعیین می‌کند. .TP \f[V]-Djava.endorsed.dirs=\f[R]\f[I]dirs\f[R] مکان مسیر استانداردهای تأییدشده (endorsed standards) را جایگزین می‌کند. .RS .PP \f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های پیش از JDK 9 قابل استفاده است. برای جزئیات بیشتر، بر حسب مورد، توضیحات موجود در \f[B]\f[VB]--release\f[B]\f[R]، \f[B]\f[VB]-source\f[B]\f[R] یا \f[B]\f[VB]-target\f[B]\f[R] را ببینید. .RE .TP \f[V]-Djava.ext.dirs=\f[R]\f[I]dirs\f[R] مکان افزونه‌های نصب‌شده را جایگزین می‌کند. .RS .PP \f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های پیش از JDK 9 قابل استفاده است. برای جزئیات بیشتر، بر حسب مورد، توضیحات موجود در \f[B]\f[VB]--release\f[B]\f[R]، \f[B]\f[VB]-source\f[B]\f[R] یا \f[B]\f[VB]-target\f[B]\f[R] را ببینید. .RE .TP \f[V]--patch-module\f[R] \f[I]module\f[R]\f[V]=\f[R]\f[I]path\f[R] یک ماژول را با کلاس‌ها و منابع موجود در فایل‌های JAR یا دایرکتوری‌ها بازنویسی یا گسترش می‌دهد. .TP \f[V]-Xbootclasspath:\f[R]\f[I]path\f[R] مکان فایل‌های کلاس راه‌انداز (bootstrap) را جایگزین می‌کند. .RS .PP \f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های پیش از JDK 9 قابل استفاده است. برای جزئیات بیشتر، بر حسب مورد، توضیحات موجود در \f[B]\f[VB]--release\f[B]\f[R]، \f[B]\f[VB]-source\f[B]\f[R] یا \f[B]\f[VB]-target\f[B]\f[R] را ببینید. .RE .TP \f[V]-Xbootclasspath/a:\f[R]\f[I]path\f[R] یک پسوند به مسیر کلاس‌های راه‌انداز اضافه می‌کند. .RS .PP \f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های پیش از JDK 9 قابل استفاده است. برای جزئیات بیشتر، بر حسب مورد، توضیحات موجود در \f[B]\f[VB]--release\f[B]\f[R]، \f[B]\f[VB]-source\f[B]\f[R] یا \f[B]\f[VB]-target\f[B]\f[R] را ببینید. .RE .TP \f[V]-Xbootclasspath/p:\f[R]\f[I]path\f[R] یک پیشوند به مسیر کلاس‌های راه‌انداز اضافه می‌کند. .RS .PP \f[B]نکته:\f[R] این گزینه فقط هنگام کامپایل برای نگارش‌های پیش از JDK 9 قابل استفاده است. برای جزئیات بیشتر، بر حسب مورد، توضیحات موجود در \f[B]\f[VB]--release\f[B]\f[R]، \f[B]\f[VB]-source\f[B]\f[R] یا \f[B]\f[VB]-target\f[B]\f[R] را ببینید. .RE .TP \f[V]-Xdiags:\f[R][\f[V]compact\f[R], \f[V]verbose\f[R]] یک حالت عیب‌یابی را انتخاب می‌کند. .TP \f[V]-Xdoclint\f[R] بررسی‌های توصیه‌شده برای مشکلات موجود در کامنت‌های مستندسازی را فعال می‌کند. .TP \f[V]-Xdoclint:\f[R](\f[V]all\f[R]|\f[V]none\f[R]|[\f[V]-\f[R]]\f[I]group\f[R])[\f[V]/\f[R]\f[I]access\f[R]] گروه‌های خاصی از بررسی‌ها در کامنت‌های مستندسازی را فعال یا غیرفعال می‌کند. .RS .PP متغیر \f[I]group\f[R] می‌تواند یکی از مقادیر زیر را داشته باشد: \f[V]accessibility\f[R]، \f[V]html\f[R]، \f[V]missing\f[R]، \f[V]reference\f[R]، \f[V]syntax\f[R]. .PP متغیر \f[I]access\f[R] حداقل سطح دید (visibility) کلاس‌ها و اعضایی را که گزینهٔ \f[V]-Xdoclint\f[R] بررسی می‌کند، مشخص می‌نماید. این متغیر می‌تواند یکی از مقادیر زیر را داشته باشد (به ترتیب از بیشترین به کمترین میزان دید): \f[V]public\f[R]، \f[V]protected\f[R]، \f[V]package\f[R]، \f[V]private\f[R]. .PP سطح دید پیش‌فرض \f[I]access\f[R] برابر با \f[V]private\f[R] است. .PP هنگامی که پیشوند \f[V]doclint:\f[R] اعمال شود، نام‌های \f[I]group\f[R] و \f[V]all\f[R] را می‌توان همراه با \f[V]\[at]SuppressWarnings\f[R] برای نادیده گرفتن هشدارهای مربوط به کامنت‌های مستندسازی در بخش‌هایی از کد کامپایل‌شونده استفاده کرد. .PP برای اطلاعات بیشتر دربارهٔ این گروه‌های بررسی، بخش \f[B]DocLint\f[R] از مستندات دستور \f[V]javadoc\f[R] را ببینید. گزینهٔ \f[V]-Xdoclint\f[R] به صورت پیش‌فرض در دستور \f[V]javac\f[R] غیرفعال است. .PP برای مثال، گزینهٔ زیر کلاس‌ها و اعضایی را (با تمام گروه‌های بررسی) بررسی می‌کند که سطح دسترسی protected و بالاتر دارند (شامل protected و public): .RS .PP \f[V]-Xdoclint:all/protected\f[R] .RE .PP گزینهٔ زیر تمام گروه‌های بررسی را برای همهٔ سطوح دسترسی فعال می‌کند، به جز اینکه خطاهای HTML را برای کلاس‌ها و اعضایی که سطح دسترسی package و بالاتر دارند (شامل package، protected و public) بررسی نخواهد کرد: .RS .PP \f[V]-Xdoclint:all,-html/package\f[R] .RE .RE .TP \f[V]-Xdoclint/package:\f[R][\f[V]-\f[R]]\f[I]packages\f[R](\f[V],\f[R][\f[V]-\f[R]]\f[I]package\f[R])* بررسی‌ها را در بسته‌های مشخص فعال یا غیرفعال می‌کند. هر \f[I]package\f[R] یا نام کامل یک بسته است یا پیشوندی از نام بسته به همراه \f[V].*\f[R]، که به تمام زیربسته‌های بستهٔ داده‌شده گسترش می‌یابد. هر \f[I]package\f[R] می‌تواند یک پیشوند خط تیره (\f[V]-\f[R]) داشته باشد تا بررسی‌ها برای بسته یا بسته‌های مشخص‌شده غیرفعال شوند. .RS.PP برای اطلاعات بیشتر، بخش \f[B]DocLint\f[R] از مستندات دستور \f[V]javadoc\f[R] را ببینید. .RE .TP \f[V]-Xlint\f[R] تمام هشدارهای توصیه‌شده را فعال می‌کند. در این نسخه، فعال‌سازی تمام هشدارهای موجود توصیه می‌شود. .TP \f[V]-Xlint:\f[R][\f[V]-\f[R]]\f[I]key\f[R](\f[V],\f[R][\f[V]-\f[R]]\f[I]key\f[R])* هشدارهایی را برای فعال یا غیرفعال کردن، به صورت جداشده با ویرگول تعیین می‌کند. برای غیرفعال کردن یک هشدار مشخص، پیش از کلید یک خط تیره (\f[V]-\f[R]) قرار دهید. .RS .PP مقادیر پشتیبانی‌شده برای \f[I]key\f[R] عبارتند از: .IP \[bu] 2 \f[V]all\f[R]: تمام هشدارها را فعال می‌کند. .IP \[bu] 2 \f[V]auxiliaryclass\f[R]: درباره یک کلاس کمکی که در یک فایل مبدأ پنهان شده و از فایل‌های دیگر استفاده می‌شود، هشدار می‌دهد. .IP \[bu] 2 \f[V]cast\f[R]: درباره استفاده از تبدیل نوع‌های (cast) غیرضروری هشدار می‌دهد. .IP \[bu] 2 \f[V]classfile\f[R]: درباره مسائل مربوط به محتویات فایل کلاس (classfile) هشدار می‌دهد. .IP \[bu] 2 \f[V]deprecation\f[R]: درباره استفاده از موارد منسوخ‌شده هشدار می‌دهد. .IP \[bu] 2 \f[V]dep-ann\f[R]: درباره مواردی که در \f[V]javadoc\f[R] به عنوان منسوخ علامت‌گذاری شده‌اند اما فاقد یادداشت \f[V]\[at]Deprecated\f[R] هستند، هشدار می‌دهد. .IP \[bu] 2 \f[V]divzero\f[R]: درباره تقسیم بر عدد صحیح ثابت 0 هشدار می‌دهد. .IP \[bu] 2 \f[V]empty\f[R]: درباره دستور خالی پس از \f[V]if\f[R] هشدار می‌دهد. .IP \[bu] 2 \f[V]exports\f[R]: درباره مسائل مربوط به صدورهای ماژول (module exports) هشدار می‌دهد. .IP \[bu] 2 \f[V]fallthrough\f[R]: درباره ریزش (fall-through) از یک حالت دستور switch به حالت بعدی هشدار می‌دهد. .IP \[bu] 2 \f[V]finally\f[R]: درباره بندهای \f[V]finally\f[R] که به‌طور عادی خاتمه نمی‌یابند هشدار می‌دهد. .IP \[bu] 2 \f[V]lossy-conversions\f[R]: درباره تبدیل‌های همراه با اتلاف احتمالی در انتساب‌های مرکب هشدار می‌دهد. .IP \[bu] 2 \f[V]missing-explicit-ctor\f[R]: درباره نبود سازنده‌های صریح در کلاس‌های public و protected درون بسته‌های صادرشده هشدار می‌دهد. .IP \[bu] 2 \f[V]module\f[R]: درباره مسائل مربوط به سامانه ماژول هشدار می‌دهد. .IP \[bu] 2 \f[V]opens\f[R]: درباره مسائل مربوط به گشودن‌های ماژول (module opens) هشدار می‌دهد. .IP \[bu] 2 \f[V]options\f[R]: درباره مسائل مربوط به استفاده از گزینه‌های خط فرمان هشدار می‌دهد. .IP \[bu] 2 \f[V]output-file-clash\f[R]: اگر فایلی در خروجی حین کامپایل بازنویسی شود، هشدار می‌دهد. این وضعیت مثلاً می‌تواند در سیستم‌های فایلی که به بزرگی و کوچکی حروف حساس نیستند رخ دهد. .IP \[bu] 2 \f[V]overloads\f[R]: درباره مسائل مربوط به چندریختی یا سربارگذاری متدها (method overloads) هشدار می‌دهد. .IP \[bu] 2 \f[V]overrides\f[R]: درباره مسائل مربوط به بازنویسی متدها (method overrides) هشدار می‌دهد. .IP \[bu] 2 \f[V]path\f[R]: درباره عناصر مسیر نامعتبر در خط فرمان هشدار می‌دهد. .IP \[bu] 2 \f[V]preview\f[R]: درباره استفاده از ویژگی‌های پیش‌نمایش زبان هشدار می‌دهد. .IP \[bu] 2 \f[V]processing\f[R]: درباره مسائل مربوط به پردازش یادداشت‌ها (annotation processing) هشدار می‌دهد. .IP \[bu] 2 \f[V]rawtypes\f[R]: درباره استفاده از نوع‌های خام (raw types) هشدار می‌دهد. .IP \[bu] 2 \f[V]removal\f[R]: درباره استفاده از یک API که برای حذف علامت‌گذاری شده است، هشدار می‌دهد. .IP \[bu] 2 \f[V]requires-automatic\f[R]: به توسعه‌دهندگان درباره استفاده از ماژول‌های خودکار در بندهای requires هشدار می‌دهد. .IP \[bu] 2 \f[V]requires-transitive-automatic\f[R]: درباره ماژول‌های خودکار در requires transitive هشدار می‌دهد. .IP \[bu] 2 \f[V]serial\f[R]: درباره کلاس‌های سریال‌پذیر (serializable) که شناسه نسخه سریال (serial version ID) ارائه نمی‌دهند هشدار می‌دهد. همچنین درباره دسترسی به اعضای غیرعمومی از طریق یک عنصر سریال‌پذیر هشدار می‌دهد. .IP \[bu] 2 \f[V]static\f[R]: درباره دسترسی به یک عضو ایستا (static) با استفاده از یک نمونه هشدار می‌دهد. .IP \[bu] 2 \f[V]strictfp\f[R]: درباره استفاده غیرضروری از اصلاح‌گر \f[V]strictfp\f[R] هشدار می‌دهد. .IP \[bu] 2 \f[V]synchronization\f[R]: درباره تلاش برای همگام‌سازی روی نمونه‌هایی از کلاس‌های مبتنی بر مقدار هشدار می‌دهد. .IP \[bu] 2 \f[V]text-blocks\f[R]: درباره نویسه‌های فاصله‌گذاری ناسازگار در تورفتگی بلوک‌های متنی هشدار می‌دهد. .IP \[bu] 2 \f[V]this-escape\f[R]: درباره نشت \f[V]this\f[R] توسط سازنده‌ها پیش از مقداردهی اولیه زیرکلاس هشدار می‌دهد. .IP \[bu] 2 \f[V]try\f[R]: درباره مسائل مربوط به استفاده از بلوک‌های try (یعنی try-with-resources) هشدار می‌دهد. .IP \[bu] 2 \f[V]unchecked\f[R]: درباره عملیات‌های بررسی‌نشده (unchecked) هشدار می‌دهد. .IP \[bu] 2 \f[V]varargs\f[R]: درباره متدهای \f[V]vararg\f[R] بالقوه ناامن هشدار می‌دهد. .IP \[bu] 2 \f[V]none\f[R]: تمام هشدارها را غیرفعال می‌کند. .PP به استثنای \f[V]all\f[R] و \f[V]none\f[R]، کلیدها می‌توانند همراه با یادداشت \f[V]\[at]SuppressWarnings\f[R] برای فرونشاندن هشدارها در بخشی از کد مبدأ که کامپایل می‌شود استفاده شوند. .PP بخش \f[B]Examples of Using -Xlint keys\f[R] را ببینید. .RE .TP \f[V]-Xmaxerrs\f[R] \f[I]number\f[R] حداکثر تعداد خطاهای قابل چاپ را تنظیم می‌کند. .TP \f[V]-Xmaxwarns\f[R] \f[I]number\f[R] حداکثر تعداد هشدارهای قابل چاپ را تنظیم می‌کند. .TP \f[V]-Xpkginfo:\f[R][\f[V]always\f[R], \f[V]legacy\f[R], \f[V]nonempty\f[R]] با استفاده از یکی از گزینه‌های زیر مشخص می‌کند که دستور \f[V]javac\f[R] چه زمانی و چگونه فایل‌های \f[V]package-info.class\f[R] را از فایل‌های \f[V]package-info.java\f[R] تولید کند: .RS .TP \f[V]always\f[R] برای هر فایل \f[V]package-info.java\f[R] یک فایل \f[V]package-info.class\f[R] تولید می‌کند. این گزینه اگر از سامانه‌های ساختی مانند Ant استفاده می‌کنید که بررسی می‌کنند آیا هر فایل \f[V].java\f[R] یک فایل متناظر \f[V].class\f[R] دارد یا خیر، ممکن است مفید باشد. .TP \f[V]legacy\f[R] تنها در صورتی یک فایل \f[V]package-info.class\f[R] تولید می‌کند که \f[V]package-info.java\f[R] حاوی یادداشت باشد. این گزینه اگر \f[V]package-info.java\f[R] فقط شامل توضیحات (comments) باشد، فایل \f[V]package-info.class\f[R] تولید نمی‌کند. .RS .PP \f[B]نکته:\f[R] اگر تمام یادداشت‌های موجود در فایل \f[V]package-info.java\f[R] دارای \f[V]RetentionPolicy.SOURCE\f[R] باشند، ممکن است یک فایل \f[V]package-info.class\f[R] تولید شود اما خالی باشد. .RE .TP \f[V]nonempty\f[R] تنها در صورتی یک فایل \f[V]package-info.class\f[R] تولید می‌کند که \f[V]package-info.java\f[R] حاوی یادداشت‌هایی با \f[V]RetentionPolicy.CLASS\f[R] یا \f[V]RetentionPolicy.RUNTIME\f[R] باشد. .RE .TP \f[V]-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] درون گیومه قرار گیرند یا نویسه‌های فاصله بین نام و همه آرگومان‌ها به روش دیگری گریز داده (escape) شوند. برای جزئیات بیشتر درباره API افزونه، به مستندات API برای \f[B]jdk.compiler/com.sun.source.util.Plugin\f[R] مراجعه کنید. .TP \f[V]-Xprefer:\f[R][\f[V]source\f[R], \f[V]newer\f[R]] با استفاده از یکی از گزینه‌های زیر مشخص می‌کند هنگام پیدا شدن هم‌زمان یک فایل مبدأ و فایل کلاس برای کلاسی که به‌طور ضمنی کامپایل شده است، کدام فایل خوانده شود. بخش \f[B]Searching for Module, Package and Type Declarations\f[R] را ببینید. .RS .IP \[bu] 2 \f[V]-Xprefer:newer\f[R]: فایل تازه‌تر را از میان فایل‌های مبدأ یا کلاس برای یک نوع می‌خواند (پیش‌فرض). .IP \[bu] 2 \f[V]-Xprefer:source\f[R] : فایل مبدأ را می‌خواند. هنگامی که می‌خواهید مطمئن شوید پردازنده‌های یادداشت می‌توانند به یادداشت‌های اعلان‌شده با سیاست نگهداری \f[V]SOURCE\f[R] دسترسی داشته باشند، از \f[V]-Xprefer:source\f[R] استفاده کنید. .RE.TP \f[V]-Xprint\f[R] نمایشی متنی از نوع‌های مشخص‌شده را برای اهداف اشکال‌زدایی چاپ می‌کند. این گزینه پردازش حاشیه‌نویسی یا کامپایل را انجام نمی‌دهد. قالب خروجی ممکن است تغییر کند. .TP \f[V]-XprintProcessorInfo\f[R] اطلاعاتی درباره اینکه پردازشگر برای پردازش چه حاشیه‌نویسی‌هایی فراخوانی شده است را چاپ می‌کند. .TP \f[V]-XprintRounds\f[R] اطلاعات مربوط به دورهای اولیه و بعدی پردازش حاشیه‌نویسی را چاپ می‌کند. .TP \f[V]-Xstdout\f[R] \f[I]filename\f[R] پیام‌های کامپایلر را به فایل مشخص‌شده ارسال می‌کند. به‌طور پیش‌فرض، پیام‌های کامپایلر به \f[V]System.err\f[R] فرستاده می‌شوند. .SH "متغیرهای محیطی (ENVIRONMENT VARIABLES)" .SS CLASSPATH .PP اگر گزینهٔ \f[B]\f[VB]--class-path\f[B]\f[R] یا هر یک از اشکال جایگزین آن مشخص نشده باشد، مسیر کلاس به‌طور پیش‌فرض برابر با مقدار متغیر محیطی \f[V]CLASSPATH\f[R] (در صورت تنظیم بودن) خواهد بود. با این حال، توصیه می‌شود که این متغیر محیطی تنظیم \f[I]نشود\f[R] و در صورت نیاز، از گزینهٔ \f[V]--class-path\f[R] برای تعیین یک مقدار صریح برای مسیر کلاس استفاده گردد. .SS JDK_JAVAC_OPTIONS .PP محتوای متغیر محیطی \f[V]JDK_JAVAC_OPTIONS\f[R] که با فاصله‌ها ( ) یا نویسه‌های فاصله (\f[V]\[rs]n\f[R]، \f[V]\[rs]t\f[R]، \f[V]\[rs]r\f[R]، یا \f[V]\[rs]f\f[R]) جدا شده است، به عنوان فهرستی از آرگومان‌ها به ابتدای آرگومان‌های خط فرمان ارسالی به \f[V]javac\f[R] اضافه می‌شود. .PP نیازمندی‌های کدگذاری برای متغیر محیطی، همانند خط فرمان \f[V]javac\f[R] در سیستم است. با محتوای متغیر محیطی \f[V]JDK_JAVAC_OPTIONS\f[R] دقیقاً مانند مواردی که در خط فرمان مشخص شده باشند رفتار می‌شود. .PP می‌توان از نقل‌قول تکی (\f[V]\[aq]\f[R]) یا نقل‌قول دوتایی (\f[V]\[dq]\f[R]) برای محصور کردن آرگومان‌هایی که حاوی نویسه‌های فاصله هستند استفاده کرد. تمام محتوای بین نقل‌قول باز و اولین نقل‌قول بستهٔ منطبق، تنها با حذف جفت نقل‌قول حفظ می‌شود. در صورتی که نقل‌قول منطبق پیدا نشود، اجراکننده (launcher) با یک پیام خطا متوقف خواهد شد. فایل‌های \f[V]\[at]\f[R]\f[I]files\f[R] همانند مشخص‌شدن در خط فرمان پشتیبانی می‌شوند. با این حال، همانند \f[V]\[at]\f[R]\f[I]files\f[R]، استفاده از نویسه‌های عمومی (wildcard) پشتیبانی نمی‌شود. .PP \f[B]مثال‌هایی از نقل‌قول آرگومان‌های حاوی نویسه‌های فاصله:\f[R] .RS .PP \f[V]export JDK_JAVAC_OPTIONS=\[aq]\[at]\[dq]C:\[rs]white spaces\[rs]argfile\[dq]\[aq]\f[R] .RE .RS .PP \f[V]export JDK_JAVAC_OPTIONS=\[aq]\[dq]\[at]C:\[rs]white spaces\[rs]argfile\[dq]\[aq]\f[R] .RE .RS .PP \f[V]export JDK_JAVAC_OPTIONS=\[aq]\[at]C:\[rs]\[dq]white spaces\[dq]\[rs]argfile\[aq]\f[R] .RE .SH "فایل‌های آرگومان خط فرمان (COMMAND-LINE ARGUMENT FILES)" .PP یک فایل آرگومان می‌تواند شامل گزینه‌های خط فرمان و نام فایل‌های منبع در هر ترکیبی باشد. آرگومان‌های درون یک فایل می‌توانند با فاصله یا نویسه‌های خط جدید از هم جدا شوند. اگر نام یک فایل حاوی فاصله‌های درونی باشد، کل نام فایل را درون علامت نقل‌قول دوتایی قرار دهید. .PP نام‌های فایل درون یک فایل آرگومان، نسبت به دایرکتوری جاری سنجیده می‌شوند، نه محل قرارگیری فایل آرگومان. استفاده از نویسه‌های عمومی (\f[V]*\f[R]) در این فهرست‌ها مجاز نیست (مانند تعیین \f[V]*.java\f[R]). استفاده از علامت اَت‌ساین (\f[V]\[at]\f[R]) برای تفسیر بازگشتی فایل‌ها پشتیبانی نمی‌شود. گزینه‌های \f[V]-J\f[R] پشتیبانی نمی‌شوند زیرا به اجراکننده ارسال می‌شوند که از فایل‌های آرگومان پشتیبانی نمی‌کند. .PP هنگام اجرای دستور \f[V]javac\f[R]، مسیر و نام هر فایل آرگومان را با نویسهٔ پیشوند اَت‌ساین (\f[V]\[at]\f[R]) وارد کنید. هنگامی که دستور \f[V]javac\f[R] با آرگومانی مواجه شود که با علامت اَت‌ساین (\f[V]\[at]\f[R]) آغاز می‌شود، محتویات آن فایل را در فهرست آرگومان‌ها می‌گستراند..SS مثال‌هایی از استفاده از javac \[at]filename .TP فایل آرگومان منفرد می‌توانید از یک فایل آرگومان منفرد به نام \f[V]argfile\f[R] برای نگه‌داری تمام آرگومان‌های \f[V]javac\f[R] استفاده کنید: .RS .RS .PP \f[V]javac \[at]argfile\f[R] .RE .PP این فایل آرگومان می‌تواند شامل محتوای هر دو فایل نشان‌داده‌شده در مثال \f[B]دو فایل آرگومان\f[R] در ادامه باشد. .RE .TP دو فایل آرگومان می‌توانید دو فایل آرگومان ایجاد کنید: یکی برای گزینه‌های \f[V]javac\f[R] و دیگری برای نام‌های فایل‌های منبع. توجه داشته باشید که فهرست‌های زیر هیچ نویسهٔ ادامه‌دهندهٔ خطی ندارند. .RS .PP فایلی به نام \f[V]options\f[R] ایجاد کنید که حاوی موارد زیر باشد: .PP \f[B]Linux و 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]Windows:\f[R] .IP .nf \f[CB] -d classes -g -sourcepath C:\[rs]java\[rs]pubs\[rs]ws\[rs]1.3\[rs]src\[rs]share\[rs]classes \f[R] .fi .PP فایلی به نام \f[V]sources\f[R] ایجاد کنید که حاوی موارد زیر باشد: .IP .nf \f[CB] MyClass1.java MyClass2.java MyClass3.java \f[R] .fi .PP سپس، دستور \f[V]javac\f[R] را به شکل زیر اجرا کنید: .RS .PP \f[V]javac \[at]options \[at]sources\f[R] .RE .RE .TP فایل‌های آرگومان دارای مسیر فایل‌های آرگومان می‌توانند مسیر داشته باشند، اما هر نام فایلی درون این فایل‌ها نسبت به دایرکتوری کاری فعلی سنجیده می‌شود (نه نسبت به \f[V]path1\f[R] یا \f[V]path2\f[R]): .RS .RS .PP \f[V]javac \[at]path1/options \[at]path2/sources\f[R] .RE .RE .SH "چینش کد منبع (ARRANGEMENT OF SOURCE CODE)" .PP در زبان Java، کلاس‌ها و رابط‌ها (interfaces) می‌توانند در بسته‌ها، و بسته‌ها در ماژول‌ها سازمان‌دهی شوند. \f[V]javac\f[R] انتظار دارد که چینش فیزیکی فایل‌های منبع در دایرکتوری‌های سیستم فایل، بازتاب‌دهندهٔ سازمان‌دهی کلاس‌ها در بسته‌ها، و بسته‌ها در ماژول‌ها باشد. .PP این یک قرارداد پذیرفته‌شدهٔ گسترده است که نام ماژول‌ها و نام بسته‌ها با یک حرف کوچک، و نام کلاس‌ها با یک حرف بزرگ آغاز شوند..SS چیدمان کد منبع برای یک بسته .PP هنگامی که کلاس‌ها و رابط‌ها در یک بسته سازمان‌دهی می‌شوند، آن بسته به‌صورت یک دایرکتوری و هر زیربسته به‌صورت یک زیردایرکتوری نشان داده می‌شود. .PP برای نمونه: .IP \[bu] 2 بسته \f[V]p\f[R] به‌صورت دایرکتوری‌ای به نام \f[V]p\f[R] نمایش داده می‌شود. .IP \[bu] 2 بسته \f[V]p.q\f[R] \-\- یعنی، زیربسته \f[V]q\f[R] از بسته \f[V]p\f[R] \-\- به‌صورت زیردایرکتوری \f[V]q\f[R] از دایرکتوری \f[V]p\f[R] نمایش داده می‌شود. بنابراین درخت دایرکتوری نمایش‌دهنده بسته \f[V]p.q\f[R] در ویندوز \f[V]p\[rs]q\f[R] و در سایر سیستم‌ها \f[V]p/q\f[R] است. .IP \[bu] 2 بسته \f[V]p.q.r\f[R] به‌صورت درخت دایرکتوری \f[V]p\[rs]q\[rs]r\f[R] (در ویندوز) یا \f[V]p/q/r\f[R] (در سایر سیستم‌ها) نمایش داده می‌شود. .PP درون یک دایرکتوری یا زیردایرکتوری، فایل‌های \f[V].java\f[R] نشان‌دهنده کلاس‌ها و رابط‌های موجود در بسته یا زیربسته متناظر هستند. .PP برای نمونه: .IP \[bu] 2 کلاس \f[V]X\f[R] اعلان‌شده در بسته \f[V]p\f[R] با فایل \f[V]X.java\f[R] در دایرکتوری \f[V]p\f[R] نمایش داده می‌شود. .IP \[bu] 2 کلاس \f[V]Y\f[R] اعلان‌شده در بسته \f[V]p.q\f[R] با فایل \f[V]Y.java\f[R] در زیردایرکتوری \f[V]q\f[R] از دایرکتوری \f[V]p\f[R] نمایش داده می‌شود. .IP \[bu] 2 کلاس \f[V]Z\f[R] اعلان‌شده در بسته \f[V]p.q.r\f[R] با فایل \f[V]Z.java\f[R] در زیردایرکتوری \f[V]r\f[R] از \f[V]p\[rs]q\f[R] (در ویندوز) یا \f[V]p/q\f[R] (در سایر سیستم‌ها) نمایش داده می‌شود. .PP در برخی شرایط، مناسب است که کد به دایرکتوری‌های جداگانه تقسیم شود، به‌طوری که ساختار هر یک طبق توضیحات بالا باشد، و فهرست تجمیعی دایرکتوری‌ها به \f[V]javac\f[R] مشخص گردد. .SS چیدمان کد منبع برای یک ماژول .PP در زبان Java، یک ماژول مجموعه‌ای از بسته‌ها است که برای استفاده مجدد طراحی شده‌اند. علاوه بر فایل‌های \f[V].java\f[R] برای کلاس‌ها و رابط‌ها، هر ماژول دارای یک فایل منبع به نام \f[V]module-info.java\f[R] است که: .IP "1." 3 نام ماژول را اعلان می‌کند؛ .IP "2." 3 بسته‌های صادرشده توسط ماژول را فهرست می‌کند (تا امکان استفاده مجدد توسط سایر ماژول‌ها فراهم شود)؛ .IP "3." 3 سایر ماژول‌های مورد نیاز ماژول را فهرست می‌کند (برای استفاده مجدد از بسته‌های صادرشده آن‌ها). .PP هنگامی که بسته‌ها در یک ماژول سازمان‌دهی می‌شوند، ماژول توسط یک یا چند دایرکتوری نمایش داده می‌شود که نشان‌دهنده بسته‌های درون ماژول هستند و یکی از آن‌ها حاوی فایل \f[V]module-info.java\f[R] است. استفاده از یک دایرکتوری واحد، هم‌نام با ماژول، برای نگهداری فایل \f[V]module-info.java\f[R] در کنار درخت دایرکتوری نشان‌دهنده بسته‌های ماژول (یعنی همان \f[I]سلسله‌مراتب بسته‌ها\f[R] که در بالا توضیح داده شد) ممکن است راحت‌تر باشد، اما الزامی نیست. چیدمان دقیق کد منبع برای یک ماژول معمولاً بر اساس شیوه‌نامه‌های اتخاذشده توسط یک محیط توسعه (IDE) یا سامانه ساخت تعیین می‌شود. .PP برای نمونه: .IP \[bu] 2 ماژول \f[V]a.b.c\f[R] ممکن است در تمام سیستم‌ها توسط دایرکتوری \f[V]a.b.c\f[R] نمایش داده شود. .IP \[bu] 2 اعلان ماژول توسط فایل \f[V]module-info.java\f[R] در دایرکتوری \f[V]a.b.c\f[R] نمایش داده می‌شود. .IP \[bu] 2 اگر ماژول حاوی بسته \f[V]p.q.r\f[R] باشد، آنگاه دایرکتوری \f[V]a.b.c\f[R] شامل درخت دایرکتوری \f[V]p\[rs]q\[rs]r\f[R] (در ویندوز) یا \f[V]p/q/r\f[R] (در سایر سیستم‌ها) خواهد بود. .PP محیط توسعه ممکن است سلسله‌مراتبی از دایرکتوری‌ها را بین دایرکتوری هم‌نام با ماژول و فایل‌های منبعی که قرار است توسط \f[V]javac\f[R] خوانده شوند، تعیین کند. .PP برای نمونه: .IP \[bu] 2 ماژول \f[V]a.b.c\f[R] ممکن است با دایرکتوری \f[V]a.b.c\f[R] نمایش داده شود. .IP \[bu] 2 اعلان ماژول و بسته‌های ماژول ممکن است در زیردایرکتوری خاصی از \f[V]a.b.c\f[R] قرار گیرند، مانند \f[V]src\[rs]main\[rs]java\f[R] (در ویندوز) یا \f[V]src/main/java\f[R] (در سایر سیستم‌ها)..SH "پیکربندی کامپایل (CONFIGURING A COMPILATION)" .PP این بخش نحوهٔ پیکربندی \f[V]javac\f[R] را برای انجام یک کامپایل پایه‌ای شرح می‌دهد. .PP برای جزئیات بیشتر جهت استفاده در هنگام کامپایل برای نسخه‌ای از پلتفرم که از ماژول‌ها پشتیبانی می‌کند، بخش \f[B]Configuring the Module System\f[R] را ببینید. .SS "فایل‌های منبع (Source Files)" .IP \[bu] 2 فایل‌های منبعی را که قرار است کامپایل شوند در خط فرمان مشخص کنید. .PP اگر هیچ خطای کامپایلی وجود نداشته باشد، فایل‌های کلاس متناظر در \f[B]دایرکتوری خروجی\f[R] قرار خواهند گرفت. .PP برخی سیستم‌ها ممکن است طول خط فرمان را محدود کنند؛ برای دور زدن این محدودیت‌ها، می‌توانید از \f[B]فایل‌های آرگومان\f[R] استفاده کنید. .PP هنگام کامپایل کد برای ماژول‌ها، می‌توانید فایل‌های منبع را به صورت غیرمستقیم و با استفاده از گزینهٔ \f[B]\f[VB]--module\f[B]\f[R] یا \f[V]-m\f[R] نیز مشخص کنید. .SS "دایرکتوری خروجی (Output Directory)" .IP \[bu] 2 از گزینهٔ \f[B]\f[VB]-d\f[B]\f[R] برای تعیین یک دایرکتوری خروجی جهت قرار دادن فایل‌های کلاس کامپایل‌شده استفاده کنید. .PP این ساختار معمولاً در یک \f[B]سلسله‌مراتب بسته‌ای\f[R] سازمان‌دهی می‌شود، مگر اینکه در حال کامپایل کد منبع از چندین ماژول باشید که در این صورت به عنوان یک \f[B]سلسله‌مراتب ماژولی\f[R] سازمان‌دهی خواهد شد. .PP پس از اتمام کامپایل، اگر در حال کامپایل یک یا چند ماژول هستید، می‌توانید دایرکتوری خروجی را در مسیر ماژول (module path) برای \f[B]راه‌انداز\f[R] جاوا قرار دهید؛ در غیر این صورت، می‌توانید دایرکتوری خروجی را در مسیر کلاس (class path) برای راه‌انداز جاوا قرار دهید. .SS "کد از پیش‌کامپایل‌شده (Precompiled Code)" .PP کدی که قرار است کامپایل شود ممکن است به کتابخانه‌هایی فراتر از آنچه توسط پلتفرم ارائه شده ارجاع دهد. در این صورت، باید این کتابخانه‌ها را در مسیر کلاس یا مسیر ماژول قرار دهید. اگر کد کتابخانه در یک ماژول نیست، آن را در مسیر کلاس قرار دهید؛ اگر در یک ماژول است، آن را در مسیر ماژول بگذارید. .IP \[bu] 2 از گزینهٔ \f[B]\f[VB]--class-path\f[B]\f[R] برای تعیین کتابخانه‌هایی که باید در مسیر کلاس قرار گیرند استفاده کنید. مکان‌ها در مسیر کلاس باید در یک \f[B]سلسله‌مراتب بسته‌ای\f[R] سازمان‌دهی شوند. همچنین می‌توانید از اشکال دیگر این گزینه استفاده کنید: \f[V]-classpath\f[R] یا \f[V]-cp\f[R]. .IP \[bu] 2 از گزینهٔ \f[B]\f[VB]--module-path\f[B]\f[R] برای تعیین کتابخانه‌هایی که باید در مسیر ماژول قرار گیرند استفاده کنید. مکان‌ها در مسیر ماژول باید خود ماژول یا دایرکتوری‌هایی از ماژول‌ها باشند. همچنین می‌توانید از شکل دیگر این گزینه استفاده کنید: \f[V]-p\f[R]. .RS 2 .PP برای جزئیات بیشتر در مورد نحوهٔ تغییر پیکربندی پیش‌فرض ماژول‌های کتابخانه، بخش \f[B]Configuring the Module System\f[R] را ببینید. .RE .PP \f[B]نکته\f[R]: گزینه‌های مربوط به مسیر کلاس و مسیر ماژول مانعة‌الجمع نیستند، اگرچه مشخص کردن مسیر کلاس هنگام کامپایل کد برای یک یا چند ماژول معمول نیست. .SS "فایل‌های منبع اضافی (Additional Source Files)" .PP کدی که قرار است کامپایل شود ممکن است به انواعی در فایل‌های منبع اضافی که در خط فرمان مشخص نشده‌اند ارجاع دهد. در این صورت، باید آن فایل‌های منبع را در مسیر منبع (source path) یا مسیر ماژول قرار دهید. شما تنها می‌توانید یکی از این گزینه‌ها را مشخص کنید: اگر کدی را برای یک ماژول کامپایل نمی‌کنید، یا تنها کدی را برای یک ماژول واحد کامپایل می‌کنید، از مسیر منبع استفاده کنید؛ اگر کدی را برای چندین ماژول کامپایل می‌کنید، از مسیر منبع ماژول (module source path) استفاده نمایید. .IP \[bu] 2 از گزینهٔ \f[B]\f[VB]--source-path\f[B]\f[R] برای تعیین مکان‌های فایل‌های منبع اضافی که ممکن است توسط javac خوانده شوند استفاده کنید. مکان‌ها در مسیر منبع باید در یک \f[B]سلسله‌مراتب بسته‌ای\f[R] سازمان‌دهی شوند. همچنین می‌توانید از شکل دیگر این گزینه استفاده کنید: \f[V]-sourcepath\f[R]. .IP \[bu] 2 از گزینهٔ \f[B]\f[VB]--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[VB]-implicit\f[B]\f[R] استفاده کنید. .PP \f[B]نکته\f[R]: اگر کدی را برای چندین ماژول کامپایل می‌کنید، باید همیشه یک مسیر منبع ماژول را مشخص کنید، و تمام فایل‌های منبع مشخص‌شده در خط فرمان باید در یکی از دایرکتوری‌های موجود در مسیر منبع ماژول، یا در زیردایرکتوری‌های آن قرار داشته باشند..SS مثال کامپایل چندین فایل منبع .PP این مثال، فایل‌های منبع \f[V]Aloha.java\f[R]، \f[V]GutenTag.java\f[R]، \f[V]Hello.java\f[R] و \f[V]Hi.java\f[R] را در بستهٔ \f[V]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:\[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 \f[R] .fi .SS مثال مشخص کردن مسیر کلاس کاربر (User Class Path) .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:\[rs]>cd \[rs]examples C:\[rs]>javac greetings\[rs]Hi.java \f[R] .fi .PP از آن‌جا که \f[V]greetings.Hi\f[R] به کلاس‌های دیگر در بستهٔ \f[V]greetings\f[R] ارجاع می‌دهد، کامپایلر باید بتواند این کلاس‌های دیگر را پیدا کند. مثال قبلی به این دلیل کار می‌کند که مسیر پیش‌فرض کلاس کاربر، دایرکتوری‌ای است که دایرکتوری بسته را در بر دارد. اگر می‌خواهید این فایل را بدون نگرانی از این‌که در کدام دایرکتوری هستید مجدداً کامپایل کنید، دایرکتوری examples را با تنظیم \f[V]CLASSPATH\f[R] به مسیر کلاس کاربر اضافه کنید. این مثال از گزینهٔ \f[V]-classpath\f[R] استفاده می‌کند. .PP \f[B]لینوکس و macOS:\f[R] .RS .PP \f[V]javac -classpath /examples /examples/greetings/Hi.java\f[R] .RE .PP \f[B]ویندوز:\f[R] .RS .PP \f[V]C:\[rs]>javac -classpath \[rs]examples \[rs]examples\[rs]greetings\[rs]Hi.java\f[R] .RE .PP اگر \f[V]greetings.Hi\f[R] را طوری تغییر دهید که از یک ابزار banner استفاده کند، آن ابزار نیز باید از طریق مسیر کلاس کاربر در دسترس باشد. .PP \f[B]لینوکس و macOS:\f[R] .IP .nf \f[CB] javac -classpath /examples:/lib/Banners.jar \[rs] /examples/greetings/Hi.java \f[R] .fi .PP \f[B]ویندوز:\f[R] .IP .nf \f[CB] C:\[rs]>javac -classpath \[rs]examples;\[rs]lib\[rs]Banners.jar \[ha] \[rs]examples\[rs]greetings\[rs]Hi.java \f[R] .fi .PP برای اجرای یک کلاس در بستهٔ \f[V]greetings\f[R]، برنامه نیاز به دسترسی به بستهٔ \f[V]greetings\f[R] و همچنین کلاس‌هایی دارد که کلاس‌های \f[V]greetings\f[R] از آن‌ها استفاده می‌کنند. .PP \f[B]لینوکس و macOS:\f[R] .RS .PP \f[V]java -classpath /examples:/lib/Banners.jar greetings.Hi\f[R] .RE .PP \f[B]ویندوز:\f[R] .RS .PP \f[V]C:\[rs]>java -classpath \[rs]examples;\[rs]lib\[rs]Banners.jar greetings.Hi\f[R] .RE.SH "پیکربندی سامانه ماژول (CONFIGURING THE MODULE SYSTEM)" .PP اگر می‌خواهید ماژول‌های بیشتری را در کامپایل خود بگنجانید، از گزینهٔ \f[B]\f[VB]--add-modules\f[B]\f[R] استفاده کنید. این کار ممکن است زمانی لازم باشد که در حال کامپایل کدی هستید که درون یک ماژول قرار ندارد، یا در یک ماژول خودکار (automatic module) قرار دارد، و کد به API موجود در ماژول‌های دیگر ارجاع می‌دهد. .PP اگر می‌خواهید مجموعه ماژول‌ها را در کامپایل خود محدود کنید، از گزینهٔ \f[B]\f[VB]--limit-modules\f[B]\f[R] استفاده کنید. این کار زمانی می‌تواند مفید باشد که می‌خواهید اطمینان حاصل کنید کدی که کامپایل می‌کنید، قابلیت اجرا روی سیستمی با مجموعهٔ محدودی از ماژول‌های نصب‌شده را دارد. .PP اگر می‌خواهید کپسوله‌سازی را بشکنید و مشخص کنید که بسته‌های اضافی باید به عنوان بسته‌های صادرشده (exported) از یک ماژول در نظر گرفته شوند، از گزینهٔ \f[B]\f[VB]--add-exports\f[B]\f[R] استفاده کنید. این کار ممکن است هنگام انجام آزمون جعبه‌سفید (white-box testing) مفید باشد؛ اتکا به دسترسی به API داخلی در کد محصول نهایی (production) به شدت نهی می‌شود. .PP اگر می‌خواهید مشخص کنید که بسته‌های بیشتری باید به عنوان نیازمندی‌های یک ماژول در نظر گرفته شوند، از گزینهٔ \f[B]\f[VB]--add-reads\f[B]\f[R] استفاده کنید. این کار ممکن است هنگام انجام آزمون جعبه‌سفید مفید باشد؛ اتکا به دسترسی به API داخلی در کد محصول نهایی به شدت نهی می‌شود. .PP می‌توانید با استفاده از گزینهٔ \f[B]\f[VB]--patch-module\f[B]\f[R] محتوای اضافی را به هر ماژولی وصله (patch) کنید. برای جزئیات بیشتر به بخش [Patching a Module] مراجعه کنید. .SH "جستجو برای اعلان‌های ماژول، بسته و نوع (SEARCHING FOR MODULE, PACKAGE AND TYPE DECLARATIONS)" .PP برای کامپایل یک فایل منبع، کامپایلر اغلب به اطلاعاتی درباره یک ماژول یا نوع (type) نیاز دارد، در حالی که اعلان (declaration) آن در فایل‌های منبع مشخص‌شده در خط فرمان وجود ندارد. .PP دستور \f[V]javac\f[R] به اطلاعات نوع برای هر کلاس یا رابطی (interface) که در فایل منبع استفاده شده، گسترش یافته (extended) یا پیاده‌سازی شده (implemented) نیاز دارد. این شامل کلاس‌ها و رابط‌هایی که به صراحت در فایل منبع ذکر نشده‌اند، اما اطلاعات را از طریق توارث فراهم می‌کنند نیز می‌شود. .PP برای نمونه، هنگامی که یک زیرکلاس (subclass) از \f[V]java.awt.Window\f[R] می‌سازید، شما همچنین از کلاس‌های اجدادی \f[V]Window\f[R] استفاده می‌کنید: \f[V]java.awt.Container\f[R]، \f[V]java.awt.Component\f[R] و \f[V]java.lang.Object\f[R]. .PP هنگام کامپایل کد برای یک ماژول، کامپایلر همچنین نیاز دارد که اعلان آن ماژول در دسترس باشد. .PP یک جستجوی موفق ممکن است یک فایل کلاس، یک فایل منبع یا هر دو را تولید کند. اگر هر دو یافت شوند، می‌توانید از گزینهٔ \f[B]\f[VB]-Xprefer\f[B]\f[R] استفاده کنید تا به کامپایلر دستور دهید از کدام یک استفاده کند. .PP اگر یک جستجو فایل منبعی را بیابد و استفاده کند، آنگاه به طور پیش‌فرض \f[V]javac\f[R] آن فایل منبع را کامپایل می‌کند. این رفتار را می‌توان با \f[B]\f[VB]-implicit\f[B]\f[R] تغییر داد. .PP کامپایلر ممکن است تا پس از تکمیل پردازش حاشیه‌نویسی (annotation processing)، متوجه نیاز به برخی اطلاعات نوع نشود. هنگامی که اطلاعات نوع در یک فایل منبع یافت می‌شود و هیچ گزینهٔ \f[B]\f[VB]-implicit\f[B]\f[R] مشخص نشده باشد، کامپایلر هشداری صادر می‌کند مبنی بر اینکه فایل بدون قرار گرفتن تحت پردازش حاشیه‌نویسی در حال کامپایل شدن است. برای غیرفعال کردن هشدار، یا فایل را در خط فرمان مشخص کنید (تا مشمول پردازش حاشیه‌نویسی شود) یا از گزینهٔ \f[B]\f[VB]-implicit\f[B]\f[R] برای تعیین اینکه آیا فایل‌های کلاس برای چنین فایل‌های منبعی تولید شوند یا خیر، استفاده کنید. .PP روشی که \f[V]javac\f[R] اعلان‌های آن نوع‌ها را مکان‌یابی می‌کند بستگی به این دارد که آیا ارجاع درون کدِ یک ماژول قرار دارد یا خیر. .SS "جستجوی مسیرهای بسته‌محور (Searching Package Oriented Paths)" .PP هنگام جستجوی یک فایل منبع یا کلاس در مسیری متشکل از مکان‌های بسته‌محور، \f[V]javac\f[R] هر مکان در مسیر را به نوبت برای احتمال وجود فایل بررسی می‌کند. نخستین رخداد یک فایل خاص، هرگونه رخداد بعدی فایل‌های هم‌نام را سایه‌اندازی (پنهان) می‌کند. این سایه‌اندازی بر جستجو برای فایل‌هایی با نام متفاوت تأثیری ندارد. این ویژگی می‌تواند هنگام جستجوی فایل‌های منبع که ممکن است در مکان‌های متفاوتی گروه‌بندی شده باشند، مانند کد مشترک، کد وابسته به پلتفرم و کد تولیدشده، بسیار مناسب باشد. همچنین می‌تواند هنگام تزریق نسخه‌های جایگزین یک فایل کلاس به درون یک بسته، به منظور اشکال‌زدایی یا سایر دلایل ابزار دقیق، مفید باشد. اما این کار می‌تواند خطرناک نیز باشد؛ مانند زمانی که نسخه‌های متفاوت و ناسازگار یک کتابخانه در مسیر کلاس (class path) قرار داده شوند..SS جستجوی مسیرهای مبتنی بر ماژول .PP پیش از پویش هر یک از مسیرهای ماژول برای اعلان‌های بسته یا نوع، \f[V]javac\f[R] مسیرها و مکان‌های زیر را به‌طور تنبل (lazy) بررسی می‌کند تا ماژول‌هایی را که در کامپایل استفاده خواهند شد مشخص کند: .IP \[bu] 2 مسیر مبدأ ماژول (گزینهٔ \f[B]\f[VB]--module-source-path\f[B]\f[R] را ببینید) .IP \[bu] 2 مسیر ماژول‌های قابل ارتقا (گزینهٔ \f[B]\f[VB]--upgrade-module-path\f[B]\f[R] را ببینید) .IP \[bu] 2 ماژول‌های سیستم (گزینهٔ \f[B]\f[VB]--system\f[B]\f[R] را ببینید) .IP \[bu] 2 مسیر ماژول کاربر (گزینهٔ \f[B]\f[VB]--module-path\f[B]\f[R] را ببینید) .PP برای هر ماژول، نخستین رخداد ماژول در طول پویش، هرگونه پیدایش بعدیِ ماژولی با نام مشابه را کاملاً می‌پوشاند (پنهان می‌کند). در حین مکان‌یابی ماژول‌ها، \f[V]javac\f[R] قادر است بسته‌های صادرشده توسط ماژول را مشخص کند و به هر ماژول یک مسیر بسته‌محور متناظر با محتویات آن ماژول اختصاص دهد. برای هر ماژولی که پیش‌تر کامپایل شده است، این مسیر معمولاً یک مدخل واحد برای یک دایرکتوری یا فایلی خواهد بود که سلسله‌مراتبی درونی شبیه به دایرکتوری ارائه می‌دهد، مانند یک فایل JAR. بدین ترتیب، هنگام جستجو برای نوعی که در بسته‌ای قرار دارد که مشخص شده توسط یک ماژول صادر گردیده، \f[V]javac\f[R] می‌تواند اعلان آن را به‌طور مستقیم و کارآمد پیدا کند. .SS جستجو برای اعلان یک ماژول .PP اگر ماژول قبلاً کامپایل شده باشد، اعلان ماژول در فایلی با نام \f[V]module-info.class\f[R] در ریشهٔ سلسله‌مراتب بسته‌ها برای محتوای ماژول قرار دارد. .PP اگر ماژول یکی از مواردی باشد که هم‌اکنون در حال کامپایل هستند، اعلان ماژول یا فایلی با نام \f[V]module-info.class\f[R] در ریشهٔ سلسله‌مراتب بسته‌ها برای آن ماژول در دایرکتوری خروجی کلاس‌ها خواهد بود، یا فایلی با نام \f[V]module-info.java\f[R] در یکی از مکان‌های روی مسیر مبدأ یا روی مسیر مبدأ ماژول برای آن ماژول. .SS جستجو برای اعلان یک نوع در صورتی که ارجاع درون یک ماژول نباشد .PP هنگام جستجو برای نوعی که در کدی خارج از یک ماژول به آن ارجاع داده شده است، \f[V]javac\f[R] مکان‌های زیر را بررسی خواهد کرد: .IP \[bu] 2 کلاس‌های پلتفرم (یا انواع موجود در بسته‌های صادرشدهٔ ماژول‌های پلتفرم) (این مورد تنها برای فایل‌های کلاس کامپایل‌شده است.) .IP \[bu] 2 انواع موجود در بسته‌های صادرشدهٔ هر یک از ماژول‌های موجود در مسیر ماژول، در صورت وجود. (این مورد تنها برای فایل‌های کلاس کامپایل‌شده است.) .IP \[bu] 2 انواع موجود در بسته‌های روی مسیر کلاس (class path) و/یا مسیر مبدأ (source path): .RS 2 .IP \[bu] 2 اگر هر دو مشخص شده باشند، \f[V]javac\f[R] در مسیر کلاس به دنبال فایل‌های کلاس کامپایل‌شده و در مسیر مبدأ به دنبال فایل‌های مبدأ می‌گردد. .IP \[bu] 2 اگر مسیر کلاس مشخص شده باشد اما مسیر مبدأ مشخص نشده باشد، \f[V]javac\f[R] هم به دنبال فایل‌های کلاس کامپایل‌شده و هم به دنبال فایل‌های مبدأ در مسیر کلاس می‌گردد. .IP \[bu] 2 اگر مسیر کلاس مشخص نشده باشد، مقدار پیش‌فرض آن دایرکتوری جاری خواهد بود. .RE .PP هنگام جستجوی یک نوع در مسیر کلاس و/یا مسیر مبدأ، چنانچه هم فایل کلاس کامپایل‌شده و هم فایل مبدأ پیدا شوند، به‌طور پیش‌فرض فایلی که اخیراً تغییر یافته استفاده خواهد شد. اگر فایل مبدأ جدیدتر باشد، کامپایل خواهد شد و ممکن است جایگزین هر نسخهٔ از پیش کامپایل‌شدهٔ آن فایل شود. می‌توانید از گزینهٔ \f[B]\f[VB]-Xprefer\f[B]\f[R] برای تغییر این رفتار پیش‌فرض استفاده کنید. .SS جستجو برای اعلان یک نوع در صورتی که ارجاع درون یک ماژول باشد .PP هنگام جستجو برای نوعی که در کدی درون یک ماژول به آن ارجاع داده شده است، \f[V]javac\f[R] اعلان ماژول دربرگیرنده را بررسی می‌کند تا مشخص شود آیا آن نوع در بسته‌ای قرار دارد که از ماژول دیگری صادر شده و توسط ماژول دربرگیرنده قابل خواندن است یا خیر. اگر چنین باشد، \f[V]javac\f[R] ساده و مستقیم به تعریف آن ماژول می‌رود تا تعریف نوع مورد نیاز را بیابد. مگر در حالتی که ماژول، یکی دیگر از ماژول‌های در حال کامپایل باشد، \f[V]javac\f[R] تنها به دنبال فایل‌های کلاس کامپایل‌شده خواهد گشت. به عبارت دیگر، \f[V]javac\f[R] در ماژول‌های پلتفرم یا ماژول‌های موجود در مسیر ماژول، به دنبال فایل‌های مبدأ نخواهد گشت. .PP چنانچه نوع مورد ارجاع در ماژول خواندنی دیگری نباشد، \f[V]javac\f[R] ماژول در حال کامپایل را بررسی می‌کند تا برای یافتن اعلان آن نوع تلاش کند. \f[V]javac\f[R] اعلان آن نوع را به شرح زیر جستجو خواهد کرد: .IP \[bu] 2 فایل‌های مبدأ مشخص‌شده در خط فرمان یا در مسیر مبدأ یا مسیر مبدأ ماژول. .IP \[bu] 2 فایل‌های پیش‌تر کامپایل‌شده در دایرکتوری خروجی..SH "سلسله‌مراتب‌های دایرکتوری (DIRECTORY HIERARCHIES)" .PP \f[V]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[V]javac\f[R] درباره سازمان‌دهی کد مبدأ انعطاف‌پذیری نسبتاً بالایی دارد (فراتر از این انتظار که مبدأ در یک یا چند سلسله‌مراتب بسته سازمان‌دهی شود) و عموماً می‌تواند با ساختارهای تعیین‌شده توسط محیط‌های توسعه و ابزارهای ساخت سازگار شود، ابزارهای Java به‌طور کلی، و به‌ویژه \f[V]javac\f[R] و اجراکننده Java، در رابطه با سازمان‌دهی فایل‌های کلاس کامپایل‌شده سخت‌گیرانه‌تر هستند و این فایل‌ها بسته به شرایط، باید در سلسله‌مراتب‌های بسته یا سلسله‌مراتب‌های ماژول سازمان‌دهی شوند. .PP مکان این سلسله‌مراتب‌ها از طریق گزینه‌های خط فرمان به \f[V]javac\f[R] مشخص می‌شود، گزینه‌هایی که نام آن‌ها معمولاً به \[dq]path\[dq] ختم می‌شود؛ مانند \f[B]\f[VB]--source-path\f[B]\f[R] یا \f[B]\f[VB]--class-path\f[B]\f[R]. همچنین به‌عنوان یک قاعده کلی، گزینه‌های مسیری که نام آن‌ها شامل کلمه \f[V]module\f[R] است، مانند \f[B]\f[VB]--module-path\f[B]\f[R]، برای مشخص کردن سلسله‌مراتب‌های ماژول به کار می‌روند؛ اگرچه برخی گزینه‌های مسیر مربوط به ماژول اجازه می‌دهند که یک سلسله‌مراتب بسته بر پایه هر ماژول مشخص شود. سایر گزینه‌های مسیر برای تعیین سلسله‌مراتب‌های بسته به کار می‌روند. .SS "سلسله‌مراتب بسته (Package Hierarchy)" .PP در یک سلسله‌مراتب بسته، دایرکتوری‌ها و زیردایرکتوری‌ها برای نشان دادن بخش‌های تشکیل‌دهندهٔ نام بسته استفاده می‌شوند، به‌طوری که فایل مبدأ یا فایل کلاس کامپایل‌شده برای یک نوع (type) به‌عنوان فایلی با پسوند \f[V].java\f[R] یا \f[V].class\f[R] در درونی‌ترین دایرکتوری ذخیره می‌شود. .PP برای نمونه، در یک سلسله‌مراتب بسته، فایل مبدأ برای کلاسی به نام \f[V]com.example.MyClass\f[R] در فایل \f[I]com/example/MyClass.java\f[R] ذخیره خواهد شد. .SS "سلسله‌مراتب ماژول (Module Hierarchy)" .PP در یک سلسله‌مراتب ماژول، دایرکتوری‌های سطح اول بر اساس ماژول‌های موجود در سلسله‌مراتب نام‌گذاری می‌شوند؛ در داخل هر یک از آن دایرکتوری‌ها، محتویات ماژول در سلسله‌مراتب‌های بسته سازمان‌دهی می‌شوند. .PP برای نمونه، در یک سلسله‌مراتب ماژول، فایل کلاس کامپایل‌شده برای نوعی به نام \f[V]com.example.MyClass\f[R] در ماژولی به نام \f[V]my.library\f[R]، در مسیر \f[I]my.library/com/example/MyClass.class\f[R] ذخیره خواهد شد. .PP دایرکتوری‌های خروجی گوناگون استفاده‌شده توسط \f[V]javac\f[R] (دایرکتوری خروجی کلاس، دایرکتوری خروجی مبدأ، و دایرکتوری خروجی سرآیند بومی) هنگامی که چندین ماژول در حال کامپایل باشند، همگی در یک سلسله‌مراتب ماژول سازمان‌دهی خواهند شد. .SS "سلسله‌مراتب مبدأ ماژول (Module Source Hierarchy)" .PP اگرچه مبدأ هر ماژول مجزا همیشه باید در یک سلسله‌مراتب بسته سازمان‌دهی شود، ممکن است گروه‌بندی این سلسله‌مراتب‌ها در یک سلسله‌مراتب مبدأ ماژول راحت‌تر باشد. این ساختار شبیه به یک سلسله‌مراتب ماژول است، با این تفاوت که ممکن است دایرکتوری‌های واسطی بین دایرکتوری ماژول و دایرکتوری ریشهٔ سلسله‌مراتب بسته برای کد مبدأ آن ماژول وجود داشته باشد. .PP برای نمونه، در یک سلسله‌مراتب مبدأ ماژول، فایل مبدأ برای نوعی به نام \f[V]com.example.MyClass\f[R] در ماژولی به نام \f[V]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[VB]--module-source-path\f[B]\f[R] دارای دو فرم است: یک \f[I]فرم مخصوص هر ماژول\f[R]، که در آن یک مسیر بسته برای هر ماژول حاوی کد جهت کامپایل مشخص می‌شود؛ و یک فرم \f[I]الگوی ماژول\f[R]، که در آن مسیر مبدأ برای هر ماژول توسط یک الگو تعیین می‌شود. فرم مخصوص هر ماژول عموماً زمانی که تنها تعداد کمی ماژول دخیل هستند برای استفاده ساده‌تر است؛ فرم الگوی ماژول زمانی می‌تواند مناسب‌تر باشد که تعداد ماژول‌ها زیاد بوده و ماژول‌ها به شیوه‌ای منظم سازمان‌دهی شده باشند که بتوان آن را با یک الگو توصیف کرد. .PP می‌توان چندین نمونه از گزینه \f[V]--module-source-path\f[R] را مشخص کرد، که هر کدام یا از فرم الگوی ماژول یا از فرم مخصوص هر ماژول استفاده می‌کنند، با رعایت محدودیت‌های زیر: .IP \[bu] 2 فرم الگوی ماژول حداکثر یک بار می‌تواند استفاده شود .IP \[bu] 2 فرم مخصوص هر ماژول برای هر ماژول معین حداکثر یک بار می‌تواند استفاده شود .PP اگر از فرم مخصوص هر ماژول برای هر ماژولی استفاده شود، مسیر جستجوی مربوطه جایگزین هر مسیری می‌شود که ممکن بود در غیر این صورت از فرم الگوی ماژول استنباط شود..SS "شکل مختص ماژول (Module-specific form)" .PP شکل مختص ماژول اجازه می‌دهد تا یک مسیر جستجوی صریح برای هر ماژول مشخص تعیین شود. این شکل به صورت زیر است: .IP \[bu] 2 \f[V]--module-source-path\f[R] \f[I]module-name\f[R]\f[V]=\f[R]\f[I]file-path\f[R] (\f[I]path-separator\f[R] \f[I]file-path\f[R])* .PP نویسهٔ جداکنندهٔ مسیر در Windows برابر با \f[V];\f[R] و در غیر این صورت \f[V]:\f[R] است. .PP \f[B]نکته:\f[R] این شکل مشابه با شکل مورد استفاده برای گزینهٔ \f[B]\f[VB]--patch-module\f[B]\f[R] است. .SS "شکل الگوی ماژول (Module-pattern form)" .PP شکل الگوی ماژول امکان تعیین مختصر مسیر منبع ماژول را برای هر تعداد ماژول که به شکلی منظم سازمان‌دهی شده‌اند، فراهم می‌کند. .IP \[bu] 2 \f[V]--module-source-path\f[R] \f[I]pattern\f[R] .PP الگو با قواعد زیر تعریف می‌شود که به ترتیب اعمال می‌گردند: .IP \[bu] 2 آرگومان به عنوان مجموعه‌ای از بخش‌ها در نظر گرفته می‌شود که توسط نویسهٔ جداکنندهٔ مسیر (\f[V];\f[R] در Windows و در غیر این صورت \f[V]:\f[R]) از یکدیگر جدا شده‌اند. .IP \[bu] 2 هر بخشی که شامل آکولادهایی به شکل زیر باشد .RS 2 .IP .nf \f[CB] string1{alt1 ( ,alt2 )* } string2 \f[R] .fi .PP جایگزین‌شده با مجموعه‌ای از بخش‌ها در نظر گرفته می‌شود که با \[dq]بسط دادن\[dq] آکولادها تشکیل شده‌اند: .IP .nf \f[CB] string1 alt1 string2 string1 alt2 string2 and so on... \f[R] .fi .PP آکولادها می‌توانند تودرتو باشند. .PP این قاعده برای تمام چنین کاربردهایی از آکولاد اعمال می‌شود. .RE .IP \[bu] 2 هر بخش باید حداکثر شامل یک ستاره (\f[V]*\f[R]) باشد. اگر بخشی فاقد ستاره باشد، به گونه‌ای در نظر گرفته می‌شود که گویی نویسهٔ جداکنندهٔ فایل و یک ستاره به انتهای آن الحاق شده است. .RS 2 .PP برای هر ماژول \f[I]M\f[R]، مسیر منبع آن ماژول از مجموعه‌ای از بخش‌ها تشکیل می‌شود که با جایگزین کردن نام ماژول \f[I]M\f[R] به جای ستاره در هر بخش حاصل می‌آیند. .PP \f[B]نکته\f[R]: در این زمینه، ستاره صرفاً به عنوان یک نشانگر ویژه برای مشخص کردن موقعیت نام ماژول در مسیر استفاده شده است. نباید آن را با کاربرد \f[V]*\f[R] به عنوان نویسهٔ عام (wildcard) نام فایل، آن‌گونه که در بیشتر سیستم‌عامل‌ها وجود دارد، اشتباه گرفت. .RE .SH "وصله‌کردن ماژول‌ها (PATCHING MODULES)" .PP دستور javac اجازه می‌دهد هر محتوایی، چه در قالب کد منبع و چه به صورت کامپایل‌شده، با استفاده از گزینهٔ \f[B]\f[VB]--patch-module\f[B]\f[R] به هر ماژولی وصله شود. ممکن است بخواهید این کار را برای کامپایل پیاده‌سازی‌های جایگزین یک کلاس انجام دهید تا در زمان اجرا به یک JVM وصله شود، یا برای تزریق کلاس‌های اضافی به ماژول، مانند هنگام آزمایش (تست). .PP شکل این گزینه عبارت است از: .IP \[bu] 2 \f[V]--patch-module\f[R] \f[I]module-name\f[R]\f[V]=\f[R]\f[I]file-path\f[R] (\f[I]path-separator\f[R] \f[I]file-path\f[R] )* .PP نویسهٔ جداکنندهٔ مسیر در Windows برابر با \f[V];\f[R] و در غیر این صورت \f[V]:\f[R] است. مسیرهای ارائه‌شده برای ماژول باید ریشهٔ یک سلسله‌مراتب بسته‌ای (package hierarchy) را برای محتویات ماژول مشخص کنند. .PP این گزینه حداکثر یک‌بار برای هر ماژول مشخص قابل ارائه است. هر محتوایی در مسیر، هر محتوای هم‌نام دیگری را که در ادامه مسیر یا در ماژول وصله‌شده قرار دارد، پنهان خواهد کرد. .PP هنگام وصله‌کردن کد منبع به بیش از یک ماژول، گزینهٔ \f[B]\f[VB]--module-source-path\f[B]\f[R] نیز باید استفاده شود تا دایرکتوری خروجی در یک سلسله‌مراتب ماژولی سازمان‌دهی شده و توانایی نگهداری فایل‌های کلاس کامپایل‌شده را برای ماژول‌های در حال کامپایل داشته باشد..SH "پردازش حاشیه‌نویسی (ANNOTATION PROCESSING)" .PP دستور \f[V]javac\f[R] پشتیبانی مستقیمی را برای پردازش حاشیه‌نویسی فراهم می‌کند. .PP رابط برنامه‌نویسی نرم‌افزار (API) برای پردازنده‌های حاشیه‌نویسی در بسته‌ها و زیربسته‌های \f[V]javax.annotation.processing\f[R] و \f[V]javax.lang.model\f[R] تعریف شده است. .SS "نحوه کارکرد پردازش حاشیه‌نویسی" .PP مگر در حالتی که پردازش حاشیه‌نویسی با گزینه \f[B]\f[VB]-proc:none\f[B]\f[R] غیرفعال شده باشد، کامپایلر به جستجوی تمامی پردازنده‌های حاشیه‌نویسی در دسترس می‌پردازد. مسیر جستجو را می‌توان با گزینه \f[B]\f[VB]-processorpath\f[B]\f[R] مشخص کرد. اگر مسیری مشخص نشده باشد، از مسیر کلاس کاربر (user class path) استفاده می‌شود. پردازنده‌ها با استفاده از فایل‌های پیکربندی ارائه‌دهنده سرویس با نام \f[V]META-INF/services/javax.annotation.processing.Processor\f[R] در مسیر جستجو شناسایی می‌شوند. این فایل‌ها باید حاوی نام پردازنده‌های حاشیه‌نویسی مورد استفاده باشند که در هر خط یک مورد درج شده است. همچنین، پردازنده‌ها را می‌توان به‌طور صریح با استفاده از گزینه \f[B]\f[VB]-processor\f[B]\f[R] مشخص کرد. .PP پس از پیمایش فایل‌های منبع و کلاس‌ها در خط فرمان برای تعیین اینکه چه حاشیه‌نویسی‌هایی وجود دارند، کامپایلر از پردازنده‌ها پرس‌وجو می‌کند تا مشخص شود چه حاشیه‌نویسی‌هایی را پردازش می‌کنند. هنگامی که تطابقی یافت شود، پردازنده فراخوانی می‌شود. یک پردازنده می‌تواند حاشیه‌نویسی‌هایی را که پردازش می‌کند تصاحب نماید؛ در این صورت هیچ تلاش دیگری برای یافتن پردازنده برای آن حاشیه‌نویسی‌ها صورت نخواهد گرفت. پس از تصاحب تمامی حاشیه‌نویسی‌ها، کامپایلر برای پردازنده‌های اضافی جستجو نخواهد کرد. .PP اگر پردازنده‌ای فایل‌های منبع جدیدی تولید کند، دور دیگری از پردازش حاشیه‌نویسی رخ می‌دهد: هر فایل منبع تازه تولیدشده پیمایش می‌شود و حاشیه‌نویسی‌های آن همانند گذشته پردازش می‌گردند. هر پردازنده‌ای که در دورهای پیشین فراخوانی شده باشد، در تمام دورهای پس از آن نیز فراخوانی می‌شود. این روند تا زمانی که هیچ فایل منبع جدیدی تولید نشود ادامه می‌یابد. .PP پس از رخ دادن دوری که در آن هیچ فایل منبع جدیدی تولید نشود، پردازنده‌های حاشیه‌نویسی برای آخرین بار فراخوانی می‌شوند تا فرصتی برای تکمیل کارهای باقیمانده به آن‌ها داده شود. در نهایت، مگر در حالتی که گزینه \f[B]\f[VB]-proc:only\f[B]\f[R] استفاده شده باشد، کامپایلر فایل‌های منبع اولیه و تمامی فایل‌های منبع تولیدشده را کامپایل می‌کند. .PP اگر از پردازنده حاشیه‌نویسی استفاده می‌کنید که فایل‌های منبع دیگری را برای گنجانده شدن در فرایند کامپایل تولید می‌کند، می‌توانید یک ماژول پیش‌فرض برای استفاده در فایل‌های تازه تولیدشده مشخص کنید، تا هنگامی که اعلان ماژول تولید نشده باشد مورد استفاده قرار گیرد. در این حالت، از گزینه \f[B]\f[VB]--default-module-for-created-files\f[B]\f[R] استفاده کنید. .SS "محیط کامپایل و محیط زمان اجرا" .PP اعلان‌ها در فایل‌های منبع و فایل‌های کلاس از پیش کامپایل‌شده، توسط \f[V]javac\f[R] در یک \f[I]محیط کامپایل\f[R] بررسی می‌شوند که از \f[I]محیط زمان اجرا\f[R] مورد استفاده برای اجرای خود \f[V]javac\f[R] مجزا است. اگرچه شباهتی تعمدی میان بسیاری از گزینه‌های \f[V]javac\f[R] و گزینه‌های هم‌نام در \f[B]launcher\f[R] جاوا وجود دارد (مانند \f[V]--class-path\f[R]، \f[V]--module-path\f[R] و غیره)، اما درک این نکته اهمیت دارد که به‌طور کلی گزینه‌های \f[V]javac\f[R] صرفاً بر محیطی که فایل‌های منبع در آن کامپایل می‌شوند اثر می‌گذارند و عملکرد خود \f[V]javac\f[R] را تحت تأثیر قرار نمی‌دهند. .PP تمایز میان محیط کامپایل و محیط زمان اجرا در هنگام استفاده از پردازنده‌های حاشیه‌نویسی بسیار چشمگیر است. اگرچه پردازنده‌های حاشیه‌نویسی عناصری (اعلان‌ها) را پردازش می‌کنند که در محیط کامپایل قرار دارند، اما خود پردازنده حاشیه‌نویسی در محیط زمان اجرا به اجرا درمی‌آید. اگر یک پردازنده حاشیه‌نویسی به کتابخانه‌هایی وابسته باشد که در قالب ماژول نیستند، می‌توان آن کتابخانه‌ها را در کنار خود پردازنده حاشیه‌نویسی در مسیر پردازنده قرار داد. (گزینه \f[B]\f[VB]--processor-path\f[B]\f[R] را ببینید.) اگر پردازنده حاشیه‌نویسی و وابستگی‌های آن در قالب ماژول باشند، باید به‌جای آن از مسیر ماژول پردازنده استفاده کنید. (گزینه \f[B]\f[VB]--processor-module-path\f[B]\f[R] را ببینید.) هنگامی که این موارد ناکافی باشند، ممکن است نیاز به انجام پیکربندی‌های بیشتری بر روی محیط زمان اجرا باشد. این کار می‌تواند به دو روش انجام گیرد: .IP "1." 3 اگر \f[V]javac\f[R] از طریق خط فرمان فراخوانی شود، می‌توان با افزودن پیشوند \f[B]\f[VB]-J\f[B]\f[R] به گزینه، آن را به زمان اجرای زیربنایی منتقل کرد. .IP "2." 3 می‌توان مستقیماً یک نمونه از Java Virtual Machine را راه‌اندازی کرد و با استفاده از گزینه‌های خط فرمان و API، محیطی را پیکربندی نمود که در آن بتوان \f[V]javac\f[R] را از طریق یکی از \f[B]APIs\f[R] آن فراخوانی کرد..SH "کامپایل برای نسخه‌های پیشین پلتفرم (COMPILING FOR EARLIER RELEASES OF THE PLATFORM)" .PP \f[V]javac\f[R] می‌تواند کدی را که قرار است در سایر نسخه‌های پلتفرم استفاده شود، با استفاده از گزینهٔ \f[B]\f[VB]--release\f[B]\f[R]، یا گزینه‌های \f[B]\f[VB]--source\f[B]\f[R]/\f[V]-source\f[R] و \f[B]\f[VB]--target\f[B]\f[R]/\f[V]-target\f[R]، به همراه گزینه‌های اضافی برای تعیین کلاس‌های پلتفرم کامپایل کند. .PP بسته به نسخهٔ پلتفرم مورد نظر، محدودیت‌هایی در استفاده از برخی گزینه‌ها وجود دارد. .IP \[bu] 2 هنگام کامپایل برای JDK 8 و نسخه‌های پیشین، نمی‌توانید از هیچ گزینه‌ای که برای استفاده با سامانهٔ ماژول در نظر گرفته شده است استفاده کنید. این شامل تمام گزینه‌های زیر است: .RS 2 .IP \[bu] 2 \f[B]\f[VB]--module-source-path\f[B]\f[R]، \f[B]\f[VB]--upgrade-module-path\f[B]\f[R]، \f[B]\f[VB]--system\f[B]\f[R]، \f[B]\f[VB]--module-path\f[B]\f[R]، \f[B]\f[VB]--add-modules\f[B]\f[R]، \f[B]\f[VB]--add-exports\f[B]\f[R]، \f[V]--add-opens\f[R]، \f[B]\f[VB]--add-reads\f[B]\f[R]، \f[B]\f[VB]--limit-modules\f[B]\f[R]، \f[B]\f[VB]--patch-module\f[B]\f[R] .PP اگر از گزینه‌های \f[V]--source\f[R]/\f[V]-source\f[R] یا \f[V]--target\f[R]/\f[V]-target\f[R] استفاده می‌کنید، باید کلاس‌های مناسب پلتفرم را نیز با استفاده از خانوادهٔ گزینه‌های boot class path تنظیم نمایید. .RE .IP \[bu] 2 هنگام کامپایل برای JDK 9 و نسخه‌های پس از آن، نمی‌توانید از هیچ گزینه‌ای که برای پیکربندی boot class path در نظر گرفته شده است استفاده کنید. این شامل تمام گزینه‌های زیر است: .RS 2 .IP \[bu] 2 \f[B]\f[VB]-Xbootclasspath/p:\f[B]\f[R]، \f[B]\f[VB]-Xbootclasspath\f[B]\f[R]، \f[B]\f[VB]-Xbootclasspath/a:\f[B]\f[R]، \f[B]\f[VB]-endorseddirs\f[B]\f[R]، \f[B]\f[VB]-Djava.endorsed.dirs\f[B]\f[R]، \f[B]\f[VB]-extdirs\f[B]\f[R]، \f[B]\f[VB]-Djava.ext.dirs\f[B]\f[R]، \f[B]\f[VB]-profile\f[B]\f[R] .PP اگر از گزینه‌های \f[V]--source\f[R]/\f[V]-source\f[R] یا \f[V]--target\f[R]/\f[V]-target\f[R] استفاده می‌کنید، باید کلاس‌های مناسب پلتفرم را نیز با استفاده از گزینهٔ \f[V]--system\f[R] برای مشخص کردن مکان یک نسخهٔ نصب‌شدهٔ مناسب از JDK تنظیم نمایید. .RE .PP هنگام استفاده از گزینهٔ \f[V]--release\f[R]، تنها APIهای مستند و پشتیبانی‌شده برای آن نسخه قابل استفاده هستند؛ شما نمی‌توانید از هیچ گزینه‌ای برای شکستن کپسوله‌سازی جهت دسترسی به کلاس‌های داخلی استفاده کنید. .SH "رابط‌های برنامه‌نویسی (APIS)" .PP کامپایلر \f[V]javac\f[R] را می‌توان با استفاده از یک API به سه روش مختلف فراخوانی کرد: .TP \f[B]Java Compiler API\f[R] این روش منعطف‌ترین راه را برای فراخوانی کامپایلر فراهم می‌کند، از جمله امکان کامپایل فایل‌های منبع ارائه‌شده در بافرهای حافظه یا سایر سیستم‌های فایل غیر استاندارد. .TP \f[B]ToolProvider API\f[R] یک \f[V]ToolProvider\f[R] برای \f[V]javac\f[R] را می‌توان با فراخوانی \f[V]ToolProvider.findFirst(\[dq]javac\[dq])\f[R] به دست آورد. این فراخوانی شیئی با قابلیت‌های معادل ابزار خط فرمان برمی‌گرداند. .RS .PP \f[B]نکته\f[R]: این API نباید با API هم‌نام در بستهٔ \f[B]\f[VB]javax.tools\f[B]\f[R] اشتباه گرفته شود. .RE .TP \f[V]javac\f[R] \f[B]Legacy API\f[R] این API صرفاً برای سازگاری عقبرو حفظ شده است. تمام کدهای جدید باید از Java Compiler API یا ToolProvider API استفاده کنند. .PP \f[B]نکته:\f[R] تمام کلاس‌ها و متدهای دیگر موجود در بسته‌هایی با نام‌هایی که با \f[V]com.sun.tools.javac\f[R] شروع می‌شوند (زیربسته‌های \f[V]com.sun.tools.javac\f[R]) کاملاً داخلی بوده و در هر زمانی ممکن است تغییر کنند..SH "مثال‌هایی از استفاده از کلیدهای -XLINT (EXAMPLES OF USING -XLINT KEYS)" .TP \f[V]cast\f[R] درباره تبدیل نوع‌های (cast) غیرضروری و زائد هشدار می‌دهد، برای نمونه: .RS .RS .PP \f[V]String s = (String) \[dq]Hello!\[dq]\f[R] .RE .RE .TP \f[V]classfile\f[R] درباره مسائل مربوط به محتوای فایل‌های کلاس (class file) هشدار می‌دهد. .TP \f[V]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[V]java.util.Date.getDay\f[R] از زمان JDK 1.1 منسوخ شده است. .RE .TP \f[V]dep-ann\f[R] درباره مواردی که با توضیح جاواداک \f[V]\[at]deprecated\f[R] مستند شده‌اند، اما یادداشت (annotation) \f[V]\[at]Deprecated\f[R] را ندارند هشدار می‌دهد، برای نمونه: .RS .IP .nf \f[CB] /** * \[at]deprecated As of Java SE 7, replaced by {\[at]link #newMethod()} */ public static void deprecatedMethod() { } public static void newMethod() { } \f[R] .fi .RE .TP \f[V]divzero\f[R] درباره تقسیم بر عدد صحیح ثابت 0 هشدار می‌دهد، برای نمونه: .RS .RS .PP \f[V]int divideByZero = 42 / 0;\f[R] .RE .RE .TP \f[V]empty\f[R] درباره دستورهای خالی پس از عبارت‌های \f[V]if\f[R] هشدار می‌دهد، برای نمونه: .RS .IP .nf \f[CB] class E { void m() { if (true) ; } } \f[R] .fi .RE .TP \f[V]fallthrough\f[R] بلوک‌های switch را برای یافتن موارد گذر (fall-through cases) بررسی کرده و برای هر مورد یافت‌شده یک پیام هشدار صادر می‌کند. موارد گذر، مواردی در یک بلوک switch (به جز آخرین مورد در بلوک) هستند که کد آن‌ها شامل دستور \f[V]break\f[R] نیست، که اجازه می‌دهد اجرای کد از آن مورد به مورد بعدی سرازیر (fall through) شود. برای نمونه، کد پس از برچسب case 1 در این بلوک switch به یک دستور \f[V]break\f[R] ختم نمی‌شود: .RS .IP .nf \f[CB] switch (x) { case 1: System.out.println(\[dq]1\[dq]); // No break statement here. case 2: System.out.println(\[dq]2\[dq]); } \f[R] .fi .PP اگر هنگام کامپایل این کد از گزینه \f[V]-Xlint:fallthrough\f[R] استفاده شده باشد، کامپایلر هشداری درباره احتمال سرازیر شدن به case بعدی، همراه با شماره خط case مورد نظر صادر می‌کند. .RE .TP \f[V]finally\f[R] درباره بندهای \f[V]finally\f[R] که نمی‌توانند به‌طور عادی خاتمه یابند هشدار می‌دهد، برای نمونه: .RS .IP .nf \f[CB] public static int m() { try { throw new NullPointerException(); } catch (NullPointerException(); { System.err.println(\[dq]Caught NullPointerException.\[dq]); return 1; } finally { return 0; } } \f[R] .fi .PP کامپایلر برای بلوک \f[V]finally\f[R] در این مثال هشداری تولید می‌کند. هنگامی که این متد \f[V]int\f[R] فراخوانی می‌شود، مقدار 0 را برمی‌گرداند. یک بلوک \f[V]finally\f[R] زمانی اجرا می‌شود که بلوک \f[V]try\f[R] خارج شود. در این مثال، هنگامی که کنترل به بلوک \f[V]catch\f[R] منتقل می‌شود، متد \f[V]int\f[R] خارج می‌شود. با این وجود، بلوک \f[V]finally\f[R] باید اجرا شود، بنابراین اجرا می‌شود، حتی اگر کنترل به خارج از متد منتقل شده باشد. .RE .TP \f[V]options\f[R] درباره مسائل مربوط به استفاده از گزینه‌های خط فرمان هشدار می‌دهد. بخش \f[B]Compiling for Earlier Releases of the Platform\f[R] را ببینید. .TP \f[V]overrides\f[R] درباره مسائل مربوط به بازنویسی متدها (method overrides) هشدار می‌دهد. برای نمونه، دو کلاس زیر را در نظر بگیرید: .RS .IP .nf \f[CB] public class ClassWithVarargsMethod { void varargsMethod(String... s) { } } public class ClassWithOverridingMethod extends ClassWithVarargsMethod { \[at]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[V]varargs\f[R] مواجه می‌شود، پارامتر رسمی \f[V]varargs\f[R] را به یک آرایه تبدیل می‌کند. در متد \f[V]ClassWithVarargsMethod.varargsMethod\f[R]، کامپایلر پارامتر رسمی \f[V]varargs\f[R] یعنی \f[V]String... s\f[R] را به پارامتر رسمی \f[V]String[] s\f[R] ترجمه می‌کند؛ آرایه‌ای که با پارامتر رسمی متد \f[V]ClassWithOverridingMethod.varargsMethod\f[R] مطابقت دارد. در نتیجه، این مثال کامپایل می‌شود. .RE .TP \f[V]path\f[R] درباره عناصر نامعتبر مسیر و دایرکتوری‌های ناموجود مسیر در خط فرمان (با توجه به class path، source path و سایر مسیرها) هشدار می‌دهد. چنین هشدارهایی را نمی‌توان با یادداشت \f[V]\[at]SuppressWarnings\f[R] نادیده گرفت. برای نمونه: .RS .IP \[bu] 2 \f[B]لینوکس و macOS:\f[R] \f[V]javac -Xlint:path -classpath /nonexistentpath Example.java\f[R].IP \[bu] 2 \f[B]ویندوز:\f[R] \f[V]javac -Xlint:path -classpath C:\[rs]nonexistentpath Example.java\f[R] .RE .TP \f[V]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.*; \[at]SupportedAnnotationTypes(\[dq]NotAnno\[dq]) public class AnnoProc extends AbstractProcessor { public boolean process(Set 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] \[at]interface Anno { } \[at]Anno class AnnosWithoutProcessors { } \f[R] .fi .PP دستورهای زیر پردازشگر حاشیه‌نویسی \f[V]AnnoProc\f[R] را کامپایل کرده و سپس این پردازشگر حاشیه‌نویسی را روی فایل منبع \f[V]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[V]AnnosWithoutProcessors.java\f[R] اجرا می‌کند، هشدار زیر را صادر می‌کند: .IP .nf \f[CB] warning: [processing] No processor claimed any of these annotations: Anno \f[R] .fi .PP برای رفع این مشکل، می‌توانید حاشیه‌نویسی تعریف‌شده و استفاده‌شده در کلاس \f[V]AnnosWithoutProcessors\f[R] را از \f[V]Anno\f[R] به \f[V]NotAnno\f[R] تغییر نام دهید. .RE .TP \f[V]rawtypes\f[R] درباره عملیات‌های بررسی‌نشده روی نوع‌های خام (raw types) هشدار می‌دهد. عبارت زیر یک هشدار \f[V]rawtypes\f[R] ایجاد می‌کند: .RS .RS .PP \f[V]void countElements(List l) { ... }\f[R] .RE .PP مثال زیر یک هشدار \f[V]rawtypes\f[R] ایجاد نمی‌کند: .RS .PP \f[V]void countElements(List l) { ... }\f[R] .RE .PP نوع \f[V]List\f[R] یک نوع خام است. با این حال، \f[V]List\f[R] یک نوع پارامتری‌شده با نویسه عام نامحدود (unbounded wildcard) است. از آنجا که \f[V]List\f[R] یک رابط (interface) پارامتری‌شده است، همواره آرگومان نوع آن را مشخص کنید. در این مثال، آرگومان صوری \f[V]List\f[R] با یک نویسه عام نامحدود (\f[V]?\f[R]) به عنوان پارامتر نوع صوری آن مشخص شده است، به این معنی که متد \f[V]countElements\f[R] می‌تواند هرگونه نمونه‌سازی از رابط \f[V]List\f[R] را بپذیرد. .RE .TP \f[V]serial\f[R] درباره تعریف‌نشدن \f[V]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[V]serialVersionUID\f[R] را به طور صریح اعلان نکند، محیط زمان اجرای سریال‌سازی بر اساس جنبه‌های مختلف کلاس، همان‌طور که در Java Object Serialization Specification شرح داده شده است، یک مقدار پیش‌فرض \f[V]serialVersionUID\f[R] را برای آن کلاس محاسبه می‌کند. با این حال، اکیداً توصیه می‌شود که تمام کلاس‌های سریال‌پذیر مقادیر \f[V]serialVersionUID\f[R] را به طور صریح اعلان کنند، زیرا فرآیند پیش‌فرض محاسبه مقادیر \f[V]serialVersionUID\f[R] به شدت به جزئیات کلاس که ممکن است بسته به پیاده‌سازی‌های کامپایلر تفاوت داشته باشد، وابسته و حساس است. در نتیجه، این امر ممکن است در طول وا‌سریال‌سازی (deserialization) خطاهای پیش‌بینی‌نشده \f[V]InvalidClassExceptions\f[R] ایجاد کند. برای تضمین یک مقدار \f[V]serialVersionUID\f[R] سازگار میان پیاده‌سازی‌های مختلف کامپایلر Java، یک کلاس سریال‌پذیر باید به طور صریح یک مقدار \f[V]serialVersionUID\f[R] اعلان کند. .RE .TP \f[V]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[V]static\f[R] یعنی \f[V]m1\f[R] را به صورت زیر فراخوانی کنید: .RS .PP \f[V]XLintStatic.m1();\f[R] .RE .PP همچنین، می‌توانید کلیدواژه \f[V]static\f[R] را از اعلان متد \f[V]m1\f[R] حذف کنید. .RE .TP \f[V]this-escape\f[R] درباره نشت دادن \f[V]this\f[R] توسط سازنده‌ها پیش از مقداردهی اولیه زیرکلاس هشدار می‌دهد. برای نمونه، این کلاس: .RS.IP .nf \f[CB] public class MyClass { public MyClass() { System.out.println(this.hashCode()); } } \f[R] .fi .PP هشدار زیر را تولید می‌کند: .IP .nf \f[CB] MyClass.java:3: warning: [this-escape] possible \[aq]this\[aq] escape before subclass is fully initialized System.out.println(this.hashCode()); \[ha] \f[R] .fi .PP هشدار فرار \[aq]this\[aq] زمانی صادر می‌شود که یک سازنده کاری انجام دهد که ممکن است باعث فراخوانی متدی از یک زیرکلاس پیش از بازگشت سازنده شود. در چنین مواردی متد زیرکلاس روی نمونه‌ای که هنوز مقداردهی اولیه آن کامل نشده است عمل خواهد کرد. در مثال بالا، اگر زیرکلاسی از \f[V]MyClass\f[R] متد \f[V]hashCode()\f[R] را جهت استفاده از فیلدهای خودش بازنویسی کند، در صورت فراخوانی به شکلی که نشان داده شده، به احتمال زیاد نتیجه نادرستی تولید خواهد کرد. .PP هشدارها تنها در صورتی صادر می‌شوند که امکان وجود زیرکلاسی خارج از ماژول فعلی (یا بسته، در صورت نبود ماژول) در حال کامپایل وجود داشته باشد. بنابراین، برای نمونه، سازنده‌ها در کلاس‌های final و غیر public هشدار تولید نمی‌کنند. .RE .TP \f[V]try\f[R] درباره مشکلات مربوط به استفاده از بلوک‌های \f[V]try\f[R]، از جمله عبارت‌های try-with-resources هشدار می‌دهد. برای نمونه، برای عبارت زیر هشداری ایجاد می‌شود زیرا منبع \f[V]ac\f[R] اعلان‌شده در بلوک \f[V]try\f[R] استفاده نشده است: .RS .IP .nf \f[CB] try ( AutoCloseable ac = getResource() ) { // do nothing} \f[R] .fi .RE .TP \f[V]unchecked\f[R] جزئیات بیشتری درباره هشدارهای تبدیل بررسی‌نشده (unchecked conversion) که توسط Java Language Specification الزامی شده‌اند ارائه می‌دهد؛ برای نمونه: .RS .IP .nf \f[CB] List l = new ArrayList(); List ls = l; // unchecked warning \f[R] .fi .PP در طول پاک‌سازی نوع (type erasure)، نوع‌های \f[V]ArrayList\f[R] و \f[V]List\f[R] به ترتیب به \f[V]ArrayList\f[R] و \f[V]List\f[R] تبدیل می‌شوند. .PP دستور \f[V]ls\f[R] دارای نوع پارامتری \f[V]List\f[R] است. هنگامی که \f[V]List\f[R] مورد اشاره توسط \f[V]l\f[R] به \f[V]ls\f[R] انتساب می‌یابد، کامپایلر یک هشدار unchecked صادر می‌کند. در زمان کامپایل، کامپایلر و JVM نمی‌توانند تشخیص دهند که آیا \f[V]l\f[R] به نوع \f[V]List\f[R] اشاره دارد یا خیر. در این مورد، \f[V]l\f[R] به نوع \f[V]List\f[R] اشاره نمی‌کند. در نتیجه، آلودگی هیپ (heap pollution) رخ می‌دهد. .PP وضعیت آلودگی هیپ زمانی رخ می‌دهد که شیء \f[V]List\f[R] با نام \f[V]l\f[R]، که نوع ایستای آن \f[V]List\f[R] است، به شیء \f[V]List\f[R] دیگری به نام \f[V]ls\f[R] که نوع ایستای متفاوتی یعنی \f[V]List\f[R] دارد، منتسب شود. با این وجود، کامپایلر همچنان این انتساب را مجاز می‌داند. کامپایلر باید این انتساب را مجاز بداند تا سازگاری با گذشته (backward compatibility) با نسخه‌هایی از Java SE که از generics پشتیبانی نمی‌کردند حفظ شود. به دلیل پاک‌سازی نوع، هر دو نوع \f[V]List\f[R] و \f[V]List\f[R] به \f[V]List\f[R] تبدیل می‌شوند. در نتیجه، کامپایلر انتساب شیء \f[V]l\f[R] را که نوع خامی (raw type) از \f[V]List\f[R] دارد، به شیء \f[V]ls\f[R] مجاز می‌شمارد. .RE .TP \f[V]varargs\f[R] درباره استفاده ناامن از متدهای با تعداد آرگومان متغیر (\f[V]varargs\f[R])، به‌ویژه متدهایی که شامل آرگومان‌های غیرقابل‌تحقق (non-reifiable) هستند، هشدار می‌دهد؛ برای نمونه: .RS .IP .nf \f[CB] public class ArrayBuilder { public static void addToList (List listArg, T... elements) { for (T x : elements) { listArg.add(x); } } } \f[R] .fi .PP یک نوع غیرقابل‌تحقق نوعی است که اطلاعات نوع آن در زمان اجرا (runtime) به‌طور کامل در دسترس نیست. .PP کامپایلر هشدار زیر را برای تعریف متد \f[V]ArrayBuilder.addToList\f[R] صادر می‌کند: .IP .nf \f[CB] warning: [varargs] Possible heap pollution from parameterized vararg type T \f[R] .fi .PP هنگامی که کامپایلر با یک متد varargs مواجه می‌شود، پارامتر صوری \f[V]varargs\f[R] را به یک آرایه تبدیل می‌کند. با این حال، زبان برنامه‌نویسی Java ساخت آرایه‌هایی از نوع‌های پارامتری را مجاز نمی‌داند. در متد \f[V]ArrayBuilder.addToList\f[R]، کامپایلر پارامتر صوری \f[V]varargs\f[R] به نام \f[V]T...\f[R] elements را به پارامتر صوری آرایه‌ایِ \f[V]T[]\f[R] elements تبدیل می‌کند. اما به دلیل پاک‌سازی نوع، کامپایلر پارامتر صوری \f[V]varargs\f[R] را به \f[V]Object[]\f[R] elements تبدیل می‌نماید. در نتیجه، احتمال وقوع آلودگی هیپ وجود دارد. .RE