Access restriction: The type 'Application' is not API (restriction on required library rt.jar)
The quick fix for the dreaded rt.jar access restriction lies within your IDE's settings:
- Navigate to Properties -> Java Build Path -> Libraries.
- Update the JRE System Library using either Alternate JRE (if the default isn't playing nice) or the Workspace Default JRE.
- Eradicate
rt.jarreferences sitting around your project from the previous JRE.
JavaFX users, beware:
- In case you have embraced Java 8, verify that JavaFX is lingering on the build path.
- If you have paced up with Java 11 or beyond, make sure your module-path is chock-full of JavaFX modules.
Decoding the access restriction
Why bother with this error?
When Eclipse decides to play police with internal classes, it sets up access restrictions. Even though you can see Application (public visibility), in reality, it's privately partying in an internal package.
Can you gatecrash to this party? In the JRE System Library settings, add a VIP pass to your class by adjusting the access rules. Set these rules to "Accessible". No more bouncers stopping you at the entrance!
Become friends with getApplication()
If you're stuck with com.apple.eawt.Application on a macOS and getting nowhere, remember it has moved to JDK 1.8. Use getApplication() to get an invite to enter the party.
Keeping JRE compatibility Did you recently switch to Java 8? Time to reflect this change in your Eclipse project settings. This goes for JavaFX projects too, where correct setup is like owning the perfect pair of dancing shoes.
Adjusting Eclipse settings
Alternate JREs can be your best friends
If the default JRE feels like a wrong puzzle piece, choose the “Alternate JRE” option in the “Java Build Path.” It's like turning the switch to a different JRE, which has a more welcoming party.
Priorities on the build path
Make a VIP list for your libraries on the Java Build Path. Put heavily used libraries on top. This way, the correct version of a class gets priority. VIP treatment, as it were!
Advanced users, listen up!
If auto-configuration isn't exciting, manually setting access rules can be an adrenaline rush. It's a signal to code maintainers (or your future self who has forgotten all about this) that your restricted API use is like a balcony jump at a party - dangerous, but thrilling!
When stuck, turn to the guidebook
If you are lost in the labyrinth of errors, deep-dive into the guides in the reference section. They are like the flashlight showing the way out of the maze of Eclipse-related riddles.
Avoiding future access restriction nightmares
Keep your dependencies in check
For projects with dependency chaos, opt for Maven or Gradle. They can manage access rules and ensure your project doesn't end up like a wild college party.
Avoid double trouble
Ensure you're not accidentally adding duplicate libraries to your project. This can be the equivalent of inviting two people who can't stand each other to the same party, and we all know how that ends...
Plugin development tips
Developing Eclipse plugins? Do remember to export the packages containing superclass types. It's like giving all your friends the address to the party.
The right error resolution
Export missing packages and change javafx access rules to Accessible for JavaFX specific issues. It's like bringing your own bottle when the party runs out of drinks!
Was this article helpful?