Jdbi: JDK9 मॉड्यूल पर सेट एक्सेसिबल को ब्लॉक करेगा

मैंने JDK 9-ea+136 पर नवीनतम JDBI स्नैपशॉट का परीक्षण किया है और दुर्भाग्य से, डिफ़ॉल्ट तरीके काम नहीं करते हैं।

java.lang.RuntimeException: java.lang.IllegalAccessException: access to public member failed: org.jdbi.v3.sqlobject.TestSqlObject$Dao.doesTransactionAnnotationWork()boolean/invokeSpecial, from org.jdbi.v3.sqlobject.TestSqlObject$Dao/2 (unnamed module @34b7bfc0)

    at org.jdbi.v3.sqlobject.DefaultMethodHandler.invoke(DefaultMethodHandler.java:63)
    at org.jdbi.v3.sqlobject.TransactionDecorator.lambda$invoke$0(TransactionDecorator.java:54)
    at org.jdbi.v3.core.transaction.LocalTransactionHandler.inTransaction(LocalTransactionHandler.java:173)
    at org.jdbi.v3.core.Handle.inTransaction(Handle.java:478)
    at org.jdbi.v3.sqlobject.TransactionDecorator.invoke(TransactionDecorator.java:57)
    at org.jdbi.v3.sqlobject.SqlObjectFactory.lambda$createInvocationHandler$18(SqlObjectFactory.java:241)
    at com.sun.proxy.$Proxy16.doesTransactionAnnotationWork(Unknown Source)
    at org.jdbi.v3.sqlobject.TestSqlObject.testTransactionAnnotationWorksOnInterfaceDefaultMethod(TestSqlObject.java:115)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
    at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
    at org.junit.rules.RunRules.evaluate(RunRules.java:20)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
    at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
    at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
    at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
    at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.IllegalAccessException: access to public member failed: org.jdbi.v3.sqlobject.TestSqlObject$Dao.doesTransactionAnnotationWork()boolean/invokeSpecial, from org.jdbi.v3.sqlobject.TestSqlObject$Dao/2 (unnamed module @34b7bfc0)
    at java.lang.invoke.MemberName.makeAccessException(java.base@9-ea/MemberName.java:915)
    at java.lang.invoke.MethodHandles$Lookup.checkAccess(java.base@9-ea/MethodHandles.java:1924)
    at java.lang.invoke.MethodHandles$Lookup.checkMethod(java.base@9-ea/MethodHandles.java:1864)
    at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(java.base@9-ea/MethodHandles.java:2013)
    at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(java.base@9-ea/MethodHandles.java:2007)
    at java.lang.invoke.MethodHandles$Lookup.unreflectSpecial(java.base@9-ea/MethodHandles.java:1539)
    at org.jdbi.v3.sqlobject.DefaultMethodHandler.invoke(DefaultMethodHandler.java:51)
    ... 38 more

अफसोस की बात है कि मुझे इसके लिए कोई समाधान भी नहीं दिख रहा है।

यह अजीब है कि इंटरनेट पर सभी लोग जो एक ही समस्या का अनुभव करते हैं, इस हैक को एकमात्र समाधान के रूप में समाप्त करते हैं। ऐसा लगता है कि JDK टीम ने "प्रॉक्सी में डिफ़ॉल्ट तरीकों" के उपयोग के मामले पर ध्यान नहीं दिया।

एचएम, इसके साथ काम कर रहा है:

Field field = MethodHandles.Lookup.class.getDeclaredField("IMPL_LOOKUP");
field.setAccessible(true);
MethodHandles.Lookup lookup = (MethodHandles.Lookup) field.get(null);
Class<?> declaringClass = method.getDeclaringClass();
return lookup.unreflectSpecial(method, declaringClass)
                    .bindTo(target)
                    .invokeWithArguments(args);

पता नहीं क्यों यह JDK9 के साथ काम करता है।

आहें। हमें शायद इसके बारे में ओपनजेडके देवों के साथ जल्द से जल्द पालन करना चाहिए ...

मैं पिछले कई दिनों से आरा-देव देख रहा हूं। इस सटीक उपयोग के मामले पर कुछ चर्चा हुई है, लेकिन मैं जो कह सकता हूं वह setAccessible को प्रतिबंधित करने के मूल्य पर एक उग्र चर्चा के सापेक्ष एक फुटनोट से अधिक है। ऐसा लगता है कि बहुत से लोग इस कदम से खुश नहीं हैं।

