مهم‌ترین ویژگی‌های جدید در JDK 24

جاوا ۲۴ شامل ۲۴ ویژگی جدید است – بیش از هر نسخه جاوا از سال ۲۰۱۸ به بعد. این شش ویژگی بیش‌ترین اهمیت را برای توسعه‌دهندگان جاوا و شرکت‌های جاوا در کوتاه‌مدت خواهند داشت.

از سال ۲۰۱۸، ما هر شش ماه یک نسخه جدید از پلتفرم جاوا داشته‌ایم. با منظمی شبیه ساعت سوئیسی، آخرین نسخهٔ جاوا، JDK 24، در دسترس است. به‌طرز تقریباً شعرآمیز، JDK 24 شامل ۲۴ پیشنهاد ارتقاء JDK (JEP) است که بیشترین تعداد ویژگی‌های جدید از زمان معرفی برنامهٔ انتشار مبتنی بر زمان است.

من به بررسی هر یک از آن‌ها نمی‌پردازم، زیرا ۱۰ مورد ویژگی‌های پیش‌نمایش، ماژول‌های انکوباتور یا تجربی هستند. بیایید به مواردی نگاه کنیم که برای توسعه‌دهندگان و کسانی که جاوا را استقرار می‌دهند، جالب‌ترین هستند.

لینک‌کردن پیش از زمان

قسمتی از پروژه گستردهٔ لایدن، JEP 483، بارگذاری و لینک‌کردن کلاس‌ها پیش از زمان است. هدف پروژه لایدن کاهش زمان راه‌اندازی برنامه‌های جاوا است. یکی از بزرگ‌ترین مزایای جاوا استفاده از JVM است، یک ماشین مجازی که امکان اجرای برنامه روی هر پلتفرمی بدون نیاز به بازسازی را فراهم می‌کند. این رویکرد «یک بار بنویس، در هر جا اجرا کن» همچنین مقیاس‌پذیری و عملکرد عالی را با استفاده از کامپایل به‌موقع (JIT) ارائه می‌دهد. متأسفانه این بدون هزینه نیست؛ عملکرد کندتری هنگام گرم شدن برنامه نشان می‌دهد که هزینه‌ای دارد.

پروژه لایدن چندین بخش دارد و JEP 483 اولین بخشی است که در JDK ارائه می‌شود. بارگذاری و لینک‌کردن کلاس‌ها پیش از زمان مرتبط با اشتراک‌گذاری داده‌های کلاس برنامه است که در JDK 11 معرفی شد و با در دسترس قرار دادن فوری کلاس‌های یک برنامه در وضعیت بارگذاری و لینک‌شده هنگامی که JVM شروع می‌شود، این کار انجام می‌دهد. این کار از هزینهٔ بارگذاری، تأیید و لینک‌کردن مکرر فایل‌های کلاس هر بار که برنامه شروع می‌شود، جلوگیری می‌کند.

JEP 485، جمع‌کننده‌های جریانی (Stream Gatherers)، تغییر کوچکی اما ارزشمند است که برای توسعه‌دهندگان مفید خواهد بود. JDK 8 API جریانی (Stream) را معرفی کرد که همراه با عبارات لامبدا، سبک برنامه‌نویسی تابعی بیشتری در جاوا فراهم کرد.

یک جریان شامل سه بخش است: منبع، صفر یا بیش از یک عملیات میانی، و یک عملیات نهایی. توسعه‌دهندگان با توانایی مشخص کردن عملکرد دلخواه که رابط Collector را پیاده‌سازی می‌کند، انعطاف کامل بر روی عملکرد عملیات نهایی دارند.

برای عملیات میانی، مجموعهٔ ثابت (اگرچه غنی) از روش‌های موجود وجود داشته است. به همان شکلی که می‌توان رابط Collector را برای عملیات نهایی سفارشی پیاده‌سازی کرد، اکنون می‌توان رابط Gatherer را برای ارائه عملیات میانی سفارشی پیاده‌سازی کرد.

بدرود، مدیر امنیت

JEPها بهبودهایی را برای JDK تعریف می‌کنند، اما این همیشه به معنای افزودن چیزی نیست.

در مورد JEP 486، غیر فعال‌سازی دائمی مدیر امنیت، این کار حذف عملکرد است. در نگاه اول، این JEP خاص کمی نگران‌کننده به نظر می‌رسد. حذف مدیر امنیت؟ آیا این باعث می‌شود JDK کمتر امن باشد؟ واقعیت کاملاً متفاوت است.

مدیر امنیت از اولین نسخهٔ جاوا بخشی از آن بوده و برای استفاده هنگام اجرای کد بارگذاری‌شده از راه دور گنجانده شده بود. به‌طور پیش‌فرض، تمام کدهای راه‌دور به‌عنوان ناشناخته در نظر گرفته می‌شوند، بنابراین نمی‌توانند به منابعی مانند سیستم فایل، شبکه و غیره دسترسی پیدا کنند. برای هر منبع مورد نیاز و نوع دسترسی، باید اجازهٔ صریحی داده شود.

دلیل حذف مدیر امنیت این است که مدت طولانی ابزار اصلی برای ایمن‌سازی جاوی سمت کلاینت نبوده و به ندرت برای ایمن‌سازی کد سمت سرور استفاده می‌شده است. دوران اپلت‌ها که افزونهٔ مرورگر در JDK 11 حذف شد، به‌سختی گذشته است. با توجه به هزینهٔ نگهداری مدیر امنیت، در JDK 17 منسوخ شد و اکنون در JDK 24 دیگر قابل استفاده نیست.

