نسخه 17 جاوا به زودی منتشر می شود و ویژگی های جدیدی را به شما ارائه خواهد داد، در این مطلب بیشتر درباره ویژگی های جدید نسخه 17 جاوا صحبت می کنیم.

نسخه بعدی جاوا یعنی نسخه 17 جاوا دارای ویژگی های بسیار زیادی خواهد بود که بدون شک آشنایی با آنها می تواند برای تمامی توسعه دهندگان این زبان برنامه نویسی جذاب باشد. در این نسخه 10 ویژگی جدید به زبان برنامه نویسی جاوا اضافه می شود در حالی که دو ویژگی حذف شده و دو مورد از ویژگی های این زبان نیز وارد حالت منسوخ شده می شوند. از جمله قابلیت هایی که برای نسخه 17 جاوا تنظیم شده است می توان به پشتیبانی از فیلترهای context-specific deserialization اشاره کرد که بهبود امنیتی در این زبان به شمار می آید. علاوه بر این پیش نمایشی از قابلیت تطبیق الگو برای دستورات switch و سایر عبارات نیز در این نسخه قرار گرفته است.

نسخه 17 جاوا

در تاریخ 14 سپتامبر نسخه 17 جاوا یا همان Java Development Kit (JDK) 17 به عنوان یک محصول تولیدی منتشر خواهد شد و برای مدت زمان طولانی پشتیبانی می شود و علاوه بر این پشتیبانی گسترده ای از اوراکل برای مدت زمان طولانی نیز خواهد داشت. در تاریخ 10 ژوئن و زمانی که نسخه 17 زبان برنامه نویسی جاوا وارد فاز اولیه خود شد منتشر شدند. بیشتر این ویژگی ها روی تعمیر کردن باگ ها و مشکلات زبان تمرکز داشتند. Repo تثبیت کننده در نسخه 17 این زبان برای برطرف کردن باگ ها در دسترس خواهد بود و علاوه بر این بهینه سازی هایی نیز روی آن انجام شده است. ویژگی های جدید دیگری نیز به این زبان اضافه شده است که در ادامه به معرفی هر یک از این ویژگی ها خواهیم پرداخت.

فیلترهای Context-specific deserialization در جاوا 17

فیلترهای Context-specific deserialization در نسخه 17 جاوا به اپلیکیشن ها اجازه می دهند تا فیلترهای deserialization که به صورت داینامیک انتخاب شده اند یا فیلترهایی که context-specific هستند را پیکربندی کنند. این کار از طریق فراخوانی سازنده فیلتر JVM-wide صورت می گیرد که یک فیلتر را برای هر یک از عملیات های serialization انتخاب می کند.

اوراکل در خصوص انگیزه ای که پشت این ویژگی وجود داشت می گوید: deserialize کردن داده های غیر قابل اعتماد ذاتا یک فعالیت خطرناک است چرا که داده ای که از جریان داده ها خارج می شود مشخص کننده شیئی که ساخته شده، ارزش فیلدهای مختلف آن و یک مرجع بین آنها می باشد. در بسیاری از موارد بایت هایی که داخل جریان داده وجود دارند از سمت کاربری که ناشناخته، غیرقابل اعتماد و احراز هویت نشده است می باشد. با افزایش دقت در ساخت جریان داده رقبای شما می توانند به سادگی کلاس های کد شما را بهم ریخته و با اهداف مخرب داده های اشتباهی را وارد کدهای شما کنند. اگر ساخت اشیا دارای اثرات جانبی باشد که حالت را عوض کند یا این که سایر اقدامات را فراخوانی کند این اقدامات جانبی می توانند یکپارچگی اشیا اپلیکیشن را به خطر انداخته و باعث ایجاد خطرات و ریسک های مختلف در اشیا کتابخانه ها و همینطور ران تایم جاوا شوند.

کلید اصلی جلوگیری از حملات serialization

کلید اصلی برای جلوگیری از حملات serialization به اشیا قبلی که در اپلیکیشن ها ساخته شده است این است که از اجرا کردن مستقیم یا غیر مستقیم متدهای آنها جلوگیری کنیم. فیلترهای Deserialization در جاوا 9 معرفی شدند تا به کدهای اپلیکیشن و کتابخانه ها این امکان را بدهند که جریان داده خروجی را پیش از deserialize کردن آنها اعتبارسنجی کنند. این کد زمانی که یک جریان deserialization ایجاد می شود منطق اعتبارسنجی را به عنوان یک java.io.ObjectInputFilter روی آن اعمال می کند. با این حال باید توجه داشته باشید که تکیه کردن بر سازنده جریان داده ها برای درخواست مستقیم اعتبارسنجی دارای محدودیت هایی است.

