3 ms·

Thanks for the response, but can you not see the source code of these private methods? And wouldn't that allow you to re-write them yourself to behave however

Thanks for the response, but can you not see the source code of these private methods? And wouldn't that allow you to re-write them yourself to behave however you want?

brown9-2 16y ago
Yes. If you over-analyze the joke too much it becomes less fun :)
shasta 16y ago
I agree, this is a worrying possibility. Luckily, with a good reflection library, you can have other obfuscated parts of the code that check for such malicious tampering and abort.
mechanical_fish 16y ago
A sign of experience with open source: You become incredibly reluctant to hack directly on the source of a popular library. With great power comes great responsibility. In Drupal, for example, there is a saying: "every time you hack core (or a module you didn't write) god kills a kitten." In the spirit of open source, we probably borrowed that saying from some earlier project, because it is generally true. The standard Java String library is the same for everyone. [1] If you download Random Java Library X, and X works with the String library, you can probably be assured that X has been tested with the standard String library. As soon as you change one line of the library this is no longer the case. You must now face the possibility that your "minor" change will lead to side effects when combined with other things, and the responsibility for finding those side effects is now entirely yours. Plus, the sheer mechanical tedium of preserving your patch, making sure to apply it to every new version of the library as it comes out, relearning how the patch works every few months, porting the patch when it fails to apply cleanly to a new version, figuring out how to distribute your personalized package to others because they can no longer simply `apt-get` your package from the canonical repository, dealing with the fact that the standard docs and the published books might not cover your variation... Tools like Github have made all this stuff much easier, but it's still a bad idea to tinker with others' libraries without a good reason. The more typical advantage of open source is that you can read exactly what your library is doing, which makes it easier to figure out how to work around it without actually editing it. --- [1] Until it isn't. But at that point it will generally get a different version number, and an official release notice, and it will have a community that is aware of the change and will promptly coordinate to find and fix any new incompatibilities with other libraries.
gokhan 16y ago
And than you will accept that either you're now forked it and won't be able benefit from future releases as in drop in replacements, or you'll have a hard time implementing the same changes you did before over and over again for each new release.

Thanks for the response, but can you not see the source code of these private methods? And wouldn't that allow you to re-write them yourself to behave however you want?

brown9-2 16y ago

Yes. If you over-analyze the joke too much it becomes less fun :)

shasta 16y ago

I agree, this is a worrying possibility. Luckily, with a good reflection library, you can have other obfuscated parts of the code that check for such malicious tampering and abort.

mechanical_fish 16y ago

A sign of experience with open source: You become incredibly reluctant to hack directly on the source of a popular library. With great power comes great responsibility. In Drupal, for example, there is a saying: "every time you hack core (or a module you didn't write) god kills a kitten." In the spirit of open source, we probably borrowed that saying from some earlier project, because it is generally true. The standard Java String library is the same for everyone. [1] If you download Random Java Library X, and X works with the String library, you can probably be assured that X has been tested with the standard String library. As soon as you change one line of the library this is no longer the case. You must now face the possibility that your "minor" change will lead to side effects when combined with other things, and the responsibility for finding those side effects is now entirely yours. Plus, the sheer mechanical tedium of preserving your patch, making sure to apply it to every new version of the library as it comes out, relearning how the patch works every few months, porting the patch when it fails to apply cleanly to a new version, figuring out how to distribute your personalized package to others because they can no longer simply `apt-get` your package from the canonical repository, dealing with the fact that the standard docs and the published books might not cover your variation... Tools like Github have made all this stuff much easier, but it's still a bad idea to tinker with others' libraries without a good reason. The more typical advantage of open source is that you can read exactly what your library is doing, which makes it easier to figure out how to work around it without actually editing it. --- [1] Until it isn't. But at that point it will generally get a different version number, and an official release notice, and it will have a community that is aware of the change and will promptly coordinate to find and fix any new incompatibilities with other libraries.

gokhan 16y ago

And than you will accept that either you're now forked it and won't be able benefit from future releases as in drop in replacements, or you'll have a hard time implementing the same changes you did before over and over again for each new release.