Enthuware

This question:
and 1st option, which is correct answer:

The code will compile fine if both A and B are part of the same named module.
All permitted subtypes of a sealed type must either belong to the same package or to the same module.

Appropriate import statements are required(or using qualified names: extends p1.A, permits p2.B).
And public modifiers too.(sorry for forgetting)

OR,

Clearly A and B can't be compiled even if A and B are part of the same named module.
So 1st option is not correct answer.

1st option of enthuware.ocpjp.v17.2.3684 explains:
All permitted subclasses of a sealed class must belong to the same package (or belong to the same named module).
Since no module information is given in the problem statement, you should assume that there is no module in play here.

This question gives no module information too.
Maybe there is no problem of module, maybe in the same module.

and 2nd option is:
Both the classes must belong to the same package for the code to compile.
A and B have default access control.
So if A and B belong to the same package, they can be compiled.
2nd option is not incorrect.


In addition,

1st option explains:
All permitted subtypes of a sealed type must either belong to the same package or to the same module.

It is not appropriate.
As the explanation of this question, it should be based on JLS.
same named module, or beloging to unnamed modules, same package.


2nd option explains:
It is not necessary of both the classes belong to the same named module.

Sorry, I can't understand what it means.


And

With ETS Viewer, "Tools" > "Check for Question Bank Update" shows:
Message from Server:Current Major/Minor Version Numbers are: 1/14
The version you are currently using is: 1/18

Update check doesn't work.
and the version of previous 1z0-829.ets is 1/18 too.

In 2.3689:
1. You are right. The import statements must be there as well (or fqcn). Should be fixed.

2. You are right. In this case, the classes have default access and so both have to be in the same package otherwise it will not compile. The question was focusing on modules and overlooked this point. Should be fixed.

3. The JLS says this:

If a sealed class C is associated with a named module (§7.3), then every class specified in the permits clause of C's declaration must be associated with the same module as C, or a compile-time error occurs.

If a sealed class C is associated with an unnamed module (§7.7.5), then every class specified in the permits clause of C's declaration must belong to the same package as C, or a compile-time error occurs.

You can't have a package spanning multiple modules. So, if a subtype is in the same package then you don't have to worry about what module it is in because if it is in a module then the sealed class and this subtype will be in the same module and if it is not in the same module then both of them will still be in the same unnamed module.
If a subtype is in the same module as the sealed class, then there is no issue. You don't have to consider their packages.

Therefore, it resolves to the same statement written in the explanation: "All permitted subtypes of a sealed type must either belong to the same package or to the same module." This is correct. If you still think it is incorrect, please show a case which shows otherwise.

4. Whenever there is any change in the question bank, its version number is updated. However, we don't update the version number on the server for minor changes to prevent frequent update notifications. Now the version in the question bank file as well as version on the server both have been updated to 1.19. So you will see the update notification now.

thank you for your feedback!

At first,
1st option explains:
All permitted subtypes of a sealed type must either belong to the same package or to the same module.

As you said:

You can't have a package spanning multiple modules.

"same package" requires "same module".
So, "or to the same module" is redundant.

And if it were true, sealed superclass and permitted subclass in an unnamed module and different packages could be compiled(not the same package, but the same module).

It is against JLS:

If a sealed class C is associated with an unnamed module (§7.7.5), then every class specified in the permits clause of C's declaration must belong to the same package as C, or a compile-time error occurs.

Maybe:
All permitted subtypes of a sealed type must either belong to the same package or to the same named module.

In addition,
I think, modified explanation of 1st option is not incorrect, but it is not appropriate.

At first,
belong to the same package
> (A package must not be included in multiple modules)
>> same named module and same package (redundant)
>> same unnamed module and same package
or to the same named module

And,

JEP 409 says:

A sealed class imposes three constraints on its permitted subclasses:
1. The sealed class and its permitted subclasses must belong to the same module, and, if declared in an unnamed module, to the same package.
2. ....

and JLS says:

Co-location is desirable in any case because a sealed class hierarchy should always be declared within a single maintenance domain, where the same developer or group of developers is responsible for maintaining the hierarchy. A named module typically represents a maintenance domain in a modular codebase.

I think, the first thing required is "same module"(named if possible), and if in an unnamed module, "same package" is required furthermore.

Modified explanation is technically same result as JLS and it seems more simple.
But, I think, there are the differences in nuance.

OK, fair points. Will update.