بهبودهایی که در نسخه 17 جاوا رخ داده است راهکارهایی را برای برطرف کردن این محدودیت ها با معرفی فیلتر JVM-wide deserialization ارائه داده است که می توان آن را با استفاده از یک API، ویژگی های سیستم یا ویژگی های امنیتی تنظیم کرد اما باید دقت داشته باشید که این رویکرد نیز دارای محدودیت هایی به خصوص در اپلیکیشن های پیچیده می باشد. رویکرد بهتر این است که از فیلترهای مخصوص هر جریان داده استفاده کنید چرا که این فیلترها نیازی به مشارکت همه سازندگان جریان های داده ندارند. این بهینه سازی ها و اضافه شدن ویژگی های جدید به توسعه دهندگان این اجازه را می دهد تا فیلترهای مناسبی را برای هر deserialization context ساخته و در صورت نیاز آنها را اعمال کنند.

ویژگی های مربوط به اعداد با ممیز شناور

در نسخه 17 جاوا عملیات های مربوط به اعداد با ممیز شناور به صورت سخت گیرانه تری انجام می شوند. این کار باعث می شود تا معنای واقعی اعداد با ممیز شناور به زبان برنامه نویسی جاوا بازگردد و ماشین مجازی زبان برنامه نویسی جاوا معنای آن را پیش از معرفی حالت اعداد با ممیز شناور پیش فرض در ویرایش استاندارد جاوا 1.2 تطابق دهد. هدف اصلی از انجام این کار راحتی توسعه کتابخانه های مبتنی بر محاسبات عددی است که از جمله آنها می توان java.lang.Math و java.lang.StrictMath اشاره کرد. اصلی ترین انگیزه برای تغییر اعداد ممیز شناور پیش فرض در زبان جاوا به سال 1990 میلادی باز می گردد که در آن زمان تعامل نامناسبی بین زبان برنامه نویسی اصلی جاوا و معناشناسی JVM  و همینطور معماری پردازشگرهای معروف x86  رخ داد.  

تطبیق معنایی اعداد ممیز شناور در تمامی موارد

تطبیق معنایی اعداد ممیز شناور در تمامی موارد شامل عملوندها و نتایج غیر معمول نیازمند دستورالعمل های اضافی می باشد. تطابق نتایج در غیاب overflow یا underflow می تواند با هزینه کمتری انجام شود و این تقریبا همان چیزی است که توسط معناشناسی اعداد ممیز شناور پیش فرض که در Java SE 1.2 معرفی شد انجام می شود. با این حال باید توجه داشته باشید که افزونه های SSE2 که در Pentium 4 و پردازنده های بعدی که از سال 2001 تولید شدند عرضه شدند می توانند از عملیات های مربوط به اعداد ممیز شناور JVM( ماشین مجازی جاوا) به صورت کاملا مستقیم پشتیبانی کنند.

از آنجایی که Intel و AMD از SSE2 و افزونه های نسل بعدی پشتیبانی می کنند امکان پشتیبانی کامل از این اعداد فراهم می شود. بنابراین دیگر نیازی به پشتیبانی معنایی از اعداد ممیز شناور پیش فرض که با عملیات های سخت گیرانه اعداد ممیز شناور در جاوا تفاوت دارند نیست.

Security Manager در نسخه 17 جاوا آماده حذف خواهد شد

Security Manager یکی از ویژگی های جاوا است که از نسخه 1 جاوا با آن همراه بوده است و اصلی ترین ابزار در زبان برنامه نویسی جاوا برای برای افزایش امنیت کدهای سمت کلاینت این زبان بوده است. این ابزار به ندرت برای تامین امنیت کدهای سمت سرور مورد استفاده قرار می گرفت. هدف اصلی از ارائه پیشنهاد حذف این ابزار بررسی این مسئله بود که آیا API ها و مکانیزم های جدید برای بررسی مسائل امنیتی مورد نیاز است یا خیر؟ از جمله ابزارهای جدید پیشنهادی می توان به  blocking System::exit اشاره کرد. بسیاری از افراد خواستار حذف Security Manager به همراه Applet API قدیمی بودند که این ابزار نیز در نسخه 17 جاوا منسوخ خواهد شد.

