Also for sorting; you can writeNot any more.
Antonio Moretti wrote:. . . anonymous classes are often used in event handling . . .
Don't say, “static inner class.” Inner classes are implicitly not static, so call them, “static nested classes.” An inner class implicitly has a this reference pointing to an instance of its enclosing type, so it can only be created when there already is such an outer class instance. Look in books like Bruce Eckel's Thinking in Java. A static nested class is easier to use, especially if it isn't private. There are restrictions on access to instance members of the enclosing type, and an inner class has restrictions on having static members (not mentioned in your link).
a static inner class, an inner class or a method-local inner class.
What about a linked list? You should consider nested classes whenever there is an intimate relationship between the nested and enclosing classes. If you have a linked list, you usually have nodes too. Is there an intimate relationship between nodes and linked lists? Yes, a node IS‑A‑PART‑OF a linked list. There is no need for code to access individual nodes from outside the list.I am not sure I have got the generics correct.
I understand the mechanism and scope of these, but can't imagine ever needing to use one. . . .
PLEASE! This is JAVA! We don't do "not any more here". Leave that to Microsoft and the unwashed masses. The old practice does still work. It's just that given more elegant alternatives, there's no justification for doing it that way for new code - and some IDEs do have a "magic button" that will upgrade legacy code when you do maintenance on it.
Campbell Ritchie wrote:Not any more
Yes, you are right; the old ways still work.
Tim Holloway wrote:. . . We don't do "not any more here". Leave that to XXX . . ..
Hahahahahahaha! I shall wait for AM to post a new question about that.
Tim Holloway wrote:. . . . I'll leave it to Campbell to explain how recent developments factor into this strategy.
Jesse Silverman wrote:Now what would you pay? But WAIT, there's MORE!!
This would be too much info for most "Beginning Java" threads, but I know the OP has a strong thirst for Deep Knowledge of Java from their posting history.
Some more words about Encapsulation in Java.
Most good programmers realize the tremendous long-term benefits of Strong Encapsulation for projects that will get large, will live a long time, or both.
They are seeking it however they can get it.
Just how you can go about getting it has evolved a lot over Java's long history.
Modern Java now finally has the Java Platform Module System (sometimes still called Project Jigsaw).
Let me describe briefly the problem it solved and then I will leave it to you to work out in code that targeted Java 8 and earlier the places and ways and workarounds they used to try to deal with the fact that it wasn't there for us yet.
In Java, you will very commonly see all but the smallest projects split into many packages.
The idea was supposed to be that everything that used a default accessibility (unfortunately spelled "" because there was no way to say it aloud!) can be seen by all other classes in the same package.
Well, that worked, except that you will also see most larger packages split into "sub-packages".
But that doesn't mean what it seems to for people coming from other languages.
Let's take an example using some "famous" Java packages we should all know about:
It would be reasonable to think that maybe java.nio.file can access those package-friendly, default or "no access modifier specified" components of java.nio, right?
"But NOOOOOO..." as John Belushi would have said, as far as access to each other goes they might as well be in:
But let's say they need to access stuff in each other, not sure for the example I gave because I am rushing, but it is VERY common.
So what did we used to do?
Anything that code in ANY other package in the world needed to access, even a "sub-package" that we just learned gets no special access privileges compared to any other package in the world, needed to be marked public or it couldn't be accessed.
But now, ANYONE who knows the package name can access it. Oh, no!
Too bad. There wasn't really a solution to this, we tried to do things like calling it "something.unsafe", "whatever.internal" or, in places I worked (this is not a joke) "mypackage.donotuse".
Did people listen? Nooooo...
This caused much pain and suffering. We needed to make changes or improvements and couldn't because there were people accessing stuff we didn't want them to, but they did and now it was OUR problem!!
So now we have the concept of modules, a higher level of organization than packages.
Modules can decide what of the multiple packages they contain can be seen by the outside world, and, in fact, by which modules if we know of a "Safe List" of those.
So all the implementations and stuff we might want to change can be safely marked public in the code and used within the module, and, optionally, some things can be shown to all or just select users of the module.
This is all wonderful and terrific and you should learn all about it.
BUT...this only came along relatively very recently!! Java was around for no less than 22 years before we got these much-needed options for encapsulation.
All but the newest code projects you may see were started long before modules were actually usable (the Jigsaw project started way back but there were many difficult roadblocks to overcome before it actually saw the light of day and we could actually use it).
You will see many, many things in older code bases used to Desperately Seek Encapsulation for good reason that had no language support in Java for "modules" (JPMS is known both by the compiler and the JVM, it took a long time to get there but "the whole Java System" knows about, and respects them now)...
Some of these will involve Nested or Inner Classes.
Some of them would look neater or easier or cleaner implemented in other ways now that we know about and can use Modules to organize our code.
But what would we say "You should have waited another 16 years to release your popular open-source project so that it could use JPMS?"
So the point is, there are a lot of better ways to organize code and achieve great encapsulation in Modern Java using modules that we would be dumb not to avail ourselves of now.
But we can't fault others for not using what wasn't there yet for all the years before they had access to it.
Various different attempts to achieve such results might look clunky, awkward or complex BECAUSE THEY WERE. But it wasn't their fault.
Having a very full knowledge of Java includes recognizing those paradigms and idioms so as to be able to work productively with such code.
It would be a Very Bad Idea to rely on such clunky solutions in new code that doesn't have to run on Java 8 or before, but there are billions of lines of Java and probably millions of classes (and probably even packages and sub-packages) that were in production and getting used heavily before we had any of these nifty ways to do things.
So, it is a bit like hand-cranked cars, horses-and-buggies or churning your own butter, except that you will actually see these things in Real Life Java Code.
Especially regarding dependency management at runtime and encapsulation as enforced by the compiler and JVM, best practices in the old days and now for new code that knows it is on say, at least Java 11 look VERY differently.
I'm not sure how much of this directly touches on Nested and Inner Classes, but some of it indeed does, and we did bring up Encapsulation, the notion of "Okay, it is great. So how do I get it?" has changed a LOT between "Classical Java" and "Modern Java"...