Java מתרחבת עם מנגנונים מודרניים חדשים, ועם זה, הקבר שלה גדל עם תכונות מיושנות כגון Vector, Finalization, NashornScriptEngine, SecurityManager, ו Unsafe. איך קבר מתמלא? Java משגשגת וגוברת, מצטברות תכונות חדשות, API, ומודולים, אבל באותו זמן, היא משאירה את העור הישן שלה מעת לעת. חלקים מוכיחים להיות מיותרים, אחרים כבר לא מתאימים למשימות מודרניות, וחלקם תמיד מיועדים כקלדג'ים. בואו נסתכל על כמה מהם. מה יש בתוך הקבר? אוסף Legacy עוד לפני שג'אווה הייתה , או פראי , , ו בניגוד לכל העתיקות שלאחר מכן, API ישנה זו אינה מסומנת כ יחד עם זאת, במקביל, את עבור כל כיתה צועקים "אל תשתמש בי!" על עצמות האינטרנט, שיעורים עתיקים אלה נקראים בדרך כלל . List Deque Map Vector Stack Dictionary Deprecated תיעוד legacy collection classes מדוע הם מתקדמים? אוסף מורשת יש שני חסרונות עיקריים: 
 
 
 כל נקודות האינטראקציה עם שיעורים אלה מסונכרנות; לשיעורים אין ממשקים משותפים ודורשים גישה אישית. בואו נלך לפי סדר. החיסרון הראשון הוא** כי כל נקודות האינטראקציה עם שיעורים אלה מסונכרניות.** עם זאת, זה נראה יותר כמו יתרון מאשר להיפך. אחרי הכל, multithreading מאובטח הוא תמיד דבר טוב. אבל מה אם אוספים אלה משמשים בהקשר של חוט אחד? סינכרוניזציות פשוט להפחית את הביצועים מבלי לספק כל יתרונות אבטחה אמיתיים. החיסרון השני** הוא כי לכיתות אין ממשקים משותפים ודורשים גישה אישית.** זה מוביל לבעיה ישנה כמו התכנות עצמן: קוד לא אוניברסלי.לדמיינו שאנחנו מפתחים שעובדים על גירסה ישנה של Java, ויש לנו קוד קשור לדוגמה, הנה אחד מהם: Stack Stack<Integer> stack = new Stack<>();

for (int i = 0; i < 5; i++) {
    stack.add(i);
}

System.out.println(stack.pop());
 נכון לעכשיו, הקוד הוא ללא כל תקלות, אבל תארו לעצמכם שהוא התפוצץ ל-1000 שורות עם 150 התייחסות לזה. משתנה stack ואז יום אחד, הלקוחות שלחו לנו פקס ואמרו שהם עבדו לאט מאוד (הקודי הבלוקים, לא הלקוחות). הוא מכיל מערך לאחסון אלמנטים, ומערך זה עצמו מתחדש לעתים קרובות מדי. Stack אנו חושבים ומציגים תיאוריה: הרשימה המקושרת יכולה לעזור להגדיל את ביצועי האפליקציה ב-100 פעמים! באינטרנט – ולאחר מכן לגלגל את הכפפות שלנו כדי להעתיק ולהפוך את כל 150 הפניות לא בכלל, אבל אנחנו לא רואים שום דרך אחרת לצאת. LinkedList stack בואו נעבור לעבר הנוכחי, שבו הקוד שלנו נראה כך: Deque<Integer> deque = new ArrayDeque<>();
IntStream.range(0, 5)
        .forEach(deque::addLast);
