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
606
Received in last 30 days
3
Total given
176
Given in last 30 days
3
Forums and Threads

Recent posts by Paul Anilprem

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.

1 week 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.
1 week 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.
2 weeks 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.
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.

1 month ago

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 ?


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.
1 month ago
Hi Patrick,
I replied to you via purple mooseage (PM). Please check it.

thank you,
Paul.

Stephan van Hulst wrote:you only need to take two minutes to write a module descriptor to give your module a name and list its dependencies on other modules.


That's a red herring, imho. Time required to write/update a module description ignores the times required to "reload" the module knowledge base into your brain. Unlike regular java code that I write every day, module-info.java is used rarely and that makes me forget its operating parts.

It is like if I have to create an executable jar, I still have to look up whether it is Main-Class or Mainclass or something else that I need to add to meta-inf. Is it meta-inf.mf or something else?

It is the looking up part and not the writing part that dissuades programmers from using modules. Most projects are used internally anyway and rarely do teams care about modules, tbh. There is no time for them.

Having said that, I think the module functionality is pretty neat for what it is meant to achieve.

Anil Philip wrote:

But why not? if you left out the -p then wouldn't it regress to the old-style prehistoric invocation using classpath?


Already answered by Mikalai above:


1) When you have module options in the command line, the program runs as a modular