Marco wrote:

How can you leave something on the classpath, when Top Modules are dependent on it ?

It is possible if top modules are not directly dependent on the jars on classpath. Top modules are directly dependent only on the automatic modules and automatic modules depend on non modular jars sitting on the classpath.
If a top module directly depends on a third party non modular jar, you have treat that jar as an automatic module.
That's how top down migration works.

Ira Go wrote:It is straightforward in other languages. Sometimes you need a byte as a byte, but because of Java's numeric promotion, the unsigned right shift is rendered useless. Personally, it does not bother me to add an extra &, but it is awkward and a simple single >>> is greatly missed. Oh well.

When you say greatly missed, I am assuming you have the need to use it quite often. I know where it can be used but personally I haven't had the need to use it even once in my 25 years of Java programming career. So I am curious to know the kind of situations you have used it in a real Java application. (This is a genuine question out of curiosity. Please don't take it otherwise.)

Sets don't allow duplicates irrespective of how you create them or which implementation you use.

Our OCA/OCP Java Certification whatsapp group is still active.

Happy to announce that we are working on OCP Java 17 / 21 Certification Exam Fundamentals, written by Hanumant Deshmukh and it is currently available for review. It is almost done and you can get the draft/review version for free if you just retweet this.

The book covers all Java 17 1Z0-829 Exam Objectives as well well as expected topics for the Java 21 1Z0-839 exam such as Virtual Threads, Sequenced Collections, Enhanced switch, and more.

Tim Moores wrote:

Thomas Roth wrote:Once is was enthusiastic about java certification. I still think the idea is great, but if the Exam creators don't change direction i think it will loose relevance, at least here in germany.

I've worked in the UK, Germany and the US for numerous companies, and I've never come across a situation where any Java exam was valued. It's an insignificant indication that an applicant may have some skill of interest, but the interview process will test the relevant ones in much more detail anyway. Obviously, that's anecdotal evidence, but I advise anyone considering spending time and money on this to ask themselves if there are maybe better ways of preparing for a tech career.

People have been cheating on exams ever since exams came into existence. There are factories that will do homeworks, essays, assignments, and Phd theses for you for God's sake! Nobody gets hired merely upon presenting a degree or a certification anyway.
A certification may be insignificant to the interviewer but it can be a very significant step in one's own learning process. What is you have learnt will be reflected in what you say in the interview.

Congratulations, Anil  and thank you for your feedback  
Happy to know our material was helpful in your preparation  

Congratulations, Eric!  
Don't let anyone devalue your achievement. There are many ways to cheat in any exam. People who want to cheat, cheat and pass the exam on the first try itself. There is no dearth of "dumps". People who want to learn, use all means to learn  

Mike Simmons wrote:
Neither do methods of PrintWriter.  The constructors of both PrintStream and PrintWriter throw IOException, but the methods do not.  

You are right. I must have confused it with some other class.

Mike Simmons wrote:
Note that you can connect a PrintWriter to an OutputStream, but you can't connect a PrintStream to a Writer.  So far.

A PrintWriter is, after all, a Writer, while PrintStream is not. A Writer adds encoding logic on top of a raw byte stream, so connecting a PrintStream to a Writer would be like putting the cart before the horse.

Anil Philip wrote:I am trying to understand the difference between the PrintStream and PrintWriter.
I see that they have identical methods.

They don't have identical methods. Specifically, methods of PrintStream do not throw IOException. PrintStream is more of a utility class (a hack) that is used primarily for System.in/out/err and has methods to print everything. PrintWriter, introduced later, otoh, is proper "Writer". You will notice other differences too in the JavaDoc.

Stephan van Hulst wrote:

Paul Anilprem wrote:But even a static method can't be marked final in an interface! One can only guess why.

What would it even mean for a static interface method to be final? Static interface methods aren't inherited in the first place.

It would mean the same that it does for a class. That it can't be hidden!

While a class implementing an interface may have to redefine a default method if it inherits the same from two interfaces, there is no such issue with a static method. But even a static method can't be marked final in an interface! One can only guess why.

You can definitely use an IDE if that helps you get started quickly if you are beginner. Using an IDE does feel more exciting than using the command line.
But if you decide to prepare for any Java certification, it is advisable to spend a good amount of time in learning how to do things from the command line for reasons explained here.

Mike Simmons wrote:
With this method, how would you ever get a V instance at all?  You have a stream of T, and you have a BiFunction to take a V and a T, and return a V.  Which means you need at least one V to use that function.  That's why you need an identity V instance, to start the reduction off.  

Right. I missed that.

Mike Simmons wrote:
And for parallel processing, each worker thread will use that same identity V instance to start off processing its own subset of elements, before combining later with the combiner.  And if any of those worker threads finds there are no elements for them to process (maybe it turns out that there's a filter() method that eliminates all the elements that might have been expected) you want the worker to not freak out and throw an exception, just return the identity value unmolested, so it can still be combined with the other results safely.

Right again.
thank you!

Campbell Ritchie wrote:
Another reason, maybe, for not throwing exceptions from an empty Stream is that exceptions are supposed to respond to something abnormal, and an empty Stream is regarded as a normal occurrence.

Yes, I agree with that. It seems reasonable.

What I am not sure about now is the reason behind having the following three methods in the Stream interface (i.e. the regular Stream interface and not the primitive stream interfaces such as IntStream) :

Optional<T> reduce(BinaryOperator<T> accumulator)

T reduce(T identity, BinaryOperator<T> accumulator)

V reduce(V identity, BiFunction< V,? super T,V> accumulator, BinaryOperator<V> combiner)

but not having:

Optional<V> reduce(BiFunction<V,? super T, V> accumulator, BinaryOperator combiner)

Paul Anilprem wrote:

Campbell Ritchie wrote:Isn't that what happens if you use the method without the identity parameter?

No, the one that doesn't take identity parameter takes one parameter of type BinaryOperator. A BinaryOperator restricts you to returning the same type as the type of the stream.
In fact, now I wonder why did they not design this method to accept a BiFunction like the other reduce method.

Because that would require a combiner, of course!

Campbell Ritchie wrote:Isn't that what happens if you use the method without the identity parameter?

No, the one that doesn't take identity parameter takes one parameter of type BinaryOperator. A BinaryOperator restricts you to returning the same type as the type of the stream.
In fact, now I wonder why did they not design this method to accept a BiFunction like the other reduce method.

Campbell Ritchie wrote:
The reason for not throwing an exception is that the designers didn't want Streams to fail to complete their runs.

Right. I should rephrase it as:
"So, it is not entirely implausible to think that multiplying the elements of an empty set of Integers should be undefined, in which case an RTE is more appropriate returning an empty Optional is more appropriate. "

What I am trying to get at is that returning Identity makes the method more rigid than what is warranted. It doesn't allow the the programmer to have an alternate path if there are no elements in the stream.  Given that there already are a buttload of methods, what's one more? Unless it is doesn't make sense logically.

No, that is not possible because Oracle has discontinued 1z0-815 and 1Z0-816 exams. Now, there is just one exam for OCP Java 11 and that is 1Z0-819. Similarly, there is just one exam for OCP Java 17 and that is 1Z0-829.

Paul Clapham wrote:And since the empty set is a set, the product of the empty set of integers has an integer value too.

Stephan van Hulst wrote:Man, I would be so upset if multiplying zero integers would return anything other than 1. Throwing an exception is what I would call "an insidious bug".

I was watching a video on Russel's paradox on youtube (https://www.youtube.com/watch?v=ymGt7I4Yn3k&t=698s) and at around 11.50, while explaining empty sets, he says that there is exactly one empty set and that two empty sets are really the same set.

If he is right, an empty set is as much a set of Integers as it is a set of monkeys. So, it is not entirely implausible to think that multiplying the elements of an empty set of Integers should be undefined, in which case an RTE is more appropriate.

Not really questioning the logic behind the reduce(U identity,  BiFunction<U,? super T,U> accumulator, BinaryOperator< U> combiner) because returning identity for an empty set is also valid from one perspective, but since they already have so many methods, they could have easily had one that didn't take an identity parameter and threw an RTE for empty stream as well i.e., reduce( BiFunction<U,? super T,U> accumulator, BinaryOperator< U> combiner).

(Fixed formatting)

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.

Will look into it. thanks.

@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.

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.

>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.

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.

I don't understand when something can be called "bloated". Java lets one do a LOT of things right out of the box. Obviously, code for all that has to exist somewhere. I mean, a Hello World program is not bloated, I guess, but it doesn't do anything useful either.

Honestly, I haven't seen any stack that can achieve all that a real world non-trivial Java app can with less code + config + runtime.  I am curious to know if there are better alternatives.

JLS Section 12.1:

The Java Virtual Machine starts execution by invoking the method main of some specified class or interface, passing it a single argument which is an array of strings.

Simon Roberts wrote:

Paul Anilprem wrote:

Anil Philip wrote:

If, as Stefan said, you can have both -p and -cp together, then can code in the module moduleName access the non-modularized jars in jarFolderName ?
java --module-path moduleFolderName --class-path jarFolderName --module moduleName/package.className

Yes, but only if it is an automatic module.

Except that the example here asks about "modularized jars in jarFolderName" -- and jarFolderName is on the classpath, *not* the module path, so they're not going to be automatic modules, and the above will not work.

You are right. I think I replied from my mobile and didn't check the actual command and posted the response based on just the world "jarFolderName". A jarFolderName has no business being on the classpath. You can only put a jarFolderName on the module path and the jars in that folder will become automatic modules (if they are not already explicitly named modules).

Now that I see the actual command in OP, I realize that the command is incorrect because putting a folder name containing a jar on the classpath doesn't make any sense. You need to put either a folder name containing exploded classes or put the jarFileName on the classpath.

You may go through release notes of each version. Skip the bugs fixes and focus on new features. Explore the features that interest you.