Mike Simmons

Anil Philip wrote:I don't understand what you are talking about!

They mean, when you reply to a post, try not to include the entire post that you are replying to.  Delete the parts that are not relevant.

---------------------------------------

This reply that I just did is an example of that.  I only included part of your post, the part I was replying to.  Let's call this Version 1  (above).

If I had not done that, it would have looked like this, Version 2 (below):

---------------------------------------

Anil Philip wrote:

Paul Clapham wrote:

Anil Philip wrote:

Campbell Ritchie wrote:Please don't quote the whole of the preceding post; that adds nothing and is liable to removal.

who are you referring to?

Let me just point out that the staff here can see all of the revisions which people have made to their posts. And they can revert them if they disapprove. I haven't reverted the one you're indirectly referring to yet.

I don't understand what you are talking about!

They mean, when you reply to a post, try not to include the entire post that you are replying to.  Delete the parts that are not relevant.

---------------------------------------

See, that's a longer post, but the extra words don't really help - they just waste space.  I deleted the parts we didn't need.  In this example, the whole thing is not that long, so it's not a big deal.  But the longer the post, the more helpful it is to delete extra copies of things that have already been posted.  Don't be like version 2, be like version 1.

Yep.  Except in the case of File, I wouldn't know what else to call it.  FileOrDrectory?  FileRelatedThing?  Yuck.  So File might simply be the simplest choice for something with no good answer.  Whereas  Class has a much better alternate name, Type.

Also, I should have said that Class represents classes, interfaces, primitive types, and, lest we forget, the void type.  Quite a lot for a "Class" to handle.

Campbell Ritchie wrote:There are only a few operators that associate right‑to‑left, or associate to the right. I am not sure, but as far as I remember, they are the unary operators, the conditional operator, and the assignment operators.

Also right-to-left are casts, and lambda and switch operators (->).

Campbell Ritchie wrote:Those JLS (=Java® Language Specification) links tell you, all with slightly different spellings, how those operators associate.

Yeah, those "slightly different spellings" are in fact quite difficult for most people to read.  I recommend the Operator Precedence in Java table for Sedgewick and Wayne's Princeton Intro to Programming course.  Someone even thoughtfully helped them update it for newer language constructs.

Campbell Ritchie wrote:That means that... x + y + z ... // Associates to the leftis equivalent to... (x + y) + z ...but... -++z ... // Associates to the rightis equivalent to... -(++z) ...

And this, in turn, means it is important that unary pre-increment and unary pre-decrement are right-to-left.

Mehmet Gunacti is correct, pre-unary operators are right to left, and this should be an errata.

Jeanne Boyarsky wrote:I don't consider it an errata because an interface is a type of class.

For what it's worth, I think Sun and Oracle have been pretty consistent in official documentation, that they differentiate between classes and interfaces.  Certainly in the JLS, never assume that "class" includes interfaces; it doesn't.  And that's generally true in most other official material as well.  The one big exception I can think of is the class Class, which represents classes and interfaces.  I think that was a mistake that they can't change now.  But if they had it to do over, they probably would have called it Type in the first place.

I'm not Tim, but I agree with his recommendation.  Effective Java is a great book, but it's not trying to teach you all the features of Java.  Or even, all the basics.  Rather, it focuses on fixing some of the most common errors that people make (assuming they already know the rules of the language).  Something like Core Java for the Impatient will be more comprehensive, better for ensuing you're not missing concepts.  I recommend Effective Java for the next book after that, though...

Chirayu Gangadkar wrote:How should I manage static imports for classes that contain both static and instance members in nested packages? Will we encounter such questions in the exam?

Well, you can only use a static import on static members.  You can't do any sort of import on members that are not static.  If you say "import static Foo.*" it will import all the static members, and have no effect on non-static members.  This is not a problem - lots of classes have both static an non-static members, and you can do static import on the static ones if you want to.  People do it all the time.  It's not really complicated.

I'm not really sure what you mean by "nested packages".  Java doesn't really have any notion of nesting, for packages.  It might seem reasonable to think that packages like

java.util
java.util.concurrent
java.util.concurrent.atomic

have some relationship - but they don't, really.  Except conceptually - we think of these packages as being related, and their names are similar.  But the compiler doesn't care how we think about it - those are just three separate packages, as far as the compiler is concerned.  Statements like
import java.util.*;
have no effect on other packages like java.util.concurrent and java.util.concurrent.atomic.  The "*" is a wildcard for classes and interfaces, not packages.  If you want to import from those other packages, you need to name them in separate import statements.

It sounds like you're worried about having to memorize or deal with too many method names at once.  While it's possible to use static imports to import every method under the sun, people don't generally do that.  It's generally a good idea to static import a member only when (a) you are using that member more than once, and (b) the code would look just as clear (or clearer) without the class name as it does with the class name.  So replacing Math.PI with PI is fairly safe.  But something like
import static java.util.List.of; import static java.util.Map.of;
would be a horrible idea, because "of" is too short and vague to make any sense on its own.  It's designed to be used with the type name, like List.of(x,y,z) or Map.of("one", 1, "two", 2).  And worse, it would often be ambiguous which method you are referring to, since two types use the same name.  Is "of(1, 2)" a refrerence to "List.of(1,2)" or to "Map.of(1,2)"?  The compiler will quickly complain about such ambiguities.  Many people prefer to not allow static import  with * in their code, because it's easy to accidentally import members which have confusing or ambiguous names.  But that's a code style issue, not enforced by the compiler (unless you create ambiguous code).

