Objective-C does not enforce method access (e.g. private methods) at the runtime level. If you are sufficiently determined, there are no restrictions on what methods you can call, unlike Java or C# (AFAIK).
Java absolutely lets you do that with Reflections. You’re not supposed to, and it’s painfully slow, but the JVM is only marginally smarter than javac (and that’s saying something) so there’s nothing actually stopping you.
I thought there was security code to stop that kind of thing. Granted, it’s been over 10 years since I’ve done anything with Java more than tinkering with Minecraft mods.
Java did have a Security Manager that can be used to prevent this sort of thing. The original thinking was that the Java runtime would essentially be an OS, and you could have different applets running within the runtime. This required a permission system where you could confine the permissions of parts of a Java program without confining the entire thing; which led to the Java security manager.
Having said that, the Java Security Manager, while an interesting idea, has never been good. The only place it has ever seen significant use was in webapps, where it earned Java the reputation for being insecure. Nowadays, Java webapps are ancient history due to the success of Javascript.
The security manager was depreciated in Java 17, and I believe removed entirely in Java 21.
Objective-C does not enforce method access (e.g. private methods) at the runtime level. If you are sufficiently determined, there are no restrictions on what methods you can call, unlike Java or C# (AFAIK).
Java absolutely lets you do that with Reflections. You’re not supposed to, and it’s painfully slow, but the JVM is only marginally smarter than javac (and that’s saying something) so there’s nothing actually stopping you.
I thought there was security code to stop that kind of thing. Granted, it’s been over 10 years since I’ve done anything with Java more than tinkering with Minecraft mods.
Java did have a Security Manager that can be used to prevent this sort of thing. The original thinking was that the Java runtime would essentially be an OS, and you could have different applets running within the runtime. This required a permission system where you could confine the permissions of parts of a Java program without confining the entire thing; which led to the Java security manager.
Having said that, the Java Security Manager, while an interesting idea, has never been good. The only place it has ever seen significant use was in webapps, where it earned Java the reputation for being insecure. Nowadays, Java webapps are ancient history due to the success of Javascript.
The security manager was depreciated in Java 17, and I believe removed entirely in Java 21.
If you are determined enough, it’s not that slow 😉