JDK 18: ویژگی های جدید در جاوا ۱۸

جاوا ۱۸ یک API برداری را انکوبه می کند، تطبیق الگو را برای عبارات سوئیچ پیش نمایش می دهد، UTF-8 را به عنوان مجموعه کاراکترهای پیش فرض پذیرفته است، شامل یک وب سرور ساده و موارد دیگر است.

کیت توسعه جاوا (JDK) 18 اکنون به عنوان نسخه تولید رسمی در دسترس است. نسخه جدید جاوا استاندارد دارای ۹ ویژگی جدید است، از جمله یک وب سرور ساده و پیش نمایش دیگری از تطبیق الگو برای switch.

صفحه OpenJDK ویژگی های زیر را به عنوان هدف رسمی JDK 18 فهرست می کند: یک سرویس رابط ارائه دهنده، یک وب سرور ساده، انکوباسیون سوم از API برداری، قطعه کد، پیاده سازی مجدد بازتاب هسته، مجموعه نویسه UTF-8، یک انکوباتور دوم یک تابع خارجی و API حافظه، یک پیش نمایش دوم از تطبیق الگو برای سوئیچ بیانیه‌ها، و منسوخ شدن نهایی‌سازی، که آخرین افزوده بود.

در حالی که JDK 17 یک نسخه پشتیبانی بلندمدت (LTS) بود که حداقل هشت سال از اوراکل پشتیبانی می‌کند، JDK 18 یک نسخه کوتاه مدت خواهد بود که برای شش سال پشتیبانی می‌شود. ماه ها. JDK 18 را می توان از oracle.com دانلود کرد.

مشخصات پیشنهادات JDK 18 عبارتند از:

• نهایی سازی را برای حذف در نسخه بعدی منسوخ کنید. Finalizer دارای نقص هایی است که باعث ایجاد مشکلات واقعی در امنیت، عملکرد، قابلیت اطمینان و نگهداری می شود. مدل برنامه نویسی سختی هم دارد. نهایی‌سازی در حال حاضر به‌طور پیش‌فرض فعال است، اما می‌توان آن را غیرفعال کرد تا آزمایش اولیه را تسهیل کند. به‌طور پیش‌فرض در نسخه‌ای از ویژگی غیرفعال می‌شود و در نسخه بعدی به طور کلی حذف می‌شود. این پیشنهاد خواستار یک گزینه خط فرمان برای غیرفعال کردن نهایی‌سازی و منسوخ شدن تمام نهایی‌کننده‌ها و روش‌های نهایی‌سازی در API استاندارد جاوا است. اهداف این پیشنهاد شامل کمک به توسعه دهندگان برای درک خطرات نهایی سازی، آماده سازی توسعه دهندگان برای حذف نهایی آن، و ارائه ابزارهای ساده برای کمک به تشخیص اتکا به نهایی سازی است. نهایی سازی که در جاوا ۱.۰ معرفی شد برای کمک به جلوگیری از نشت منابع در نظر گرفته شد. یک کلاس می تواند یک نهایی کننده – متد protected void finalize() – که بدنه آن هر منبع اساسی را آزاد می کند، اعلام کند. جمع‌آورکننده زباله، نهایی‌کننده یک شی غیرقابل دسترس را قبل از بازیابی حافظه شی، فراخوانی می‌کند. به نوبه خود، روش finalize می تواند اقداماتی مانند فراخوانی close شی را انجام دهد. به نظر می‌رسد این یک شبکه ایمنی مؤثر برای جلوگیری از نشت منابع است، اما نقص‌هایی از جمله تأخیر غیرقابل پیش‌بینی وجود دارد، با گذشت زمان طولانی بین زمانی که یک شی غیرقابل دسترسی می‌شود و زمانی که نهایی‌کننده آن فراخوانی می‌شود. رفتار نامحدود، با کد نهایی کننده قادر به انجام هر اقدامی، از جمله احیای یک شی و قابل دسترس کردن مجدد آن است. نهایی ساز همیشه فعال است، بدون مکانیزم ثبت صریح. و نهایی کننده ها می توانند روی رشته های نامشخص به ترتیب دلخواه اجرا شوند. با توجه به مشکلات نهایی، به توسعه دهندگان توصیه می شود از تکنیک های جایگزین برای جلوگیری از نشت منابع استفاده کنند، یعنی عبارت های try-with-resources و پاک کننده ها. (برای جزئیات به پیشنهاد ارتقای JDK 421 مراجعه کنید.)
• برای SPI وضوح آدرس اینترنتی، پیشنهاد تعریف یک SPI است برای تفکیک آدرس میزبان و نام به طوری که Inet.Address می تواند از حل کننده های دیگری غیر از حل کننده داخلی پلت فرم استفاده کند. انگیزه‌های این تلاش شامل فعال کردن بهتر Project Loom برای همزمانی و مدل‌های برنامه‌نویسی جدید است. در جاوا، همراه با یکپارچه سازی پروتکل های جدید شبکه، سفارشی سازی و فعال کردن تست. این پیشنهاد شامل ایجاد یک حل کننده جایگزین برای JDK نیست.
• پیش نمایش دوم تطبیق الگو برای سوئیچ، که در آن زبان جاوا با تطبیق الگو برای عبارات و عبارات switch، همراه با پسوندهای زبان الگوها تقویت می‌شود. این پیش نمایش در JDK 17 مشاهده شد. گسترش تطبیق الگو به switch اجازه می‌دهد تا یک عبارت در برابر تعدادی الگو، که هر کدام دارای عملکرد خاصی هستند، آزمایش شود، بنابراین می‌توان پرس‌وجوهای پیچیده داده‌گرا را به طور مختصر و ایمن بیان کرد. این ویژگی از Project Amber می آید، یک پروژه OpenJDK که بر ویژگی های کوچکتر جاوا و بهره وری محور تمرکز دارد. جورج ساب، معاون گروه پلتفرم جاوا در اوراکل، گفت: «تطبیق الگو برای switch چیزی است که هر برنامه نویس جاوا باید ببیند و با آن برخورد کند و می تواند از آن استفاده کند. این قابلیت پشتیبانی گسترده ای را برای تطبیق الگو در جاوا نشان می دهد. قبلاً برای نمونه در دسترس بود. ساب گفت که این سبک از برنامه نویسی به ماهیت دوم تبدیل خواهد شد.
• اجرای مجدد بازتاب هسته با دسته‌های متد lang.reflect.Method را مجدداً پیاده‌سازی می‌کند. ، Constructor و Field در بالای دسته‌های روش java.lang.invoke. داشتن دسته‌های متد به عنوان مکانیزم اساسی برای بازتاب، هزینه‌های نگهداری و توسعه هر دو APIهای java.lang.reflect و java.lang.invoke را کاهش می‌دهد.
• با پیشنهاد وب سرور ساده، یک ابزار خط فرمان برای شروع یک حداقل وب سروری که فقط فایل های ثابت را ارائه می دهد. هیچ CGI یا عملکردی شبیه سرورلت در دسترس نیست. این ابزار برای نمونه سازی، کدگذاری موقت و آزمایش، به ویژه در زمینه های آموزشی مفید خواهد بود. اهداف این طرح شامل ارائه یک سرور فایل HTTP استاتیک خارج از جعبه با راه اندازی آسان و حداقل عملکرد، کاهش انرژی فعال سازی توسعه دهنده و قابل دسترس تر کردن JDK و ارائه یک پیاده سازی پیش فرض از طریق خط فرمان همراه با یک API کوچک است. برای ایجاد و سفارشی سازی برنامه ای ارائه یک سرور با ویژگی های غنی یا با درجه تجاری هدف پیشنهاد نیست.
• دومین انکوباسیون یک API عملکرد خارجی و حافظه، که در آن یک API از طریق معرفی می شود کدام برنامه های جاوا می توانند با کد و داده های خارج از زمان اجرا جاوا تعامل داشته باشند. با فراخوانی توابع خارجی – کد خارج از JVM – و با دسترسی ایمن به حافظه خارجی – حافظه ای که توسط JVM مدیریت نمی شود – API به برنامه های جاوا اجازه می دهد تا کتابخانه های بومی را فراخوانی کرده و داده های بومی را بدون شکنندگی و خطر JNI پردازش کنند. (رابط بومی جاوا). هدف جایگزینی JNI با یک مدل توسعه برتر جاوا خالص است. این API در JDK 17 انکوبه شد. برای JDK 18، اصلاحات بر اساس بازخورد، مانند پشتیبانی از حامل های بیشتری مانند Boolean و MemoryAddress در دسته های var دسترسی به حافظه، و یک API جدید برای کپی کردن آرایه های جاوا به و از حافظه گنجانده شد. بخش ها.
• بردار API برای سومین بار در JDK 18 انکوبه می شود، که قبلا انکوبه شده بود. در JDK 16 و JDK 17. این پیشنهاد محاسبات برداری را بیان می‌کند که در زمان اجرا به دستورالعمل‌های برداری بهینه در معماری‌های CPU پشتیبانی می‌شوند و عملکردی برتر از محاسبات اسکالر معادل را به دست می‌آورند. عملیات برداری درجه ای از موازی سازی را بیان می کند که کار بیشتری را در یک چرخه واحد CPU انجام می دهد و در نتیجه باعث بهبود عملکرد قابل توجهی می شود. هدف پلتفرم-اگنوستیک بردار API ارائه راهی برای نوشتن الگوریتم‌های پیچیده در جاوا، با استفاده از بردار خودکار HotSpot موجود، اما با یک مدل کاربری که بردارسازی را قابل پیش‌بینی‌تر می‌کند. JDK 18 همچنین از پلت فرم ARM Scalar Vector Extension پشتیبانی می کند و عملکرد عملیات برداری را که می پذیرند بهبود می بخشد. ماسک هایی روی معماری هایی که از پوشش در سخت افزار پشتیبانی می کنند. API برداری نیز از پروژه پاناما مشتق شده است.
• تعیین UTF-8 به‌عنوان مجموعه نویسه‌های پیش‌فرض APIهای استاندارد جاوا. UTF-8 یک رمزگذاری کاراکتر با پهنای متغیر برای ارتباطات الکترونیکی است و مجموعه حروف استاندارد وب در نظر گرفته می شود. Charset یک رمزگذاری کاراکتر است که می تواند همه کاراکترهای موجود در وب را رمزگذاری کند. از طریق این تغییر، APIهایی که به مجموعه نویسه‌های پیش‌فرض وابسته هستند، در تمامی پیاده‌سازی‌ها، سیستم‌های عامل، محلی‌ها و پیکربندی‌ها به‌طور پیوسته رفتار خواهند کرد. این پیشنهاد برای تعریف APIهای جدید با استاندارد جاوا یا JDK در نظر گرفته نشده است. طرفداران این پیشنهاد انتظار دارند که برنامه‌های کاربردی در بسیاری از محیط‌ها تاثیری از انتخاب UTF-8 توسط جاوا نبینند، زیرا MacOS، بسیاری از توزیع‌های لینوکس و بسیاری از برنامه‌های کاربردی سرور در حال حاضر از UTF-8 پشتیبانی می‌کنند. با این حال، در محیط‌های دیگر خطر وجود دارد، واضح‌ترین آن این است که برنامه‌های کاربردی بسته به مجموعه حروف پیش‌فرض هنگام پردازش داده‌های تولید شده در زمانی که مجموعه حروف پیش‌فرض مشخص نشده بود، رفتار نادرست خواهند داشت. خرابی داده ها ممکن است بی سر و صدا رخ دهد. انتظار می‌رود تأثیر اصلی بر روی کاربران سیستم‌های ویندوز در مناطق آسیایی و احتمالاً برخی از محیط‌های سرور در آسیا و سایر مناطق باشد.
• قطعات کد در اسناد Java API، شامل معرفی یک @snippet< برچسب /code> برای Doclet استاندارد JavaDoc، برای ساده کردن گنجاندن کد منبع نمونه در اسناد API. از جمله اهداف این طرح، تسهیل اعتبار بخشی از کد منبع با فراهم کردن دسترسی API به آن قطعات است. در حالی که مسئولیت صحت بر عهده نویسنده است، پشتیبانی پیشرفته در JavaDoc و ابزارهای مرتبط می‌تواند دستیابی به آن را آسان‌تر کند. اهداف دیگر عبارتند از فعال کردن یک سبک مدرن، مانند برجسته کردن نحو، و همچنین پیوند خودکار نام ها به اعلان ها، و فعال کردن پشتیبانی IDE بهتر برای ایجاد و ویرایش قطعات. پیشنهاد اشاره می‌کند که نویسندگان اسناد API اغلب بخش‌هایی از کد منبع را در نظرات مستندات قرار می‌دهند.