February 24, 2020
Hot Topics:

Java Language Security: Controlling Access to a Class

  • By Matt Weisfeld
  • Send Email »
  • More Articles »

Security and the default level access modifier

While the protected access modifier allows you to access attributes and methods within a package and a subclass, the default access modifier allows access to classes in the package. However, it restricts access to subclasses.

Access Levels
Modifier Class Package World
no modifier (default) Y Y N N

Listing 9 and Figure 6 illustrates this behavior.

Note: Because classes in the same directory are considered to be in the same package, the PlatinumChecking class was moved out of the Account directory. You can see this in the command line in Figure 5.
// CheckingAccount
package Account;

public class CheckingAccount {

   String accountNumber;                  // no access modifier (default)
   double accountBalance = 1000000.00;    // no access modifier (default)

   public double getAccountBalance() {

      return (accountBalance);



// PlatinumChecking
import Account.*;

public class PlatinumChecking extends CheckingAccount {

   public void PlatinumChecking() {

      accountBalance=0;    // subclass can't access


// AccountList
import Account.*;

public class AccountList {

   public static void main(String args[]) {

      PlatinumChecking myList = new PlatinumChecking();


Listing 9: Default Access using Inheritance & Packages

Click here for a larger image.

Figure 5: Default Access using Packages

Why would this be a security issue? By using the default access modifier, a subclass is prevented from altering an attribute in a parent class without going through the security constraints in that parent class. For example, rather than directly changing an attribute as follows:

      accountBalance=0;    // subclass can't access

The subclass would be required to call a method in the superclass to access/change the attribute.


Once of the great advantages that Java brought to the table when it was first introduced was that several levels of security were built directly into the language itself. In this article, you explore just one of those security concerns.

The concept of secure access levels is even more interesting when you consider that this type of security is enforced at the compilation level. In other words, if properly designed, security anomalies are caught prior to the creation of the bytecodes, so the application can never be executed. This not only makes the code more secure, it also assists the software development process itself.

There are several other compiler enforced security concepts to explore in future articles, as well as security issues enforced by the Virtual Machine.


About the Author

Matt Weisfeld is a faculty member at Cuyahoga Community College (Tri-C) in Cleveland, Ohio. Matt is a member of the Information Technology department, teaching programming languages such as C++, Java, C#, and .NET as well as various Web technologies. Prior to joining Tri-C, Matt spent 20 years in the information technology industry gaining experience in software development, project management, business development, corporate training, and part-time teaching. Matt holds an MS in computer science and an MBA in project management. Besides The Object-Oriented Thought Process, which is now in its second edition, Matt has published two other computer books, and more than a dozen articles in magazines and journals such as Dr. Dobb's Journal, The C/C++ Users Journal, Software Development Magazine, Java Report, and the international journal Project Management. Matt has presented at conferences throughout the United States and Canada.

Page 3 of 3

This article was originally published on December 8, 2006

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date