پیش نمایشی از تطبیق الگوها در نسخه 17 جاوا

در نسخه 17 جاوا پیش نمایشی از تطبیق الگوها برای دستورالعمل های switch ارائه می شود که از زبان الگوها در جاوا گرفته شده است. این ابزار به دستورالعمل های switch اجازه می دهد تا خود را در برابر تعداد زیادی از الگوهای مختلف که هر یک عملیات خاصی را انجام می دهند آزمایش کنند. این ابزار به کوئری های پیچیده مبتنی بر داده اجازه می دهد تا به صورت کاملا واضح و امن توصیف شوند. از جمله اهداف مختلفی که پشت این ویژگی قرار دارد می توان به بهبود و افزایش کاربردهای مختلف دستورالعمل switch اشاره کرد که این کار با فعال سازی امکان ظاهر شدن الگوها در لیبل های case صورت می گیرد.

با این ویژگی دو نوع الگو نیز معرفی می شود: اولی الگوهای محافظت شده هستند که به منطق تطبیق الگوها اجازه می دهند تا با استفاده از عبارت های بولین دلخواه مجددا تعریف شوند. دومی الگوهای پرانتزگذاری هستند که برای برطرف کردن برخی از ابهامات موجود در تجزیه مورد استفاده قرار می گیرند. در JDK 16 یک شی از عملگرها می تواند یکی از انواع این الگوها را انتخاب کرده و عملیات تطبیق الگو را انجام دهد.

کپسوله سازی قوی برای بخش های داخلی  JDK

کپسوله سازی قوی برای بخش های داخلی JDK به جز API های  داخلی حیاتی مانند sun.misc.Unsafe دیگر به شما این اجازه را نمی دهد تا بتوانید با استفاده از تنها یک خط کد ساده عناصر داخلی را کپسوله سازی کنید. این قابلیت از JDK 9 تا JDK 16 در دسترس بود که با انتشار نسخه 17 جاوا دیگر در دسترس توسعه دهندگان قرار نمی گیرد. هدف اصلی از ارائه این طرح بهبود مسائل امنیتی نسخه 17 جاوا و همینطور بهبود قابلیت نگهداری از JDK می باشد. علاوه بر این باید دقت داشته باشید که این طرح توسعه دهندگان را تشویق می کند تا از عناصر داخلی JDK به API های استاندارد جاوا مهاجرت کنند.

حذف مکانیزم فعال سازی فراخوانی متد از راه دور یا RMI در نسخه 17 جاوا

یکی از ویژگی هایی که در نسخه 17 جاوا حذف خواهد شد مکانیزم فعال سازی فراخوانی متد از راه دور یا RMI می باشد. البته سایر بخش های RMI حفظ خواهد شد و تنها بخش فعال سازی آن حذف می شود. مکانیزم فعال سازی RMI در حال حاضر نیز منسوخ شده و توسعه دهندگان دیگر از آن استفاده نمی کنند. منسوخ شدن این ویژگی در JDK 15 اتفاق افتاد و پس از آن توسعه دهندگان از روش های جایگزین استفاده می کنند.

تابع خارجی و API حافظه و مموری

تابع خارجی و API مموری در مرحله ابتدایی از معرفی نسخه 17 جاوا معرفی شد. این ویژگی به اپلیکیشن های نوشته شده به این زبان برنامه نویسی اجازه می دهد تا از خارج از برنامه با کد و داده های موجود در برنامه ارتباط برقرار کنند. به وسیله فراخوانی بهینه تابع خارجی یعنی از خارج از موتور مجازی جاوا و دسترسی امن به حافظه خارجی مموری و حافظه دیگر توسط موتور مجازی مدیریت نمی شود. API برنامه ها و اپلیکیشن های جاوا را قادر می سازد تا کتابخانه های محلی و نیتیو را فراخوانی کرده و بتوانند داده های محلی را نیز بدون ریسک های مربوط به JNI( یا رابط کاربری نیتیو جاوا) پردازش کنند. API پیشنهادی در واقع نسخه تکامل یافته از دو API می باشد که اولی مربوط به API دسترسی به حافظه خارجی و دومی مربوط به API متصل کننده خارجی می باشد. API دسترسی به حافظه خارجی در سال 2019 و در نسخه 14 جاوا مورد هدف قرار گرفت و در نسخه های بعدی جاوا نیز مورد استفاده قرار گرفت. API متصل کننده خارجی در نسخه 16 جاوا و در سال 2020 مورد هدف قرار گرفت که کار کردن با آن بسیار ساده بود و علاوه بر این باعث افزایش امنیت اطلاعات در زبان برنامه نویسی جاوا میشد.

