3

In my experience, package-private visibility for classes in Java is turning out to be redundant.

Package-private visibility seems to be based on the premise that a class which is almost-privately used by another class is likely to be kept in the same package. Often this is not the case. Is someone exploring an improved access modifier/alternate mechanism?

Problem with trying to use package-private visibility:

  • We are tempted to put functionally unrelated classes in same package to get this benefit

Problem with using public instead:

  • APIs get polluted. Once a library Jar is imported, client sees several other public classes that he has no need to be worried about
  • From a coding-standards perspective, there is no easy way to ensure that short-circuit calls are not done by developers on time crunches (By short-circuit calls I mean method calls that bypass a layer (like from Servlet direct to DAO bypassing the bean/BO)

The current workaround:

  • To dissuade short-circuit calls we usually package different parts of the application into several JARs and ensure only the respective JARs are available in the build environment for each build. (For example server.jar would not be available while compiling swing client classes. Only client classes and common.jar would be available.)

Questions:

  1. Wouldn't it be useful to come up with a new visibility modifer/alternative?
  2. Is something along these lines already in pipeline?
  3. Are frameworks like Spring/Guice sufficient replacements?
Teddy
  • 4,009
  • 2
  • 33
  • 55
  • Make every field, method, and class either private or public, with the exception of classes that are designed to be extended. – Gilbert Le Blanc Jun 02 '14 at 14:48
  • @GilbertLeBlanc This question also gives some details of the same situation: http://stackoverflow.com/questions/8647565/package-and-visibility – Teddy Jun 02 '14 at 18:24

2 Answers2

1

  1. Yes, I think it would be useful.

  2. I think what you are looking for is project jigsaw which will eventually make it into Java 9. I am not an expert on this, but you can have a look at the following questions and their answers to get an idea:

  3. I don't have experience with these frameworks.

Community
  • 1
  • 1
Axel
  • 13,939
  • 5
  • 50
  • 79
  • For (2) Jigsaw seems to be modular and plug-and-play solution for integrating large number of modules. My question is more about implementation of a single module where there is clearly public-to-my-classes but not public-to-client kind of classes. – Teddy Jun 02 '14 at 18:29
  • You are right in that OSGi seems to be the closest alternative as of now. Although I wonder if it makes sense to use OSGi just for the sake of making my modules self-contained, modular and hiding the internals. OSGi seems to come with a lot more baggage. – Teddy Jul 30 '16 at 14:42
1

Looks like a feature from scala. There is a scope for access modifiers. I've found this tutorial useful.

Method can be private in scope of some package

package company.module.domain

class Example {
  private[module] def moduleMethod = ???
  private[domain] def domainMethod = ???
}

In this example moduleMethod is available everywhere inside package module and its child packages (like domain). Method domainMethod is visible only in domain package and invisible outside.

Unfortunately this functionality is not compatible with java and those restriction are compiled to byte code with lost of restrictions i.e. to public

Nazarii Bardiuk
  • 4,272
  • 1
  • 19
  • 22
  • From the tutorial that you had linked "With qualifiers, and because Scala understands nested packages, you have more fine-grained control over accessibility in Scala than in Java." Excellent design in Scala. – Teddy Jul 30 '16 at 15:53