Tim Holloway wrote:Your error message explains it.

You have an "import" in a place where "import" is not permitted.

Rereading the error message, this is correct.  Although the comments claim these are two separate files, the error message suggests something else was going on - like maybe all that text was in Main.java.  I was assuming the comments were correct (and that was what should have been done) - but what was actually done at that point was a little different, it seems.

Right, we've all never seen a need for it, because System.out has (apparently) always come with auto-flush enabled.  Though that's not documented.

I agree with your assessment of Console being generally not worth the trouble.  Maybe if you know you're writing a command-line app, it's a little convenient to be able to write something like
String name = console.readLine("What's your name?");
rather than
System.out.println("What's your name?"); String name = scanner.readLine();
But the benefit seems minor at best.

The one really useful thing Console provides is a way to read a password without echoing it to a screen.  I don't know another way to do that in Java for a command-line app.

Um, reading what Chirayu posted, there was no issue with the placement of the import statement.  Those are two separate files, as indicated by the comments.  The "import static Foo.*;" is the first line of file Main.java.

Based on this, Campbell's later comments are on target - Chirayu is trying to import from class Foo, which is in the default package, and you can't import from the default package.  That's the problem.

Chirayu, if you try the same thing, but put the files in some package, it will compile.  Then your code shows that you can, indeed, do a static import with "import static Foo.*;" even if there are no static members of Foo to import.

Tim Holloway wrote:It would be pointless to include importing from the default package though. Aside from the fact that there's no special syntax for it, the default package would be the implicit location for unqualified classes not in the explicit package class path and therefore would need no explicit directive.

It would be pointless to do a regular import, yes, because you would still refer to the class by its simple name either way - there would be no advantage gained by importing.  But for a static import, there would be a slight advantage if it were allowed here (and if there were any static member to import).  You could go from
Foo.bar();
to
bar();
But that minor advantage was not enough for them to justify making an exception to the previous rule (made before static imports even existed): no imports from the default package.

I think the default package was just intended for beginners anyway.  If you're advanced enough to be using imports, it's time to put things in packages, as Gosling intended.

Well, every time that you care.  You probably don't actually need a flush on every println.  But the beauty of auto-flush is that you don't have to remember to do it, or make a call each time you care.  It just happens.

Yeah, it's kind of weird that they (a) never specified it, and (b) now change it, when it's something we implicitly rely on.  We can insert auto-flush if we need to using a static initializer:
 static {    // do this just once in the program, and do not close the new stream, ever    System.setOut(new PrintStream(System.out, true));  }
But yeah, I don't think I've ever had to do that.  It was always just set up with auto-flush, out of the box.  And still is, using System.out, but not through the Console.  So far...

Chirayu Gangadkar wrote:Thank you for the detailed explanation! That clarifies things—static imports apply to any member that can normally be accessed using ClassName.member.

Or for a method, ClassName.member(someArguments)

Chirayu Gangadkar wrote:Therefore, if I encounter a static import for something that is usually instance-based (like ArrayList.add()), I should immediately suspect a possible compilation error.

Yes, a static import of a non-static method like add() would definitely be an error.  Though many classes have both static an non-static members, so don't be shocked if you see a static import related to a class that is mostly non-static.  As long as the specific thing you're importing is static, it should work.

Chirayu Gangadkar wrote:Would you say that relying on method behaviour (mutating vs. non-mutating) and understanding class design is an effective strategy for identifying static methods in the exam? Or do you have any other quick tips to recommend?

I think that's probably a good way, yes.  If you know that add(x) is adding something to an instance, and we're not specifying an instance in the arguments, then it only makes sense that it's adding to the current instance, and then it must be non-static.  A static version would have had a signature like

addTo(list, x)

I don't know if it makes more sense to understand the behavior first and then work out that it must be static, or the other way around.  They're very much intertwined.  Knowing a method is static helps you understand its behavior.

There are also some methods that seem like they could have been static, because they do not use or modify any instance data, but are not declared that way.  The most common reason for this is for testability.  When testing other methods, we often like to override some of the methods that we are not testing, to force specific behavior from the method being tested.  If you've studied unit testing and method mocking, that's what this is about.  If not, don't worry now; it will come later.

I figure if the index is within the valid range, it will find it.  If not, then an IndexOutOfBoundsException is a good way to communicate that to the user.

It is a bit odd that they didn't provide a simple method for this.  The simplest way I know to do it is
MyEnum x = MyEnum.values()[index];
But you can make this a little nicer (and more performant) by putting a method in the enum yourself.  E.g.
 enum Suit {    SPADES, CLUBS, DIAMONDS, HEARTS;    private static Suit[] values = Suit.values();        public static Suit forIndex(int index) {      return values[index];    }  }
 You don't actually need to make a separate static field for values like I did; you could just call the values() method.  But that makes a defensive copy each time, which seems inefficient to some of us, so I optimized it by saving a single copy.

It's the same for System.out and PrintStream.  By default, a PrintStream does not auto-flush unless it's created with an auto-flush parameter set to true.  And the documentation for System.out does not say that that particular PrintStream will auto-flush, either.  At least, I don't think this is specified anywhere, and I can't find it with a simple search. So, it may well be that System.out does, usually, auto-flush - but we can't (at least, shouldn't) assume that it does.  That's not a good assumption to make.