قابلیت vector API

vector API که پیش از این در نسخه 16 JDK نیز ارائه شده بود در نسخه 17 جاوا نیز در اختیار توسعه دهندگان قرار می گیرد. این API مکانیزمی را برای شما فراهم می کند که بتوانید محاسبات برداری را در زبان برنامه نویسی جاوا به راحتی انجام دهید. این API در واقع دستورالعمل های برداری بهینه را برای شما فراهم می کند که از معماری CPU نیز پشتیبانی می کند. استفاده از این API از نظر محاسباتی شرایط بهتری را نسبت به محاسبات اسکالر برای شما فراهم می کند. در نسخه 17 جاوا vector API بهینه سازی شده است تا عملکرد بهتری را به شما ارائه دهد و راحت تر پیاده سازی شود. یکی از مهم ترین ویژگی های این API بهبود در ترجمه بردارهای بایت به آرایه های بولین و برعکس می باشد.

کلاس ها و اینترفیس های انتخاب شده در نسخه 17 جاوا

رابط های کاربری و کلاس های انتخاب شده کلاس ها و رابط های کاربری دیگری که ممکن است آنها را پیاده سازی کنند را محدود می کنند. هدف اصلی از ارائه این طرح این بود که به نویسنده و سازنده یک کلاس یا  رابط کاربری اجازه دهد تا مشخص کند کدام کد مسئول پیاده سازی آن می باشد. علاوه بر این یکی دیگر از اهداف ارائه این طرح فراهم کردن یک روش بهتر برای دسترسی به modifier ها برای محدود کردن استفاده از یک سوپر کلاس و همچنین پشتیبانی از اهداف آینده برای تطبیق الگو در زبان برنامه نویسی جاوا و فراهم کردن یک بستر مناسب برای آنالیز و بررسی کردن الگوها می باشد.

حذف کامپایلر آزمایشی AOT و JIT

حذف کامپایلرهای AOT و JIT که کاربرد چندانی نداشتند ولی نیاز به نگهداری با هزینه بالا داشتند یکی دیگر از مواردی است که در نسخه 17 جاوا اتفاق می افتد. این برنامه برای اینترفیس کامپایلر موتور مجازی جاوا در سطح جاوا پیاده سازی می شود به همین علت نیز توسعه دهندگان می توانند از نسخه های خارجی این کامپایلرها استفاده کنند. AOT که همان ابزار jaotc است در JDK 9 به عنوان یک ویژگی آزمایشی اضافه شد. این ابزار از کامپایلر Graal که به زبان برنامه نویسی جاوا نوشته شده است استفاده می کند. این ویژگی های آزمایشی در نسخه 16 JDK که به صورت رسمی توسط اوراکل منتشر شد قرار نداشتند و کسی نیز نسبت به این مسئله شکایتی نداشت. براساس یک برنامه از پیش تعیین شده سه مورد از ماژول های JDK حذف خواهند شد که این سه ماژول به ترتیب عبارت اند jdk.aot یا همان ابزار jaotc، internal.vm.compiler، کامپایلر Graal و jdk.internal.vm.compiler.management. البته باید توجه داشته باشید که بیشتر کدهای مرتبط با کامپایل AOT نیز حذف خواهد شد.

انتقال JDK به MacOS/AArch64 در نسخه 17 جاوا

با توجه به برنامه اپل برای انتقال کامپیوترهای Macintosh از x64 به AArch64 در نسخه 17 جاوا شاهد انتقال JDK به MacOS/AArch64 خواهیم بود. در حال حاضر یک پورت AArch64 برای جاوا در دسترس است که در لینوکس قرار دارد و می توان از آن برای ویندوز نیز استفاده کرد. سازندگان زبان برنامه نویسی جاوا انتظار دارند که از کد AArch64 که در حال حاضر موجود است دوباره استفاده کنند که این کار از طریق همین پورت صورت می گیرد. البته برای استفاده از این پورت باید تغییراتی در دستورالعمل های سطح پایین مانند اینترفیس باینری اپلیکیشن و مجموعه ای از رجیسترهای پردازنده رزرو شده ایجاد شود. تغییراتی که در MacOS/AArch64 ایجاد می شود خطراتی را برای Linux/AArch64، Windows/AArch64 و MacOS/x64 ports به همراه خواهد داشت ولی این ریسک و خطر با استفاده از آزمایش های از پیش ادغام شده کاهش پیدا خواهد کرد.

Applet API منسوخ شده از نسخه 17 جاوا حذف خواهد شد

این API در نسخه 17 جاوا به طور کامل حذف خواهد شد چرا که اساسا بی ربط بود و کاربرد چندانی نداشت. دلیل این مسئله این است که تمامی فروشندگان مرورگرهای وب پشتیبانی خود از پلاگین های مرورگر جاوا را حذف کرده و برنامه های مختلفی را برای انجام این کار دارند. Applet API پیش از این منسوخ شده بود اما برای استفاده در دسترس بود که در نسخه جدید به طور کامل حذف خواهد شد.

اضافه شدن یک پایپ لاین جدید برای MacOS

با استفاده از Apple Metal API و به عنوان یک جایگزین برای پایپ لاین فعلی که از OpenGL API منسوخ شده استفاده می کند یک پایپ لاین جدید برای MacOS ارائه می شود. این پیشنهاد ارائه شد تا یک پایپ لاین کاملا فانکشنال برای اجرای Java 2D API که از فریم ورک MacOS Metal استفاده می کند ایجاد کند و شرایطی را ایجاد کند تا بتوان در نسخه 17 جاوا OpenGL API را به طور کامل از ویژگی های MacOS حذف کرد. این پایپ لاین ارائه شده است تا عملکردی مشابه OpenGL را به شما ارائه دهد و در اپلیکیشن های مختلف کاربردهای بسیار زیادی داشته باشد. با استفاده از این پایپ لاین یک معماری بسیار تمیز و جذاب ایجاد می شود که سازگاری کاملی با مدل فعلی Java 2D دارد. البته باید دقت داشته باشید که پایپ لاین جدید باید سازگاری کاملی با پایپ لاین OpenGL داشته باشد و در اهداف آن اضافه شدن ویژگی ها یا api های جدید نیامده است.

تولید اعداد شبه تصادفی پیشرفته در نسخه 17 جاوا

یکی از ویژگی های مهم نسخه 17 جاوا این است که یک اینترفیس جدید را برای تولید اعداد شبه تصادفی اضافه کرده است که از الگوریتم های PRNG استفاده می کند. رابط جدید باید یک api واحد را برای تمامی PRNG های موجود و جدید ارائه دهد. انگیزه اصلی از ارائه این طرح روی نواحی مختلفی تمرکز دارد که تمامی آنها با تولید اعداد شبه تصادفی در زبان برنامه نویسی جاوا مرتبط هستند. دقت داشته باشید که تلاش های صورت گرفته برای پیاده سازی تعداد زیادی از الگوریتم های PRNG نیست. با این حال باید توجه کنید که سه الگوریتم رایج به نسخه 17 جاوا اضافه شده است که امروزه به طور گسترده ای در سایر زبان های برنامه نویسی نیز مورد استفاده قرار می گیرند. از جمله مهمترین اهداف این طرح می توان به موارد زیر اشاره کرد:

-   راحت تر کردن روند استفاده متناوب از چندین اپلیکیشن PRNG در برنامه ها و اپلیکیشن ها

-  بهبود پشتیبانی از برنامه نویسی مبتنی بر جریان که جریانی از اشیا PRNG را فراهم می کند.

-  حذف کدهای تکراری موجود در کلاس های PRNG

-  حفظ رفتار فعلی کلاس java.util.Random

طبق اعلام قبلی دسترسی های سریع تر به نسخه 17 جاوا از طریق jdk.java.net امکان پذیر خواهد بود که توسعه دهندگان می توانند از آن استفاده کنند تا بیشتر با ویژگی های این نسخه از زبان محبوب جاوا آشنا شوند.