3 ms·
I am skeptical about the "strong encapsulation" and in general, of all cases whey people tell me about something: "you don't need it, it's better for you to do
by avodonosov 5y ago
I am skeptical about the "strong encapsulation" and in general, of all cases whey people tell me about something: "you don't need it, it's better for you to do it other way".
Usually I know better what I need. There were cases when I needed to access the internals, e.g. fixing a prod issue.
A quote from Thinking Forth comes to mind:
> The newest traditional languages (such as Modula 2) bend over backwards to ensure that modules hide internal routines and data structures from other modules. The goal is to achieve module independence (a minimum coupling). The fear seems to be that modules strive to attack each other like alien antibodies. Or else, that evil bands of marauding modules are out to clobber the precious family data structures.
> This is not what we’re concerned about. The purpose of hiding information, as we mean it, is simply to minimize the effects of a possible design-change by localizing things that might change within each component.
- danogentili 5y agoFixing a prod issue by bypassing encapsulation and other programming practices sounds very much like accumulating technical debt. Encapsulation may be a lot more verbose, but it remains the best way to isolate software modules, to write better tests, and improve the overall reliability of software.
- avodonosov 5y agoIt was a one-time script, no debt.
- exabrial 5y agoIn that case, I think a Java Agent is better suited to your needs. We have one we wrote that will intercept a class load and hot-patches the byte code. This allows us to fix bugs in 3rd party software or the JDK itself until fixes can be released upstream and we don't wish to release an internal version of an artifact. Not something we use exclusively for obvious reasons, but it's a handy tool to have in the toolbox when we're forced up against a wall.
- avodonosov 5y agoI multiple cases that I had Java Agent would not help.
- vbezhenar 5y agoLibrary developers start depending on Java internals. Developer change internals, because they want to improve something. Library breaks. Users don't want to update to new Java because their code does not work. They want to break that chain, I guess. Also I think that you still can allow access to any internal class using --add-opens
- avodonosov 5y agoAlso, justifying it by security is not convincing. Encapsulation / decoupling and security are different things. The internals can anyways be accessed through core-dumps, /dev/mem, side-channels, etc. Yes, the strong encapsulation of JDK impl classes can create some inconveniences to an attacker. But I don't feel it's valuable enough to justify luck of access to the internals.