This article is rated Stub-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing ??? This article has not yet received a rating on the project's importance scale.

The example of the "public" qualifier in Java and C# was written 17 years ago, and since then has received no support or citation. Even the editor who added it calls it a "matter of opinion". I suggest removing or rewriting.

The reason I am not rewriting it myself is that (1) my opinion is also just an opinion, although based on decades of professional experience, and (2) the example mentions Java and C# as having the same issue, and while I strongly disagree about Java, I don't know enough about C# to express an opinion. (Maybe the situation is superficially similar but fundamentally different in these languages?)

As a senior Java developer I find the example in the article not only wrong, but ironically the very opposite of true. The default package-private access in Java is in fact a very good example of the "convention over code" approach -- it is a reasonable choice for most methods:[1] keeps them simultaneously protected from other packages (other people's code) and accessible from unit tests (which are typically in a different class in the same package).

If it is true that in practice most methods use the "public" qualifier, that is simply because many programmers do not think much about security (and blindly adding "public" to everything allows them to get the work done), or are unfamiliar with the "convention over code" approach (do not realize that not using an explicit access qualifier is a valid choice, and often the right one). Also, in 2008, when the article was written, most Java developers were coming from C/C++ background, where the concept of packages (and thereby package-privacy) did not exist; but protection of code access on the package level was already supported since Java 1.2 by sealed packages, and since Java 9 by modules. ~2026-34635-33 (talk) 07:59, 12 June 2026 (UTC)Reply