so why a generic class MyClass cannot create an array of the K variable, claiming its generic array. like K[] myArray = new K[10]; in Java 21. if not already fixed in Java22, fix the Generic class instantiation unnecessary limitations. Every generic class is an Object and can be thus made into arrays. Higher rule applies. Just make an Object array and put each normal or generic class object into the Object array. then you have a permissible generic array. allow it to be fully type checked.
Would it make sense to be able to enable these boundry breaking configs at the module level in the module declaration? That way, you could for example set it so only the trusted JNI based wrapper library for a system service can use JNI.
@@ronpressler1362i have seen that but that is from the reverse perspective. That is "i declare i need x. Access". What i'm suggesting is kinda the reverse. Where i'm requiring my modules and granting them specific opens and exports, i'd like to be able to grant them these special privileged accesses, so i can have all these access controls specified in one place. Especially as it operates on the same logical level.
@@shadeblackwolf1508 Imagine the next step. You specified all these "module_foo opens to native;" and everything works. Then you (Bob) decide to publish your library and someone (Alice) starts using it. What will happen then? 2 choices. 1st choice: Alice will get this module_foo that breaks integrity and Alice doesn't even know about granted access because it's in the module of a dependent library from you, Bob. 2nd choice: All your grants will not affect anything for Alice using your lib. And it makes module-info dependable on usage.
It’s how the JDK is developed, and how they recommend library and framework authors navigate their increased release velocity: new features only in the latest release, stability and fixes for older releases. The implication being you can track the latest features and be only an LTS release behind maybe
A testing tool is somewhat of a special case that it is reasonable to allow since it doesn't run in production and I would be willing to provide special permissions when it is being used. I wouldn't want to offer the same for some random library that is part of my production runtime classpath.
Great talk. After seat-belts please do some more jet-packs (TCO!).
so why a generic class MyClass cannot create an array of the K variable, claiming its generic array. like K[] myArray = new K[10]; in Java 21. if not already fixed in Java22, fix the Generic class instantiation unnecessary limitations. Every generic class is an Object and can be thus made into arrays. Higher rule applies. Just make an Object array and put each normal or generic class object into the Object array. then you have a permissible generic array. allow it to be fully type checked.
The tone of speach is cool
Would it make sense to be able to enable these boundry breaking configs at the module level in the module declaration? That way, you could for example set it so only the trusted JNI based wrapper library for a system service can use JNI.
this has already been discussed in several JEPs, and ron has always voted against it. without him, it won't happen
See 39:39
@@ronpressler1362i have seen that but that is from the reverse perspective. That is "i declare i need x. Access". What i'm suggesting is kinda the reverse. Where i'm requiring my modules and granting them specific opens and exports, i'd like to be able to grant them these special privileged accesses, so i can have all these access controls specified in one place. Especially as it operates on the same logical level.
@@shadeblackwolf1508 Imagine the next step. You specified all these "module_foo opens to native;" and everything works. Then you (Bob) decide to publish your library and someone (Alice) starts using it. What will happen then? 2 choices. 1st choice: Alice will get this module_foo that breaks integrity and Alice doesn't even know about granted access because it's in the module of a dependent library from you, Bob. 2nd choice: All your grants will not affect anything for Alice using your lib. And it makes module-info dependable on usage.
Thank you for the great presentation.
great
Does anyone know what he means by the Tip & Tail development model?
It’s how the JDK is developed, and how they recommend library and framework authors navigate their increased release velocity: new features only in the latest release, stability and fixes for older releases. The implication being you can track the latest features and be only an LTS release behind maybe
Make sure to check the keynote th-cam.com/video/NV4v7KXKQ-c/w-d-xo.htmlfeature=shared&t=240
39:36 is he saying JNI will be removed entirely "in the end"?
No, it's just that you will eventually *have* to enable native access to use either JNI or some FFM features (now you'll only get a warning)
The value of jdk updates is there, but a bunch of companies will question themself whether theyre worth it.
Content starts at 10:02
First 10 minutes is really good content.
Mockito uses bytebuddy to instantiate an object without touching its constructor... Integrity is a long way off
Integrity needs exceptions. Stuff like Mockito needs to continue existing sas its rather useful.
A testing tool is somewhat of a special case that it is reasonable to allow since it doesn't run in production and I would be willing to provide special permissions when it is being used. I wouldn't want to offer the same for some random library that is part of my production runtime classpath.
Integrity is not about killing those things. It's about explicit permission from you on such backdoors.