11

It seems like the SharedSecrets and JavaLangAccess classes from the sun.misc package were removed in Java 9.

Are there any replacements in Java 9 for the functionality provided by these classes?

Clashsoft
  • 11,553
  • 5
  • 40
  • 79
  • What exactly are you trying to do using these classes? – M A Oct 06 '17 at 19:58
  • 1
    Using the `newStringUnsafe` or `getEnumConstantsShared` methods, for example. – Clashsoft Oct 06 '17 at 20:00
  • 3
    The internal newStringUnsafe and getEnumConstantsShared should never be used by code outside of the JDK core classes. The supported APIs are of course String(char[]) and Class::getEnumConstants. – Alan Bateman Oct 07 '17 at 07:59

2 Answers2

6

Both the above classes are packaged in jdk.internal.misc package.

One way you can try and access them is by using the option

--add-exports <source-module>/<package>=<target-module>(,<target-module>)*

for your use case as :

--add-exports java.base/jdk.internal.misc=your.module

Note:- Disclaimer from JEP-261:Module System -

The --add-exports and --add-opens options must be used with great care. You can use them to gain access to an internal API of a library module, or even of the JDK itself, but you do so at your own risk: If that internal API is changed or removed then your library or application will fail.

Naman
  • 27,789
  • 26
  • 218
  • 353
  • 1
    That package appears to be [undocumented](https://docs.oracle.com/javase/9/docs/api/java.base-summary.html). Is there any guarantee it will be present in future Java releases? Or do developers assume the risk, just like they did when using sun.\* packages? – VGR Oct 06 '17 at 20:41
  • 3
    @VGR They might supposedly be removed in future releases I believe. Added the disclaimer from the JEP to specify that. – Naman Oct 06 '17 at 20:46
  • 6
    Developers should be strongly discouraged from using sun.*, jdk.internal.* and other JDK internal APIs. So I don't think it's a good idea to suggest the submitter move to use the new location of the internal shared secrets classes. – Alan Bateman Oct 07 '17 at 07:54
  • 2
    @AlanBateman I do second the point as already pointed out by VGR as well. Hence added the note to the answer as well. And I have just suggested *one way* on how this could be achieved not defining that as a must/should to be followed. And without a doubt, I would be glad to upvote an answer that could reflect details over the replacements to the mentioned classes and their functionalities. – Naman Oct 07 '17 at 07:56
2

According to Bug#JDK-8137056

In preparation for JEP 160, SharedSecrets and friend interfaces should be moved out of 'sun.misc' and located in a truly private package

And they are now available at jdk.internal.misc

Move SharedSecrets and friends to jdk.internal.misc

Ravi
  • 30,829
  • 42
  • 119
  • 173
  • Does that mean there is no requirement of exports for this package? – Mani Oct 07 '17 at 06:19
  • @ManiGrover if you are asking about `sun.misc` then, yes. And, as per my understanding, they won't exist actually. – Ravi Oct 07 '17 at 06:26
  • Asking about the moved package jdk.internal.misc? – Mani Oct 07 '17 at 06:27
  • 2
    @ManiGrover You have to, which mentioned in other answer. – Ravi Oct 07 '17 at 06:30
  • As an aside, wouldn't the concept of Shared Secrets be made obsolete by the implementation of modules? Don't modules allow you to provide special access paths between packages while preventing outside code from reaching it? Sort of a broader version of package-private access that allows a project to internally share code with itself without exposing implementation to other projects? – HesNotTheStig Sep 26 '18 at 21:57