متأسفانه برخی توسعه‌دهندگان از این ویژگی استفاده کرده‌اند، اما هیچ جایگزینی ارائه نشده است. مهاجرت این برنامه‌ها به JDK 24 و نسخه‌های بعدی ممکن است به تغییرات معماری عمده و بازنویسی نیاز داشته باشد. اگرچه جاوا سازگاری عالی با نسخه‌های قبلی دارد، اما گاهی برنامه‌ها باید برای کار بر روی نسخه‌های جدید تغییر کنند.

رشته‌های مجازی بدون پین‌گذاری

رشته‌های مجازی در JDK 21 معرفی شدند تا مقیاس‌پذیری بیشتری برای برنامه‌هایی که معمولاً از مدل برنامه‌نویسی thread-per-request استفاده می‌کردند و آن رشته‌ها زمان قابل توجهی را بلوک می‌شدند، فراهم کنند. با این حال، رشته‌های مجازی هنگام استفاده از متدها یا بلوک‌های synchronized محدودیت‌هایی داشتند. حتی اگر یک رشتهٔ مجازی بلوک شده باشد، اگر در یک بلوک یا متد synchronized باشد، رشتهٔ پلتفرم زیرین برای استفاده توسط سایر رشته‌های مجازی آزاد نمی‌شود. این ناشی از این است که مانیتوری که توسط متد یا بلوک synchronized استفاده می‌شود، به رشتهٔ پلتفرم اتصال دارد نه به رشتهٔ مجازی.

JEP 491، همگام‌سازی رشته‌های مجازی بدون پین‌گذاری، این محدودیت را با انتقال ارتباط مانیتور به رشتهٔ مجازی حل می‌کند. پیاده‌سازی JVM از کلیدواژه synchronized تغییر کرده است تا رشته‌های مجازی بتوانند به‌صورت مستقل از حامل‌های خود مانیتورها را به‌دست آورند، نگه دارند و آزاد کنند. عملیات mount و unmount اکنون bookkeeping لازم را برای اجازه دادن به رشتهٔ مجازی برای جدا شدن و دوباره‌اتصال هنگام حضور در یک متد یا عبارت synchronized یا انتظار بر روی مانیتور، انجام می‌دهند.

عدم‌امنیت و غیرضروری

از JDK 9 به بعد، بسته‌بندی APIهای داخلی JDK به‌طور فزاینده‌ای سخت‌تر شده است. در JDK 24، گامی دیگر به سمت حذف کامل دسترسی برداشته می‌شود.

کلاس بدنام sun.misc.Unsafe همواره یک مشکل بوده است، زیرا شامل عملکردی است که نمی‌توان آن را با یک کلاس نوشته‌شده توسط کاربر بازتولید کرد. تمام روش‌های مرتبط با حافظه اکنون از طریق APIهای عمومی ارائه‌شده توسط VarHandle API و Foreign Function & Memory API در دسترس هستند. JEP 498، هشدار هنگام استفاده از روش‌های دسترسی به حافظه در sun.misc.Unsafe، به این معنی است که JVM در زمان اجرا برای اولین بار که هر روش دسترسی به حافظه در sun.misc.Unsafe فراخوانی شود، هشدار صادر خواهد کرد.

آخرین JEP مورد علاقه JEP 501، حذف پورت ۳۲‑بیتی x86 است. در واقع، این فقط نسخهٔ لینوکس این پورت را تحت تأثیر قرار می‌دهد، زیرا نسخهٔ ویندوز در JDK 21 (JEP 449) حذف شده بود. تعداد بسیار کمی از افراد هنوز برنامه‌ها را بر روی سیستم‌عامل‌های ۳۲‑بیتی اجرا می‌کنند و انتقال آن‌ها به یک JDK مدرن بدون ارتقاء همزمان سیستم‌عامل به نسخهٔ ۶۴‑بیتی معنایی ندارد.

JDK 24 به پیشبرد پلتفرم جاوا ادامه می‌دهد و ویژگی‌هایی را ارائه می‌کند که توسعه‌دهندگان و کاربران آن‌ها را مفید می‌دانند. انتظار داشته باشید که همان ویژگی‌ها در JDK 25 (نسخهٔ بعدی پشتیبانی بلندمدت) و پس از آن ادامه پیدا کنند.

سیمون ریتتر معاون CTO و قهرمان جاوا در Azul است.

—

انجمن فناوری نوین (New Tech Forum) بستری را برای رهبران فناوری — از جمله فروشندگان و سایر مشارکت‌کنندگان خارجی — فراهم می‌کند تا به بررسی و بحث درباره فناوری‌های نوظهور سازمانی با عمق و گستردگی بی‌سابقه بپردازند. انتخاب‌ها به‌صورت ذهنی است، بر پایهٔ انتخاب ما از فناوری‌هایی که مهم می‌دانیم و بیشترین علاقهٔ خوانندگان InfoWorld را دارند. InfoWorld مطالب بازاریابی برای انتشار قبول نمی‌کند و حق ویرایش تمام محتویات مشارکت‌شده را برای خود محفوظ می‌دارد. برای ارسال تمام سؤال‌ها به doug_dineley@foundryco.com.