Jdbi: JDK9는 모듈에서 setAccessible을 차단합니다.

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에서 작동하는 이유를 모르겠습니다.

한숨을 쉬다. 우리는 아마도 이것에 대해 나중에 openjdk 개발자에게 후속 조치를 취해야 할 것입니다...

나는 지난 며칠 동안 jigsaw-dev를보고있었습니다. 이 정확한 사용 사례에 대한 몇 가지 논의가 있었지만 setAccessible 제한의 가치에 대한 격렬한 토론과 관련된 각주에 더 가깝다고 말할 수 있습니다. 많은 사람들이 그 움직임에 만족하지 못하는 것 같습니다.

릴리스 차단기에서 이것을 제거하고 있습니다. 업스트림 수정 사항이 곧 나타나지 않을 것으로 보이며 JDK9는 아직 릴리스되지 않았습니다. 최종 수정 사항은 공개 API에 영향을 미치지 않아야 합니다.

이에 대해 jigsaw-dev 메일링 리스트에 연락했습니다. http://jigsaw-dev.1059479.n5.nabble.com/Invoking-default-methods-from-a-Proxy-s-InvocationHandler-in-JDK9-td5714878.html.

우리는 그것에서 무엇이 나오는지 볼 것입니다.

core-lib-dev에 다시 부딪쳤습니다.

이것은 최근 JDK9 빌드에서 해결되어야 합니다. 적어도 이론상으로는.

기본적으로 보안 검사를 변경하여 누구나
기본 메소드에 대한 unreflectSpecial.

JDK9가 출시되면 다음에 따라 접근 방식을 동적으로 전환해야 합니다.
Java 버전 JDBI가 실행 중입니다.

2017년 3월 1일 오후 2시 36분, "Steven Schlansker" [email protected]
썼다:

core-lib-dev에 다시 부딪쳤습니다.

—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/jdbi/jdbi/issues/497#issuecomment-283478025 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AACW5VBktrJYJatnsABFKay_-Ci5WD_Sks5rheTCgaJpZM4KCb6m
.

아, 그래. core-libs-dev에서:

MethodHandles.privateLookupIn(JDK 9의 새로운 기능)을 사용하여 생성자 해킹을 대체하여 대상 클래스에 대한 비공개 액세스로 조회 개체를 가져올 수 있습니다.
맨디

듣기만 해도 상쾌합니다! 최소한 JDK9에서는 이 혼란을 없앨 수 있습니다.

안녕하세요 JDK9를 사용하여 인터페이스에서 기본 메소드를 호출하는 프로젝트 소유자 에서 유사한 문제를 해결했습니다. 제 유틸리티 클래스를 살펴보십시오. 도움이 될 수 있습니다.

이것에 대한 어떤 말? 언제 JDBI를 JDK 9와 함께 사용할 수 있습니까?

우리는 Java 9 지원에 매우 관심이 있지만 솔직히 아직 조사를 시작하지 않았습니다. 마지막으로 생태계가 아직 정착할 시간이 필요하다는 것을 분명히 보았지만, 아마도 이것의 우선 순위를 부딪힐 때일 것입니다.

여기에 새로운 것이 있습니까? JDK 10이 며칠 만에 없어졌습니다 ...

jdk9에는 눈에 띄는 변화가 없습니다. 10으로 바로 이동하는 것이 좋습니다.

코드를 분기하고 리플렉션을 사용하여 8과의 호환성을 손상시키지 않고 JDK9에 추가된 새로운 방법을 활용해야 할 수도 있습니다. 여기서 앞으로 나아가는 가장 빠른 방법은 패치를 제출하거나 최소한의 변경 사항을 파악하기 위한 약간의 노력을 기울이는 것입니다. 필요합니다 :) 그렇지 않으면 이번 주에 이것을 살펴보려고 합니다.

그리고 바라건대 10에 도달하는 작업의 대부분은 실제로 9에 도달하는 것입니다. 10에 큰 변화가 없다고 생각합니다. 우리가 깨뜨릴 것으로 예상하는 반면에 9는 확실히 깨졌습니다...

이중 빌드가 필요하지 않은 분기가 있지만 먼저 수정해야 합니다.

알겠습니다. 그러면 해킹을 시작하지 않겠습니다.

이것은 다음 Jdbi 릴리스(아마도 v3.2.0)에서 지원되어야 합니다.