System.out.println(deque.pollLast());
 עם הזמן, הקוד גם גדל לכלול 150 הפניות, אבל עכשיו יש לו הפניות אנו עוקבים אחר אותו נתיב וגם מציגים את התיאוריה כי זה יהיה מהיר יותר עם רשימה מקושרת. 2 אשר גם מבצעת וזה כל מה שצריך! deque ArrayDeque LinkedList Deque זה בדיוק איך פותר את הבעיה של היעדר ממשקים משותפים.זה עוזר למנוע להיות מחוברים ליישומים ספציפיים. ואפשר להשתמש ב אינטגרציה במקום מסגרת אוסף Vector List סיום באותו זמן, (למשל ) נראה כמו רעיון מצוין: שיטה שיקרא כאשר אובייקט נהרס, משחרר משאבי מערכת. סיום #finalize() אבל בפועל, הרעיון הזה לא היה כל כך מבריק: 
 
 
 
 
 ייתכן שהסגנון לא יתקשר בכלל אם עדיין היה התייחסות לאובייקט איפשהו או אם אוסף הזבל לא רצה למחוק אותו. אם אוסף הזבל באמת רצה להרוס את האובייקט, הוא עדיין היה צריך לחכות עד שהקוד הזה בוצע; האובייקט יכול אפילו להתחדש בעצמו; והכי גרוע מכל, הגמלאים יצרו תנאים מושלמים לפריצות זיכרון. ג'אווה המודרנית היא גמישה מאוד; אפילו אוסף הזבל יכול להיות מכל סוג והוא מוגדר בדרכים שונות. ואל תשכחו כי אספקת הזבל מובטחת לא לאסוף דוגמה כל עוד יש לה לפחות אחת הפניות חזקות. מסיבות אלה, ההיגיון של שחרור משאבי המערכת לא צריך להיות תלוי מחזור החיים של האובייקט. אם נסתכל על המסמכים של שיטה זו, אנו רואים כי מומלץ להשתמש הוא נוצר במיוחד כדי לשחרר משאבים ביעילות ללא מעורבות של אוסף פסולת. לעשות את זה. #finalize() AutoCloseable not to forget באשר לעקוב אחר מתי אובייקט באמת נמחק, Java מספקת חלופה: , אשר פותר את הבעיות המתוארות לעיל. java.lang.ref.Cleaner למען הבהירות, בואו לשחק סביב עם זיכרון Java ולכתוב קצת קוד לא מאובטח באמצעות finaliser: class ImmortalObject {  
    private static Collection<ImmortalObject> triedToDelete = new ArrayList<>();

    @Override  
    protected void finalize() throws Throwable {
        triedToDelete.add(this);
    }  
}
 כאן, אנו מחזירים כל מקרה של כי אספקת הזבל עומדת למחוק, אשר לא תשמח את ה-RAM שלך או את עצמך כאשר הוא מתנגש עם . ImmortalObject OutOfMemoryError כך נראית הקוד המתאים : Cleaner static List<ImmortalObject> immortalObjects = new ArrayList<>();

....

var immortalObject = new ImmortalObject();  
Cleaner.create()  
        .register(  
                immortalObject,  
                () -> immortalObjects.add(immortalObject)  
        );
 ראוי לציין כי אנו יכולים גם להקשיב למחוק כל אובייקט קיים. הפסק! האם רק למדנו מדוע הגישה הזאת היא בעייתית?זה נכון, אבל זה רק רע עם ניהול משאבים. לפעמים יישום Java עדיין צריך לדעת כי אוסף הזבל מוחק אובייקט. הכיתה עדיין חיה עד השם שלה, אך לא משום שאנחנו מוסיפים אותה לרשימה סטטית כאשר אנו מוחקים את הדוגמה. כאמור, כאמור, הקורא מתייחס ל עכשיו האובייקט לא ייחזור לתחייה כי אספקת הזבל לא תסיר את הדוגמה.זה יותר אידיומטי ב-Java ואין ניקרומנציה מעורבת. Runnable immortalObject Finalizers משמשים לעתים קרובות בעת עבודה עם אובייקטים שנוצרו באמצעות JNI איפשהו מחוץ לקוד Java, למשל, ב C++. תגיותNashornScriptEngine מעטים זוכרים שג'אווה הייתה פעם ממש בקצב עם JavaScript: JDK 8 הציג את המהדורה המובנית מנוע JS, המאפשר למפתחים להפעיל קוד JS ישירות מ-Java. נאשורין אנחנו יכולים ליישם את הפאזל הבננה הפופולרי הזה מבלי לעזוב את Java: new NashornScriptEngineFactory()
        .getScriptEngine()
        .eval("('b' + 'a' + + 'a' + 'a').toLowerCase();");
 אכן, זה דבר מגניב, אבל רק עד שאנחנו מבינים כי מפתחי Java צריכים לשמור על מנוע JavaScript. Nashorn לא יכול היה לעמוד בקצב עם האבולוציה המהירה של JavaScript, כמו גם פתרונות polyglot הופיעו, כגון GraalVM Polyglot. על Java 15 הוצאת Overboard בעוד Nashorn מיושם JavaScript על פני Java, Polyglot יוצר פלטפורמה מבוססת JVM שלמה התומכת בשפות רבות, כולל Java ו- JavaScript. מנהל בטיחות פגוש עוד טיימר ישן ששרד עד Java 17 – . SecurityManager בימים של אפלטים פראיים, כאשר ניתן היה להפעיל קוד Java ישירות בדפדפן, זה היה עמוד השדרה של אבטחת יישומים Java. SecurityManager 
 
 אפלט הוא תוכנית קטנה המופעלת ישירות בדפדפן ומסוגלת להציג אנטומיה, גרפיקה או אלמנטים אינטראקטיביים, אך פועלת תחת מגבלות קפדניות. אפלט הוא תוכנית קטנה המופעלת ישירות בדפדפן ומסוגלת להציג אנטומיה, גרפיקה או אלמנטים אינטראקטיביים, אך פועלת תחת מגבלות קפדניות. אבל הזמן עבר, פראי בסופו של דבר עבר מהדפדפנים למחשבים שולחניים, ולאחר מכן נעלם לחלוטין כפתרון. הוא נשאר ושימש לעתים קרובות ביישומים עסקיים. אפליקציות SecurityManager → אבל שום דבר לא נמשך לנצח, והגמרא באה . Java 17 removed its entire interior and left only the facade without any logic. If we look at the entry point for installing  נוכל למצוא רק את המושב: SecurityManager SecurityManager @Deprecated(since = "17", forRemoval = true)
