Paul Anilprem

Enthuware Software Support
+ Follow
since Sep 23, 2000
Merit badge: grant badges
Cows and Likes
Cows
Total received
52
In last 30 days
0
Total given
3
Likes
Total received
607
Received in last 30 days
3
Total given
176
Given in last 30 days
2
Forums and Threads

Recent posts by Paul Anilprem

Naizak Aram wrote:
for example in this question there are 6 myFavoriteNumbers variables. do I have to check for spelling errors in each of them?
regards,


No, the exam questions do not try to trick you on that point. While you may see spelling mistake in  question the answer will not depend on that. In your example, you may see myFavoriteNumbers mistyped as myFavoriteNmbers but you can ignore that as a typo. If the correct answer is Compilation error, it would be because of something else.
@Anil, Just wanted to confirm if this explanation was displayed or not when you viewed the solution. If it was then I will take it as the explanation wasn't enough and will mark it as requiring improvement.

Mike Simmons wrote:But I believe it refers to the fact that a class or interface can define multiple nested types, in addition to defining a type for itself.


Yes, that makes more sense.

Stephan van Hulst wrote:A type can not be a subset of another type because types are not sets.


Oh but they are. That is how the JLS defines them. See section 4.5: A class or interface that is generic (§8.1.2, §9.1.2) defines a set of parameterized types.

Stephan van Hulst wrote:

ArrayList<? super Number> is not a class at all. It is a parameterized type.


It is not a class, indeed, but it is a type. Subclass and subtype are often used interchangeably for convenience because there is a lot of overlap between the two and that is the cause of confusion here, I think. They are technically different things.
Subtyping/supertyping and Inheritance are two different things. What constitutes a subtype/supertype relation is explicitly defined by the JLS in Section 4.10. This definition does include subclasses/superclassess/superinterfaces but only as one of the constituents.

The point is, it is true that ArrayList<? super Number> is a subtype of ArrayList<? super Integer> (and others) but that does not mean ArrayList<? super Number> inherits from ArrayList<? super Integer>. Java does not have multiple implementation inheritance and having multiple subtype/supertype relationships does not violate that. There is no contradiction.

Inheritance is real. Subtyping is "legal fiction".

(Fixed grammar typo)
Congratulations, Enrico! Don't worry about the score. 76% is way above passing. It is great for such a tough exam.

Campbell Ritchie wrote:Congratulations What is wrong with 65%? That sounds a good score.


Nah, 65% is below passing. No good  
If you are talking about enthuware.ocpjp.v17.2.3680, then the two options were updated last year to:

In bottom-up migration all classes and jars get moved to the module-path. (Marked as correct).

In top-down migration all packages/jars are moved to the module-path. (Marked as incorrect).

Antonio Berr wrote:
Because for the same reason, also this answer is not correct:
In bottom-up migration all modules are moved to module-path.


Bottom up migration does require all packages/jars to be converted into modules. Everything will be put on the module path in a bottom-up migration of an application. There is no scope for an intermediate stage in this approach where some part of the application is a module and some part is not.

Jan Paul Brasser wrote:I think this is confusing too, as I the endgoal of a migration can ever be an incomplete migration. No matter how I look at the Enthuware answer, it does not make sense from any perspective.


The whole purpose of top-down migration is to avoid converting third party libraries (over which you have no control) to modules. Therefore, only the application classes are converted to modules and put on the module path. The rest are left on the classpath.

But, obviously, the wording is still causing confusion, so we will make it clearer.

>So objects just have access to private members of other objects of the same type..?
No, they don't just have access to private members. They have access to public, protectec, and default members also.

>That seems like it has potential for issues.
You could say that but I don't think it really is an issue because it is still the developer/owner of the class who decides what members should be accessed and/or modified in any of its methods. It is not like someone else is able to modify fields of object of some one else's class.

In any case, that is just how Java does it.

2 weeks ago
Because private means private to the class and not to the object.
The code accessing a field is written in a class, so how would it work if it were private to an object? How would the compiler accept/reject the code because there is no object at compile time.
3 weeks ago
>Daylight saving time always starts on the second Sunday in March and ends on the first Sunday in November for the United States
I think it used to start on first Sunday of April and end on last sunday of Octorber ((a decade or so ago?).

But you don't need to remember these dates for the exam. If the answer depends on the when DST starts or ends, the problem statement will tell you when it starts/ends. You do need to know, for example, what happens to a ZonedDateTime object when you add an hour to the ZonedDateTime on this boundary.
A legal state means that the values of the instance fields of an object make sense as per the business logic that the class is meant to represent/model. To continue with Campbell's example, if you are modeling a real kettle using a Kettle class and using an int field named t for temperature in degree Celsius, does your business logic expect its value to be less than 0 or greater than 100? If no, then a Kettle object with t = -1 is in an illegal state even though an int can very well store a value of -1.

The legality is decided by you, the developer, and not by Java.
1 month ago
There has been a change in the behavior of instanceof from Java 17 to Java 21. In Java 17, the type expression on the right hand side of the instanceof operator, when it is used for pattern matching (but not when it is used just for type comparison), must be a subtype of the type of the variable given on the left hand side. Java 21 does not impose this restriction.

Stephan van Hulst wrote:
Wouldn't it be strange if I could become a licensed dentist just by studying for an exam and never doing any practice? Why do people think the same doesn't apply to programming?


Indeed it would be strange. But so would be if you could become a dentist just by practicing without studying for and passing an exam.
Both have their utility, imho.