मैं इसे रिलीज ब्लॉकर्स से हटा रहा हूं। एक अपस्ट्रीम फिक्स जल्द ही प्रकट होने की संभावना नहीं है, और JDK9 अभी तक जारी नहीं किया गया है। अंतिम सुधार सार्वजनिक एपीआई को प्रभावित नहीं करना चाहिए।

मैंने इस बारे में jigsaw-dev मेलिंग सूची से संपर्क किया। http://jigsaw-dev.1059479.n5.nabble.com/Invoking-default-methods-from-a-Proxy-s-InvocationHandler-in-JDK9-td5714878.html।

हम देखेंगे कि इससे क्या निकलता है।

इसे कोर-लिब्स-देव पर फिर से टकराया।

यह हमारे लिए हाल के JDK9 बिल्ड में हल किया जाना चाहिए। कम से कम सिद्धांत में।

मूल रूप से, उन्होंने सुरक्षा जांच बदल दी ताकि कोई भी कर सके
एक डिफ़ॉल्ट विधि पर अप्रतिबंधित विशेष।

जब JDK9 लैंड करता है, तो हमें के आधार पर गतिशील रूप से दृष्टिकोण बदलना होगा
जावा संस्करण JDBI चल रहा है।

1 मार्च, 2017 को दोपहर 2:36 बजे, "स्टीवन श्लानस्कर" सूचनाएं @github.com
लिखा था:

इसे कोर-लिब्स-देव पर फिर से टकराया।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने सूत्र को लिखा है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/jdbi/jdbi/issues/497#issuecomment-283478025 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AACW5VBktrJYJatnsABFKay_-Ci5WD_Sks5rheTCgaJpZM4KCb6m
.

आह बिल्कुल। कोर-लिब्स-देव से:

लक्ष्य वर्ग के लिए निजी एक्सेस के साथ लुकअप ऑब्जेक्ट प्राप्त करने के लिए कंस्ट्रक्टर हैक को बदलने के लिए आप MethodHandles.privateLookupIn (JDK 9 में नया) का उपयोग कर सकते हैं।
मैंडी

यह सुनकर ताज़गी आ रही है! कम से कम हम JDK9 में इस गड़बड़ी से छुटकारा पा सकते हैं।

हाय मैंने अपने प्रोजेक्ट ओनर पर एक समान समस्या हल की है जो जेडीके 9 का उपयोग कर इंटरफेस पर डिफ़ॉल्ट विधियों को कॉल करती है, कृपया मेरी उपयोगिता वर्ग पर एक नज़र डालें, शायद यह आपकी मदद कर सके।

इस पर कोई शब्द? मैं JDK 9 के साथ JDBI का उपयोग कब कर पाऊंगा?

हम जावा 9 समर्थन में बहुत रुचि रखते हैं लेकिन स्पष्ट रूप से मैंने इसे अभी तक देखना शुरू नहीं किया है। पिछली बार मैंने देखा कि पारिस्थितिकी तंत्र को स्पष्ट रूप से अभी भी व्यवस्थित होने के लिए समय चाहिए, लेकिन शायद यह इस की प्राथमिकता को टक्कर देने का समय है।

यहाँ कुछ नया? JDK 10 कुछ दिनों से बाहर है...

Jdk9 में कोई स्पष्ट परिवर्तन नहीं है, सीधे 10 . पर जाना बेहतर है

ऐसा लगता है कि हमें कोड को ब्रांच करना पड़ सकता है और JDK9 में जोड़े गए नए तरीकों का लाभ उठाने के लिए प्रतिबिंब का उपयोग करना पड़ सकता है, 8 के लिए संगतता को तोड़े बिना। यहां आगे बढ़ने का सबसे तेज़ तरीका न्यूनतम परिवर्तन का पता लगाने की दिशा में एक पैच या कम से कम कुछ लेगवर्क जमा करना है। आवश्यक :) अन्यथा मैं इस सप्ताह इस पर एक नज़र डालने की कोशिश करूँगा।

और उम्मीद है कि १० तक पहुंचने के लिए अधिकांश काम वास्तव में ९ में होगा - मुझे नहीं लगता कि १० में कोई बड़ा बदलाव है, हम चीजों को तोड़ने की उम्मीद करते हैं, जबकि हम निश्चित रूप से ९ टूटी हुई चीजों को जानते हैं ...

मेरे पास इस पर एक शाखा है जिसे दोहरे निर्माण की आवश्यकता नहीं है, लेकिन इसे पहले ठीक करने की आवश्यकता है

ठीक है, मैं उस पर हैकिंग शुरू नहीं करूंगा।

इसे अगली जेडीबीआई रिलीज में समर्थित किया जाना चाहिए--शायद v3.2.0