Announcement Announcement Module
No announcement yet.
Private beans? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Private beans?

    I am currently wiring several classes together that I would normally make package private and hide behind a facade. It appears that Spring requires these classes and their methods to be public.

    Is there a way to make classes/methods private and still use them with Spring? The idea is to minimize the classes that I am exposing to clients in a package, as the majority of the classes are specific to the implementation.

  • #2
    Default accessible class

    It appears you have to have public classes for IoC, although I'm not sure if this is by design.

    I'm just looking at adding a JIRA bug for this. Patching BeanUtils to change line 68:

    if (!Modifier.isPublic(constructor.getModifiers())) {
    if (!Modifier.isPublic(constructor.getDeclaringClass( ).getModifiers()) || !Modifier.isPublic(constructor.getModifiers())) {

    will at least allow creation of the bean, but there are a whole lot of regression test cases to check. Will get back with JIRA link if I add it.


    • #3
      The reason for the classes to be public is, that they are not instantiated from within their package but from Spring's factories. So they have to be public.

      I also had the issue with "normally package visible" types before. However I didn't find a solution either (except making the classes public of course).


      • #4
        It's strongly recommended to use public classes with public accessors for IoC: An important point about IoC is that you should be able to use the same classes outside an IoC container too, via direct instantiation - which requires the class and relevant methods to be public.

        That said, we do support protected/private constructors etc to some degree already, so I wouldn't mind adding support for package-level classes etc. Even if this is not recommended, I guess that Spring shouldn't constrain the choices for application developers here.



        • #5
          Here's the issue on JIRA

          Re: The reason for the classes to be public is, that they are not instantiated from within their package but from Spring's factories

          Actually, with reflection you can bypass all OO access restrictions (you can even directly modify private fields outside the class), but Spring is designed not to violate OO. Access to package level classes and members is quite reasonable for a container however. In a way it's more intrusive to force all public classes/methods. I think this is a good move.