public static void setSecurityManager(SecurityManager sm) {
    throw new UnsupportedOperationException(
             "Setting a Security Manager is not supported");
}
 כניסה למצב מסך מלא כניסה למצב מסך מלא איך עשו הוא פעל כשמירה פנימית של JVM אשר חסה פעולות מסוכנות פוטנציאליות ובדק אם לכל אלמנט של החבילה יש את הזכות לבצע פעולה כזו. SecurityManager מה בדיוק עשה הרשימה עצומה, אז אני מציע שנסתכל רק על הנקודות העיקריות: SecurityManager 
 
 
 
 
 
 גישה למערכת קבצים; קישורים לרשת; יצירת וסיום תהליכים; access to system properties; מניפולציה של שיעורים וחשיבה. זה עבד היטב בימים של אפלטים דפדפן, שבו היה צורך לשמור קוד לא אמין בתיבת חול, אבל עם הפיתוח של containerization, זה הפך מיושן. SecurityManager למרות היא נוצרה במקור עבור applets, היא שימשה גם בהקשרים אחרים. ב- PVS-Studio static analyzer שלנו, זה עזר לפתור בעיה משעשעת: אם initializer המעמד הסטטי בקוד שנבדק נקרא תהליך הניתוח ייגמר. לאפשר לנו לחסום פעולות כאלה בעת ניתוח שדות סטטיים, וזה משהו ששימנו מאוחר יותר עם ASM. SecurityManager תומך System#exit SecurityManager אגב, גם אם אפלטים כאמצעי הפסקו מוקדם יותר הם רק התחילו להסיר את ה-JDK. SecurityManager העולם משתנה, הגישה משתנה הוא עוזב SecurityManager לא בטוח ג'אווה מסירה את חוסר האבטחה. אולי התושב האגדי ביותר של הקבר הזה היה . sun.misc.Unsafe שיעור זה היה שער סודי לעומק JVM, שם הכללים הרגילים של השפה כבר לא היו בתוקף. ניתן לפתוח יישום Java עם . Unsafe SIGSEGV לדוגמה, ככה למשל: class Container {
    Object value; // (1)
}

// ✨ some magic to get unsafe unsafely ✨
Unsafe unsafe = ....;

long Container_value =
  unsafe.objectFieldOffset(Container.class.getDeclaredField("value"));

var container = new Container();

