I was working with some API which was used internally, and while looking at their code I found something like this:

public class Parent {
     public static class Child {

        private List<GrandChild> grandChildren;

        public static class GrandChild {
            private String name;

This hierarchy representation was used extensively, and it made creating some lists feel very counterintuitive, like for example List<Parent.Child.GrandChild.NewBorn>. Those representations were used to represent a JSON response. So this hierarchy matched the hierarchy returned in the response.

My main issue was that it was verbose and had a lot of duplicated code, for example, creating another class Parent2 would mean that we would have to copy the classes definitions of both Child and GrandChild to the new Parent2 class.

Would there be any benefit of using such representations?

Are there any downsides to this usage that I am not aware of?

Does it have any performance gains?

  • 3
    Newborn.Fetus.Zygote.Egg.PrimordialOoze.Hydrogen.BigBang Nah, why not. What could go wrong? :P I think you should just recognize this for what it is. A convention someone made up to help them with their limited understanding of hierarchies that went a little out of control. May 10, 2018 at 3:33
  • @CandiedOrange I just thought it might be a common convention that was helpful in some situations
    – engma
    May 10, 2018 at 5:09
  • 1
    I'm thinking probably not. May 10, 2018 at 5:13
  • 4
    As these things normally go, someone thought it was probably a really clever solution for their problem of representing a hierarchy. Also as these things normally go, "clever" rarely means smart.
    – Neil
    May 10, 2018 at 6:29

1 Answer 1


What you found is a good example of extremely poor coding style.

To answer your questions:

Would there be any benefit of using such representations?

Yes, if used within certain sane limits. For example, if you have a class named User to be stored into the database and you want a view that joins the user table with few other tables to create a fancy application-level view (not a database view!), you could have a class named User.FancyView. I find this better than having User and UserFancyView or worse, User and FancyView (which doesn't tell fancy view of which class), or myapp.user.User and myapp.user.FancyView (which creates a package just for one database table, meaning you will have a huge number of packages).

Are there any downsides to this usage that I am not aware of?

You already are aware of the downsides, which are really verbose object names and lots of duplicate code when copypasting. Because static inner classes are just regular classes that happen to reside within the code of another class, there are no other downsides.

However, if you have non-static inner classes, then the inner class object cannot exist without the outer class object.

Does it have any performance gains?

No, it does not. Static inner classes are just regular classes with a name having dot in them. They are stored on disk to separate .class files as well. So you don't even get a minor hard disk seek elimination performance gain, because they are stored in different .class files.

Overall, I probably use inner classes more than what other people use, including more anonymous inner classes. I like the feature of the Java language. This is a matter of coding style, and some style guides can prohibit using inner classes. However, I would stop nesting at a sane level. One level of nesting (User.FancyView) is good, two levels of nesting (User.FancyView.Helper) requires extremely good justification.

  • Yes so nesting 4 or 5 levels must be an extreme case which requires a ton of justification, and even then it would still be in desperate need for refactoring
    – engma
    May 11, 2018 at 2:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.