{"id":16538,"date":"2023-08-01T16:07:56","date_gmt":"2023-08-01T14:07:56","guid":{"rendered":"https:\/\/vived.io\/?p=16538"},"modified":"2023-08-01T16:08:00","modified_gmt":"2023-08-01T14:08:00","slug":"nowe-jep-y-computed-constants-nowe-podejscie-do-ahead-of-time-i-stabilizacja-ffm-api-jvm-weekly-vol-144","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/nowe-jep-y-computed-constants-nowe-podejscie-do-ahead-of-time-i-stabilizacja-ffm-api-jvm-weekly-vol-144\/","title":{"rendered":"Nowe JEP-y: Computed Constants, nowe podej\u015bcie do Ahead-of-Time i stabilizacja FFM API – JVM Weekly vol. 144"},"content":{"rendered":"\n

1. Nowe JEP-y: Computed Constants, nowe podej\u015bcie do Ahead-of-Time & stabilizacja i FFM API<\/h2>\n\n\n\n

JEP draft: Foreign Function & Memory API<\/a><\/h3>\n\n\n\n

Zaczniemy od czego\u015b do\u015b\u0107 oczywistego, ale w dalszym ci\u0105gu interesuj\u0105cego.<\/p>\n\n\n\n

JDK 21 przynosi stabilizacje wielu d\u0142ugo oczekiwanych API, ale z jednym do\u015b\u0107 istotnym wyj\u0105tkiem – Foreign Function & Memory API. Ta kluczowa funkcjonalnos\u0107 Panamy uka\u017ce si\u0119 wy\u0142\u0105cznie jako Preview, ju\u017c trzecie. Wszystko wskazuje jednak, \u017ce r\u00f3wnie\u017c ostatniego – w ostatnich dniach opublikowany i zaktualizowany zosta\u0142 JEP Draft zawieraj\u0105cy ju\u017c specyfikacje finalnej wersji tego API. Wszystko wskazuje wi\u0119c na to, \u017ce kt\u00f3ra\u015b z najbli\u017cszych wersji Javy (mo\u017ce ju\u017c JDK 22) pozwoli nam na wygodne Sam JEP za\u015b skupia si\u0119 na finalizacji interfejsu API FFM poprzez wprowadzenie serii ulepsze\u0144, takich jak wprowadzenie atrybutu manifestu Enable-Native-Access<\/code>, umo\u017cliwiaj\u0105cego plikom JAR dost\u0119p do wybranych metod bez wymagania konkretnych flag. Dodatkowe ulepszenia obejmuj\u0105 tworzenie deskryptor\u00f3w funkcji C, bardziej zaawansowane wsparcie dla natywnych tablic o zmiennym rozmiarze oraz wsparcie dla wielu zestaw\u00f3w znak\u00f3w w natywnych stringach.<\/p>\n\n\n\n

JEP draft: Computed Constants<\/a><\/h3>\n\n\n\n

Programi\u015bci Java staj\u0105 przed dylematem mi\u0119dzy niezmienno\u015bci\u0105 a elastyczno\u015bci\u0105 inicjalizacji, szczeg\u00f3lnie w zarz\u0105dzaniu polami final<\/code>. Java wymaga bowiem, aby ta by\u0142a inicjalizowana w konstruktorze:<\/p>\n\n\n\n

class DeepThought {\n    final int theAnswer;\n\n    public DeepThought() {\n        value = ultimateQuestion();     \n    }\n\n    private int ultimateQuestion() {\n        \/\/ Expensive computation here\n        return 42;\n    }\n<\/code><\/pre>\n\n\n\n
Oczywi\u015bcie istniej\u0105 strategie takie jak class-holder idiom<\/strong>:<\/p>\n\n\n\n
class DeepThought {\n    private static class AnswerHolder {\n        static final int theAnswer = ultimateQuestion();\n\n        private static int ultimateQuestion() {\n            \/\/ Expensive computation here\n            return 42;\n        }\n    }\n\n    public DeepThought() {\n    }\n\n    public int getTheAnswer() {\n        return AnswerHolder.theAnswer;\n    }\n}\n<\/code><\/pre>\n\n\n\n
czy (w nieco bardziej skomplikowanych przypadkach) znany cho\u0107by z Effective Java, paskudny double-checked locking<\/strong>:<\/p>\n\n\n\n
class DeepThought {\n    private static class AnswerHolder {\n        static final int theAnswer = ultimateQuestion();\n\n        private static int ultimateQuestion() {\n            \/\/ Expensive computation here, takes 7.5 million years\n            return 42;\n        }\n    }\n\n    public int getTheAnswer() {\n        return AnswerHolder.theAnswer;\n    }\n}\n\nclass LazySingleton {\n    private static volatile LazySingleton instance;\n    private final DeepThought deepThought;\n\n    private LazySingleton() {\n        deepThought = new DeepThought();\n    }\n\n    public static LazySingleton getInstance() {\n        if (instance == null) {\n            synchronized (LazySingleton.class) {\n                if (instance == null) {\n                    instance = new LazySingleton();\n                }\n            }\n        }\n        return instance;\n    }\n\n    public int getTheAnswer() {\n        return deepThought.getTheAnswer();\n    }\n}\n<\/code><\/pre>\n\n\n\n
cho\u0107 u\u017cyteczne, maj\u0105 wady, takie jak dodatkowa z\u0142o\u017cono\u015b\u0107 po\u0142\u0105czona z utrat\u0105 mo\u017cliwo\u015bci \u0142atwej optymalizacji w czasie wykonywania. W przeciwie\u0144stwie do j\u0119zyk\u00f3w takich jak C# (z jego typem Lazy<T><\/code>):<\/p>\n\n\n\n
class DeepThought {\n    private static readonly Lazy<int> theAnswer = new Lazy<int>(() => UltimateQuestion());\n\n    private static int UltimateQuestion() {\n        \/\/ Expensive computation here\n        return 42;\n    }\n    \n    static int getTheAnswer() {\n        return theAnswer.get();\n    }\n}\n<\/code><\/pre>\n\n\n\n
czy Kotlin (kt\u00f3ry lazy<\/code> dla „leniwej” inicjalizacji):<\/p>\n\n\n\n
class DeepThought {\n    val theAnswer: Int by lazy { ultimateQuestion() }\n\n    private fun ultimateQuestion(): Int {\n        \/\/ Expensive computation here\n        return 42\n    }\n}\n<\/code><\/pre>\n\n\n\n
\u015bcis\u0142e wymogi Javy dotycz\u0105ce inicjalizacji p\u00f3l oznaczonych jako final<\/code> stwarzaj\u0105 wyzwania w odroczeniu inicjalizacji sta\u0142ych, zmuszaj\u0105c programist\u00f3w do obchodzenia ogranicze\u0144 j\u0119zyka .<\/p>\n\n\n\n
JEP draft: Computed Constants<\/a> wprowadza koncept Computed Constants, maj\u0105cych na celu zniwelowanie tej luki poprzez dostarczenie funkcji podobnej do konstrukcji znalezionych w j\u0119zykach takich jak C# i Kotlin. Sta\u0142e Obliczeniowe (nawet zgrabne t\u0142umaczenie) s\u0105 niemutowalne i s\u0105 gwarantuj\u0105 inicjalizowane co najwy\u017cej raz, oferuj\u0105c korzy\u015bci p\u00f3l oznaczonych jako final<\/code>, ale z wi\u0119ksz\u0105 elastyczno\u015bci\u0105 w czasie inicjalizacji.<\/p>\n\n\n\n
class DeepThought {\n    private static final ComputedConstant<Int> theAnswer =\n            ComputedConstant.of(() -> ultimateQuestion());\n\n    static int ultimateQuestion() {\n        \/\/ Expensive computation here\n        \/\/    (evaluation made before the first access)\n        return 42\n    }\n    \n    static int getTheAnswer() {\n        return theAnswer.get();\n    }\n}\n<\/code><\/pre>\n\n\n\n
Jak widzicie, rozwi\u0105zanie jest ca\u0142kiem eleganckie i \u0142adnie wpasowuje si\u0119 w ostatnie konwencje j\u0119zyka, takie jak Scoped Values. Wspominany ju\u017c oryginalny JEP zawiera te\u017c przyk\u0142ad dla kolekcji.<\/p>\n\n\n\n
\n