4 ms·

Can someone please explain what this means to people not familiar with Java? I'm confused because I thought open source meant open source, as in "all of the so

Can someone please explain what this means to people not familiar with Java? I'm confused because I thought open source meant open source, as in "all of the source-code is available." What does 'open source' mean in this context, if not "open'??? When I read the title I thought it was a joke. Thanks and sorry for my ignorance, I'm a lowly perl hacker.

MartinCron 16y ago
A big part of OO languages is encapsulation. Private fields encapsulate state and private methods encapsulate implementation details. The intention there is to make the code more robust to restrict the way collaborating classes can interact with it. Example, if you have a type representing a game score, you may want to implement a public Increment() method instead of letting other types access the score value directly. The author of the post is pointing out the irony of people saying "this code is totally open" yet forcing you, ostensibly for your own good, to interact with it in a prescriptive way.
- roadnottaken 16y ago
  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.

MartinCron 16y ago

A big part of OO languages is encapsulation. Private fields encapsulate state and private methods encapsulate implementation details. The intention there is to make the code more robust to restrict the way collaborating classes can interact with it. Example, if you have a type representing a game score, you may want to implement a public Increment() method instead of letting other types access the score value directly. The author of the post is pointing out the irony of people saying "this code is totally open" yet forcing you, ostensibly for your own good, to interact with it in a prescriptive way.

roadnottaken 16y ago
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.