מודולריות בג'אווה 9: ערימה עם Project Jigsaw, Penrose ו- OSGi

מאמר זה מספק סקירה של הצעות, מפרטים ופלטפורמות שמטרתן להפוך את טכנולוגיית ג'אווה למודולרית יותר בג'אווה 9. אדון בגורמים התורמים לצורך בארכיטקטורת ג'אווה מודולרית יותר, אתאר והשווה בקצרה את הפתרונות שהוצעו, ולהציג את שלושת עדכוני המודולריות המתוכננים עבור Java 9, כולל ההשפעה הפוטנציאלית שלהם על פיתוח Java.

מדוע אנו זקוקים למודולריות של Java?

מודולריות היא מושג כללי. בתוכנה, זה חל על כתיבה והטמעה של תוכנית או מערכת מחשוב כמספר מודולים ייחודיים, ולא כעיצוב יחיד, מונוליטי. לאחר מכן משתמשים בממשק סטנדרטי כדי לאפשר למודולים לתקשר. חלוקת סביבה של בניית תוכנה למודולים נפרדים עוזרת לנו למזער צימוד, לייעל את פיתוח היישומים ולהפחית את מורכבות המערכת.

המודולריות מאפשרת למתכנתים לבצע בדיקות פונקציונליות במנותק ולעסוק במאמצי פיתוח מקבילים במהלך ספרינט או פרויקט נתון. זה מגביר את היעילות לאורך כל מחזור חיי פיתוח התוכנה.

כמה מאפיינים מאפיינים של מודול אמיתי הם:

  • יחידת פריסה אוטונומית (צימוד רופף)
  • זהות עקבית וייחודית (מזהה מודול וגרסה)
  • אותרו בקלות וגילו דרישות ותלות (מתקני זמן קומפילציה ופריסה סטנדרטיים ומטא-מידע)
  • ממשק פתוח ומובן (חוזה תקשורת)
  • פרטי יישום מוסתרים (אנקפסולציה)

מערכות הבנויות לעיבוד יעיל של מודולים צריכות לבצע את הפעולות הבאות:

  • תומך במודולריות וגילוי תלות בזמן הידור
  • הפעל מודולים בסביבת זמן ריצה התומך בפריסה ופריסה קלה ללא זמן השבתה של המערכת
  • יישם מחזור חיים של ביצוע ברור וחזק
  • ספק מתקנים לרישום קל וגילוי של מודולים

פתרונות מונחים-אובייקטים, מונחי-רכיבים ושירותים ניסו כולם לאפשר מודולריות טהורה. לכל פיתרון יש סט משונה של מוזרויות שמונעות ממנו להשיג שלמות מודולרית. בואו נשקול בקצרה.

מחלקות ואובייקטים של Java כקבוצות מודולריות

האם אופי מונחה האובייקטים של ג'אווה אינו עומד בדרישות המודולריות? אחרי הכל, תכנות מונחה עצמים עם ג'אווה מדגיש ולעיתים אוכף ייחודיות, כימוס נתונים, והצמדה רופפת. נקודות אלה הן אמנם התחלה טובה, אך שימו לב לדרישות המודולריות שאינן עומדות במסגרת מונחה האובייקטים של ג'אווה: זהות ברמת האובייקט אינה אמינה; ממשקים אינם מנוסחים: והשיעורים אינם ייחודיים ברמת הפריסה. צימוד רופף הוא שיטה מומלצת, אך בהחלט לא נאכף.

שימוש חוזר בשיעורים בג'אווה קשה כאשר נעשה שימוש לרעה בתלות של צד שלישי. כלים לזמן הידור כגון Maven מבקשים לטפל בחסרון זה. מוסכמות ומבני שפה לאחר מעשה כמו הזרקת תלות והיפוך שליטה עוזרים למפתחים בניסיונות שלנו לשלוט בסביבת זמן הריצה, ולעתים הם מצליחים, במיוחד אם משתמשים בהם במשמעת קפדנית. למרבה הצער, מצב זה משאיר את המטלה של יצירת סביבה מודולרית עד למוסכמות ומסגרות קנייניות קנייניות.

ג'אווה מוסיפה לתערובת גם מרחבי שמות של חבילות וראיית היקף כאמצעי ליצירת מנגנוני זמן קומפילציה וזמן פריסה מודולרי. אבל תכונות השפה האלה נעקרות בקלות, כפי שאסביר.

חבילות כפתרון מודולרי

חבילות מנסות להוסיף רמת הפשטה לנוף התכנות של Java. הם מספקים מתקנים עבור מרחבי שמות קידוד ייחודיים והקשרים של תצורה. למרבה הצער, עם זאת, ניתן לעקוף את מוסכמות החבילה בקלות, מה שמוביל לעתים קרובות לסביבה של צימודים מסוכנים לזמן הידור.

מצב המודולריות בג'אווה כיום (מלבד OSGi, שעליו אדון בקרוב) מושג לרוב באמצעות מרחבי שמות חבילות, מוסכמות JavaBeans ותצורות מסגרת קנייניות כמו אלו שנמצאו באביב.

האם קבצי JAR אינם מספיק מודולריים?

קבצי JAR וסביבת הפריסה בה הם פועלים משפרים במידה ניכרת את מוסכמות הפריסה הרבות המורשות שקיימות אחרת. אך לקבצי JAR אין ייחוד מהותי, מלבד מספר גרסה נדיר שמשתמש במניפסט .jar. קובץ ה- JAR והמניפסט האופציונלי אינם משמשים כמוסכמות מודולריות בסביבת זמן הריצה של Java. אז שמות החבילות של השיעורים בקובץ והשתתפותם במסלול כיתה הם החלקים היחידים במבנה ה- JAR שמעניקים מודולריות לסביבת זמן הריצה.

בקיצור, JARs הם ניסיון טוב למודולריזציה, אך הם אינם ממלאים את כל הדרישות לסביבה מודולארית באמת. מסגרות ופלטפורמות כמו Spring ו- OSGi משתמשים בתבניות ושיפורים במפרט JAR כדי לספק סביבות לבניית מערכות מסוגלות ומודולריות מאוד. אולם עם הזמן, גם כלים אלה ייכנעו לתופעת לוואי מצערת מאוד של מפרט ה- JAR לעזאזל!

מסלול קלאס / JAR לעזאזל

כאשר סביבת זמן הריצה של Java מאפשרת מנגנוני טעינה מורכבים באופן שרירותי של JAR, מפתחים יודעים שהם נמצאים בגיהינום שביל הכיתה או בגיהנום JAR . מספר תצורות יכולות להוביל למצב זה.

ראשית, שקול מצב בו מפתח יישומי Java מספק גרסה מעודכנת של האפליקציה ואריז אותה בקובץ JAR עם אותו שם בדיוק כמו הגרסה הישנה. סביבת זמן הריצה של Java אינה מספקת מתקני אימות לקביעת קובץ ה- JAR הנכון. סביבת זמן הריצה פשוט תטען שיעורים מקובץ JAR שהוא מוצא תחילה או שעונה על אחד מכללי מסלולי הכיתה הרבים. זה מוביל להתנהגות בלתי צפויה במקרה הטוב.

מופע אחר של גיהנום JAR מתעורר כאשר שני יישומים או תהליכים או יותר תלויים בגרסאות שונות של ספריית צד שלישי. באמצעות מתקני טעינה כיתתיים סטנדרטיים, רק גרסה אחת של ספריית הצד השלישי תהיה זמינה בזמן הריצה, מה שיוביל לשגיאות ביישום או בתהליך אחד לפחות.

מערכת מודולי ג'אווה בתכונות מלאות ויעילות אמורה להקל על הפרדת קוד למודולים מובחנים, מובנים בקלות ומצומדים באופן רופף. יש לציין בבירור תלות ולאכוף אותן בקפידה. מתקנים צריכים להיות זמינים המאפשרים שדרוג מודולים מבלי להשפיע לרעה על מודולים אחרים. סביבת זמן ריצה מודולרית אמורה לאפשר תצורות ספציפיות לתחום מסוים או לשוק אנכי, ובכך להקטין את זמן ההפעלה וטביעת הרגל של המערכת בסביבה.

פתרונות מודולריות לג'אווה

לצד תכונות המודולריות שהוזכרו עד כה, המאמצים האחרונים מוסיפים עוד כמה. התכונות הבאות נועדו לייעל את הביצועים ולאפשר הרחבת סביבת זמן הריצה:

  • קוד מקור מפולח : קוד המקור מופרד לפלחים מובנים ושמורים במטמון, שכל אחד מהם מכיל סוג ספציפי של קוד מהודר. מטרותיו כוללות דילוג על קוד שאינו שיטה במהלך טאטוא אשפה, בנייה מצטברת וניהול זיכרון טוב יותר.
  • אכיפת זמן בנייה: שפה בונה לאכיפת מרחבי שמות, גרסאות, תלות ואחרים.
  • מתקני פריסה : תמיכה בפריסת סביבות זמן ריצה מוקטן בהתאם לצרכים ספציפיים, כמו למשל בסביבת מכשירים ניידים.

מספר מפרטים ומסגרות של מודולריות ביקשו להקל על תכונות אלה, וכמה מהם עלו לאחרונה לראש ההצעות עבור Java 9. סקירה כללית של הצעות המודולריות של Java היא להלן.

277. JSR (בקשת מפרט Java) 277

נכון לעכשיו אינה פעילה היא Java Specification Request (JSR) 277, מערכת ה- Java Module; הוצגה על ידי סאן ביוני 2005. מפרט זה כיסה את רוב אותם אזורים כמו OSGi. כמו OSGi, גם JSR 277 מגדיר גילוי, טעינה ועקביות של מודולים, עם תמיכה דלילה לשינויים בזמן הריצה ו / או לבדיקת תקינות.

החסרונות ל- JSR 277 כוללים:

  • אין טעינה ופריקה דינמית של מודולים / חבילות
  • אין בדיקות זמן ריצה לגבי ייחודיות במרחב

OSGi (יוזמת שער שירות פתוח)

הוצגה על ידי הברית OSGI בנובמבר 1998, פלטפורמת OSGI היא התשובה המודולרית הנפוצה ביותר לשאלה הסטנדרטית הרשמית עבור Java. נכון לעכשיו במהדורה 6, מפרט ה- OSGi מקובל ונמצא בשימוש נרחב, במיוחד באיחור.

בעיקרו של דבר, OSGi היא מערכת מודולרית ופלטפורמת שירות לשפת התכנות Java המיישמת מודל רכיבים שלם ודינמי בצורת מודולים, שירותים, חבילות פריסה וכו '.

השכבות העיקריות של ארכיטקטורת OSGI הן כדלקמן:

  • סביבת ביצוע : סביבת Java (לדוגמה, Java EE או Java SE) שתחתיה יפעל חבילה.
  • מודול : כאשר מסגרת OSGi מעבדת את ההיבטים המודולריים של חבילה. מטה נתונים של חבילות מעובדים כאן.
  • מחזור חיים : אתחול, התחלה והפסקה של חבילות קורה כאן.
  • רישום שירותים : איפה חבילות מפרטות את שירותיהן שניתן לגלות על חבילות אחרות.

אחד החסרונות הגדולים ביותר ב- OSGi הוא היעדר מנגנון רשמי להתקנת חבילה מקורית.

JSR 291

JSR 291 היא מסגרת רכיבים דינמית עבור Java SE המבוססת על OSGi, ונמצאת כעת בשלב הסופי של הפיתוח. מאמץ זה מתמקד בלקיחת OSGi לג'אווה המיינסטרים, כמו שנעשה עבור הסביבה הניידת של ג'אווה על ידי JSR 232.

JSR 294