unsafe.getAndSetLong(container, Container_value, Long.MAX_VALUE); // (2)
System.out.println(container.value); // (3)
 ב The שדה (1), אנחנו קובעים 2) במקום ולנסות להוציא את הערך ל 3 ) value Long.MAX_VALUE Object System.out המכשיר הווירטואלי אינו אוהב את הטריק הזה, והוא נופל על השורה האחרונה כי מכיל פסולת במקום התייחסות אמיתית לאובייקט וזה רק דוגמה אחת של שגיאה כל כך קלה לזיהוי. value אבל מדוע הוסיף מנגנון מסוכן כזה ל-Java? הוא לא נולד כאנרכיסט, אלא כמושיע. ו (אנו נדבר עליהם מאוחר יותר), הספריות הסטנדרטיות היו צריכות לבצע פעולות ברמה נמוכה כגון ניהול זיכרון, פעולות אטומיות או חוסם חוט ביעילות. Unsafe VarHandle MemorySegment אבל איך אנחנו יכולים לעשות את כל הדברים לעיל אם השפה אוסרת עליך להסתכל מתחת לקופסא? הופיע כאילו מתאים לצרכים של Java. Unsafe internal Developers intended to use it only within Java—and it even had protection against gaining external access to its instance. But what happened in Java, not stayed in Java, and developers found a way to obtain  תראו את הקסם שמקבל "חוסר ביטחון" בדרך לא בטוחה: Unsafe var Unsafe_theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
Unsafe_theUnsafe.setAccessible(true);
Unsafe unsafe = (Unsafe) Unsafe_theUnsafe.get(null);
 אובייקט זה מאפשר לנו לפגוע במכונה הווירטואלית ככל שאנחנו רוצים. אבל אל תמהרו להאשים את המפתחים שהעזו להגיע למה שג'אווה ניסתה כל כך להסתיר מהם; שווה לזכור: גישה ל עזר לספריות רבות להיות יעילות יותר.לדוגמה, הספרייה הפופולרית של נטי לעבודה עם רשתות נאלצה להשתמש וכאשר הופיעה תחליף, נטי על זה Unsafe Unsafe החלפת על איזה סוג של תחליף אנחנו מדברים? אין אחד אלא שניים: 
 
 
 ה- Foreign Function & Memory API מחליף את פעולות הזיכרון. VarHandle API מחליף פעולות אטומיות. APIs אלה אינם מוגבלים פשוט להחליף שיטות מסוימות הם כלים חזקים לעבוד בבטחה עם פעולות ברמה נמוכה.לדוגמה, ה- Foreign Function & Memory API מאפשר לך להתקשר לתפקידים מקוריים מבלי להשתמש ב- JNI! Unsafe חוסר האבטחה של Java מתמוטט לאט לאט לשכוח, משאיר מאחור APIים חדשים, מעוצבים היטב ועוצמתיים שעושים את אותו הדבר מבלי לפחד מהתנאי. . SIGSEGV מדוע הקבר מלא? Java גדלה, מורידה רעיונות מיושנים, הופכת בטוחה יותר, נקיה יותר ופשוטה יותר.כל API חדש הוא לא רק "הוספת מודול נוסף", אבל סוגרים את הפערים הישנים בצורה מתוחכמת יותר. יחד עם זאת, "הקבר" הווירטואלי משחק תפקיד תרבותי חשוב: הוא רשום את האבולוציה של רעיונות והחלטות, מזכיר לנו את הנתיב שעברנו ויוצר את הקשר הדרוש לפיתוח הפלטפורמה המשמעותית.

Read My Stories

האודיו הזה מופק בשפת המקור של הסיפור!

קבר גדל של ג'אווה: APIs ישנים קבורים - ומה החליף אותם

About Author

הערות

תלו תגים

מאמר זה הוצג ב

Related Stories

The TechBeat: To Focus or Not Focus: How to Find the Right Product-Market Fit (3/10/2024)

The TechBeat: To Focus or Not Focus: How to Find the Right Product-Market Fit (3/14/2024)

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

The TechBeat: Python's Testing Playbook: Building Bulletproof Code (1/16/2024)

The TechBeat: To Focus or Not Focus: How to Find the Right Product-Market Fit (3/10/2024)

The TechBeat: To Focus or Not Focus: How to Find the Right Product-Market Fit (3/14/2024)

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

The TechBeat: Python's Testing Playbook: Building Bulletproof Code (1/16/2024)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps