Mikalai Zaikin

public enum Season { WINTER { public void printHours() { System. out .println("9am-3pm"); } }, SPRING { public void printHours() { System. out .println("9am-5pm"); } }, SUMMER { public void printHours() { System. out .println("9am-7pm"); } }, FALL { public void printHours() { System. out .println("9am-5pm"); } }; public abstract void printHours(); }

There are no contradictions here.
You define enum (which is an "object blueprint") and tell -- "I have an abstract method".
Then you define inside the enum body all possible instances, and each of them is (a) concrete -- because JVM calls implicitly constructor and constructor may be called on concrete class (b) has an implementation of the abstract method
So, all are happy! 8-)
It would fail to compile if any of your declared instance did not implement "printHours", in that case it would remain abstract, and JVM would not be able to create an instance of particular enum constant.

You're right. It seems an error for me.

When in doubt -- try the compiler 8-)

DoubleConsumer dc = ... ; dc.accept(1.0); Consumer<Double> c = ... ; c.accept(1.0);

These both are valid.

With Oracle any requirement can be legal 8-)
I personally get this warning when took 1Z0-817 proctored exam.

Basically, your face must be fully open and visible to the camera during the whole exam: you may not scratch your head, cover your mouth with your hand -- you will get a warning from the proctor.

The JEP 286 clearly says var is not a "type" or "keyword", rather "reserved type name"

Some of the reasons:
* because IDE will spot many non-compile problems right off, while lots of questions test specifically compilation problems
* because you won't learn command line arguments for java and javac
* because you won't learn modules layout (where put module definition, how to package module manually, etc.)
* because IDE performs auto code completion for you and methods lookups
* because IDE performs adds import statement for you, while you must know some packages names
* because IDE will wrap problematic code in try catch block and you won't bother if the code safe or not (distinguish checked v.s. runtime exception)
* some more reasons, but I am tired to list...

My understanding is if the source code (which normally is a single snippet potentially containing several classes/interfaces) does not contain import/package statements, then they are assumed to be valid and that part of the code is fine.
However, if the package/import statement[s] is present in the source code, and the question contains "Compilation fails" option, then question tests package[s] visibility and import rules must be analyzed.

Sorry, could you clarify why may consider option E correct?
The book says option D correct, you also seem tested option D and it works.

Maybe there is some confusion caused by directories names, and/or module/package names?
Try then something like


modRoot
  |  
  | - module-info.java
  |
  zoo--
         |
         staff--
                 |
                Vet.java


and

module moduleA {    exports zoo.staff; }


Once JVM sees "exports zoo.staff" it will start searching that package starting the directory where module definition is located, and if you put module-info.class inside the "zoo" directory, JVM modules resolver will not be able to find the first part of the package -- "zoo" directory. Exporting of non-existing packages is not allowed.

HTH,
MZ

No one questions labels presence, they are in scope, from what I understand (?) the question was about obsolete (not used) labels 8-)

Hello,

I think you might see only 1 question on exam testing 2 dimensional loops, and I doubt you will see abandoned labels, these do not make sense.

So, the answer is: no, you won't see code like that with abandoned labels.

In general, the error happened because in Java you may not run code (java) with Java version smaller than version of Java used for compilation (javac). The opposite is allowed. I.e.

compile with Java 13, run with Java 11 => fail
compile with Java 11, run with Java 13 => success

P.S. Welcome to CodeRanch ! 8-)

I can guess you compiled .java with Java 13 (Java SE 13 = 57) and now you use jar utility from Java 11 or <13.

You can try these commands to investigate:

where java
where javac
where jar
javac -version
java -version

and to run bytecode we use "java filename.class".

That's obviously an error, it's Java 101, IIRC this was tested on some very early SCJP exams, but then removed from scope, as very easy question (IMHO)

It's because VisibleClassTest in java VisibleClassTest is a class name, not a file on filesystem.
To remember it better, imagine you have org.mycompany.VisibleClassTest class. There's no such file as org.mycompany.VisibleClassTest.class