JSR 294 מגדיר מערכת מטא-מודולים ומאציל את ההתגלמות בפועל של מודולים הניתנים לחיבור (גרסאות, תלות, הגבלות וכו ') לספקים חיצוניים. מפרט זה מציג הרחבות שפה, כגון "חבילות-על" ומודולים הקשורים להיררכיה, כדי להקל על המודולריות. אנקפסולציה קפדנית ויחידות אוסף מובחנות הם גם חלק ממוקד המפרט. JSR 294 כרגע רדום.

פרויקט פאזל

Project Jigsaw הוא המועמד הסביר ביותר למודולריות ב- Java 9. Jigsaw מבקש להשתמש במבני שפה ותצורות סביבה כדי להגדיר מערכת מודולים ניתנת להרחבה עבור Java SE. המטרות העיקריות של פאזל כוללות:

  • מה שמקל מאוד על הגדלת זמן הריצה של Java SE ו- JDK למכשירים קטנים.
  • שיפור האבטחה של Java SE ו- JDK על ידי איסור גישה לממשקי API JDK פנימיים ועל ידי אכיפה ושיפור SecurityManager.checkPackageAccessהשיטה.
  • שיפור ביצועי היישומים באמצעות אופטימיזציות של הקוד הקיים והקלה על טכניקות אופטימיזציה לתוכניות.
  • פישוט פיתוח יישומים בתוך Java SE על ידי אפשרות לבנות ספריות ויישומים ממודולים שתרמו למפתחים ומ- JDK מודולרי
  • דרישה ואכיפה של קבוצה מוגבלת של אילוצי גרסאות

JEP (הצעת שיפור Java) 200

הצעת שיפור Java 200 שנוצרה ביולי 2014, מבקשת להגדיר מבנה מודולרי עבור ה- JDK. JEP 200 מתבסס על מסגרת ה- Jigsaw כדי להקל על פילוח ה- JDK, על פי פרופילי Java 8 Compact, לקבוצות של מודולים הניתנים לשילוב בזמן הידור, זמן בנייה ופריסת זמן. לאחר מכן ניתן לפרוס את שילובי המודולים הללו כסביבות זמן ריצה מוקטנות המורכבות ממודולים תואמי פאזל.

JEP 201

JEP 201 מבקש לבנות על פאזל כדי לארגן מחדש את קוד המקור של JDK למודולים. לאחר מכן ניתן להרכיב מודולים אלה כיחידות נפרדות על ידי מערכת בנייה משופרת המאכפת את גבולות המודולים. JEP 201 מציע תוכנית ארגון מחדש של קוד המקור בכל ה- JDK המדגישה את גבולות המודולים ברמה העליונה של עצי קוד המקור.

פנרוז

פנרוז ינהל יכולת פעולה הדדית בין פאזל ל- OSGi. באופן ספציפי, זה יקל על היכולת לשנות מיקרו-גרעינים של OSGi על מנת שחבילות הפועלות בגרעין המתוקן ישתמשו במודולי פאזל. זה מסתמך על שימוש ב- JSON לתיאור מודולים.

תוכניות לג'אווה 9

Java 9 הוא מהדורה מרכזית ייחודית עבור Java. מה שמייחד אותו הוא הצגתו של רכיבים וסגמנטים מודולריים ברחבי ה- JDK כולו . התכונות העיקריות התומכות במודולריזציה הן:

  • קוד מקור מודולרי : ב- Java 9, ה- JRE וה- JDK יוסדרו מחדש למודולים הניתנים לפעולה. זה יאפשר ליצור זמן ריצה בהרחבה שניתן לבצע במכשירים קטנים.
  • מטמון קוד מפולח : אמנם לא מתקן מודולרי למהדרין, אך מטמון הקוד המקוטע החדש של Java 9 יעקוב אחר רוח המודולריזציה וייהנה מכמה מאותן יתרונות. מטמון הקוד החדש יקבל החלטות מושכלות לקמפל קטעי קוד שנמצאים בתדירות גבוהה בקוד מקורי ולאחסן אותם לצורך חיפוש אופטימלי וביצוע עתידי. הערימה תחולק גם ל -3 יחידות נפרדות: קוד שאינו שיטה שיישמר לצמיתות במטמון; קוד בעל מחזור חיים בעל פוטנציאל ארוך (המכונה "קוד שאינו פרופיל"); וקוד חולף (המכונה "קוד פרופילי").
  • אכיפת זמן בנייה : מערכת הבנייה תשופר, באמצעות JEP 201, כדי להרכיב ולאכוף את גבולות המודולים.
  • מתקני פריסה : במסגרת פרויקט Jigsaw יסופקו כלים שיתמכו בגבולות המודול, האילוצים והתלות בזמן הפריסה.

שחרור גישה מוקדמת של Java 9

בעוד שתאריך השחרור המדויק של Java 9 נותר בגדר תעלומה, תוכלו להוריד מהדורת גישה מוקדמת ב- Java.net.

לסיכום

מאמר זה היה סקירה כללית של המודולריות בפלטפורמת Java, כולל סיכויים למודולריות ב- Java 9. הסברתי כיצד נושאים ארוכי שנים כמו גיהינום שבילי התורם תורמים לצורך בארכיטקטורת Java מודולרית יותר ודנתי בכמה מהמודולריות החדשה האחרונה. תכונות המוצעות עבור Java. לאחר מכן תיארתי והתקשרתי כל אחת מההצעות או הפלטפורמות של Java, כולל OSGi ו- Project Jigsaw.

הצורך בארכיטקטורת Java מודולרית יותר ברור. הניסיונות הנוכחיים נפלו, אם כי OSGi מתקרב מאוד. עבור מהדורת Java 9 Project Jigsaw ו- OSGi יהיו השחקנים העיקריים במרחב המודולרי של Java, כאשר Penrose אולי תספק את הדבק ביניהם.

סיפור זה, "Modularity in Java 9: ​​stacking with Project Jigsaw, Penrose, and OSGi" פורסם במקור על ידי JavaWorld.