Paul Clapham

There's always errors in published works. (We have a lot of posts on this site discussing those.) It's possible that this is one of them. I don't have the book so I can't comment about that, though.

Could you also post the question you're asking about and the possible answers?

(Originally you posted a download of the entire book. I don't know whether that counts as piracy, maybe not, but it's certainly very hard to find the question you're asking about. Just post the question.)

Campbell Ritchie wrote:

Tim Moores wrote:If you ask this of 5 people, you'll get 5 different answers. . . .

Only five?

Maybe fewer than 5. Unless you count my reply "I have no idea" as an answer.

Are you considering the possibility that       intValue = (int) doubleValue++;could be equivalent to       intValue = ((int) doubleValue)++;
? You'll find that isn't valid Java code.

Which implies that the cast can't possibly be evaluated before the ++ operator.

kevin Abel wrote:Bayesian inference is a statistical method that combines prior knowledge with new evidence to make intelligent guesswork. For example, if you know what a dog looks like and you see a furry animal with four legs, you might use your prior knowledge to guess it’s a dog.

And then when you learn that the animal is a wolf, you update your posterior knowledge accordingly. This becomes  your new prior knowledge.

Tim Holloway wrote:I'm uncertain about that and what releases of Java that might be true for (remember JAXB?) I don't think Xalan would be putting in something unless either it couldn't depend on the JVM or the JVM version was somehow deficient.

It was Java 1.4 when Sun added DocumentBuilder and SAXParser and so on to Java. From the beginning the design was that there was a system property which controlled which implementation of those classes would be used to do the parsing. There was a system default which was used if you didn't set that property.

And it was Java 5 when XSLT processing was added. This had a similar plug-in architecture and that's when Xalan was written to be a better XSLT processor than Sun's. It was Xerces which was supposed to be the better XML processor than Sun's. But at any rate you never have had to go searching for jar files if you want to process XML (or XSLT) in Java.

But Java already has an XML parser built in. Sure, there are other XML parsers that you can acquire and plug in, but you don't have to do that.

Do you know for sure that the previous custodians of the web app had plugged in a particular XML parser?

hiroki inoue wrote:There are the option “E. Port” so the option “D. Location of database” I think references an IP address of database or localhost.
At least does a Location of database(IP or localhost or domain) be required in the third part of the JDBC URL?

No, those things have default values and are therefore optional.

It looks to me like the standard procedure for the Builder pattern in Java is to have the Builder be an inner class of the class which it's responsible for building. So that's +1 in favour of doing that.

On the other hand many of the examples I've seen make the class being built by the Builder have a private constructor, so that the programmer is compelled to use the Builder to create an object of the class. This doesn't work with Records because they can't have private constructors. (Not that I know of, I didn't write code to try that out.)

However it looks to me like there are two reasons for Builders. One is to validate the input parameters, and the other is to provide a way to give names to the parameters instead of requiring the programmer to know which order the six or twelve parameters go in.

Validating the input parameters is covered by using a "custom constructor" in the record declaration. In your code it would look something like this:
       public Rejection  {            if (!CODE_PATTERN.matcher(code).matches()) {                throw new IllegalArgumentException("Code must match the pattern: "                      + CODE_PATTERN.toString());            }            if (reason == null || reason.isBlank()) {                throw new IllegalArgumentException("Reason cannot be null or blank");            }        }
So that should take care of the validation part. That leaves the Builder to provide the fluid interface, which looks like it can't be made compulsory but maybe that isn't as much of a problem. Inner class or not? Maybe inner class because that's the usual way to implement a Builder?

I see that Java 21 (to be released next week) has a preview feature which dispenses with most of that business. Here's the new version of Hello, World:
void main() {    System.out.println("Hello, World!"); }
That's all. No class declaration, doesn't need to be static, no useless parameters from the command line.

Back before we had enums to solve this problem there was a lot of discussion about it. The obvious answer is this:

public class One {  private static One theOne = new One();  public static One getTheOne() {    return theOne;  }  private One() {    // a private constructor  }  // more methods for the One to execute }
This works fine because when class One is first used, it's loaded and its static variables are initialized before any other code can use the class. Problem solved, then? Well, no. Some people needed to consider the case where creating a new One object was "time-consuming" and where users might use the One class for purposes other than what the single One object provided. It might happen that you created the One object and never used it, which would be an inefficiency.

So the alternative to this issue would be to create the One object lazily, in other words not until somebody calls getTheOne() would you actually create the One object. This leads you into the depths of Java synchronization -- what happens if two threads try to create the One object at the same time? I will only say that reams of server space were used to store blog posts arguing about this.

But now we have enums. They work fine. And they tend to prevent you from designing a slow-loading singleton which can also be used for features unrelated to that singleton, which was also the solution to the lazy-loading idea.

Also, the Car constructor (and instance initializers) are responsible for initializing the Car object's data. It would be a wrong design to allow the subclass Taxi's constructor to bypass that initialization. After all, a Taxi IS-A Car.

That's a good question, and it did cross my mind just the other day when I was writing code using a queue. I just used sample code from the web but of course it's always better to read the docs. The API documentation for Queue, for example, says

The documentation wrote:Besides basic Collection operations, queues provide additional insertion, extraction, and inspection operations. Each of these methods exists in two forms: one throws an exception if the operation fails, the other returns a special value (either null or false, depending on the operation). The latter form of the insert operation is designed specifically for use with capacity-restricted Queue implementations; in most implementations, insert operations cannot fail.

Yes, I agree, this thread is well into "The Perfect is the enemy of The Good" territory. I think it was stated in the original post that the student was new to programming, and I also agree that often it's best for students to work their way through exercises which try to reference interesting subjects, even if they may be over-simplified in terms of those subjects.

kevin Abel wrote:I think that the book wants me to recognize wrapper types don't automatically get set to a default.  They are wrappers and don't have a value of their own.

Do you think that is what the authors want me to realize?

You have put your finger on the problem, indeed. But your conclusion isn't quite correct. All instance and static variables in Java do get automatically set to a default value. And as you know, primitive variables are set to zero. And as you see, variables of types such as Integer (those wrapper classes) aren't set to zero. So what are they set to, and why? (Hint: the error message tells you what the Integer variable was set to.)