this post was submitted on 24 Mar 2024
1021 points (99.2% liked)
Programmer Humor
19197 readers
1118 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Not a bug exactly, but about ten years ago I was working as an iOS developer and to get around a major problem introduced by the app designer, I made use of a "private method", which is something an app supposedly gets rejected for by Apple. I came up with a way of hiding it and had to sweat out the approval period before it went live. Ten years later that shit is still there; I'm sure the developers currently responsible for the app don't even know it's there. I normally comment my code with an eye to helping future programmers understand what's going on and why, but this hack was one where I even obscured the comments.
What does "private method" mean in this context? Did you make use of an undocumented endpoint of the iOS API?
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 😉
Yeah, same thing.