Mike Simmons

(Though both of those have bugs in general, they work fine for this problem.)

Aside from trying a more modern JDK, don't overlook Ron's previous comment about how the documentation for File.length() may explain this, and recommends using Files.readAttributes() to see if there's an error message.  You can go further and print out additional diagnostic info that may help:
 private static void examine(File file) {    System.out.println("file: " + file);    Path path = file.toPath();    System.out.println("  absolutePath: " + path.toAbsolutePath());    try {      System.out.println("  realPath: " + path.toRealPath());      BasicFileAttributes attrs = Files.readAttributes(path, BasicFileAttributes.class);      System.out.println("  size: " + attrs.size());      String type =        attrs.isRegularFile() ? "REGULAR FILE"        : attrs.isDirectory() ? "DIRECTORY"        : attrs.isSymbolicLink() ? "SYMBOLIC LINK"        : attrs.isOther() ? "OTHER"        : "UNKNOWN";      System.out.println("  type: " + type);    } catch (IOException e) {      e.printStackTrace();    }  }

Kevin, what is this "j8" command that you're running?

I'm guessing it may be an alias for a Java 8 runtime.  If so, can you try any other JDKs?  Something more modern?  This may be something that's been fixed in other versions.

If they ever use 0 for 1900s, or 2 for 2100s, then one approach would be to take that original format as a decimal number, and add 19000000.

So 1240528 + 19000000 = 20240528.  Convert that back to a String and parse it using yyyyMMdd.  That way you can easily handle any date from 1900 on to... whenever, really.

1240528 is not a random example - it's today's date, 2024-05-28, formatted according to the format given in the original post, 1yyMMdd.  It contains no time info, only date.  This can be reversed to parse a given string as a LocalDate, e.g.
   DateTimeFormatter format = DateTimeFormatter.ofPattern("1yyMMdd");    var dateStr = "1240528";    var date = LocalDate.from(format.parse(dateStr));    System.out.println(date);

Ira Go wrote:XOR is so basic that it is possible it was not talked about much in the book.

I wouldn't say it's basic, exactly.  It's not just XOR, but bitwise XOR, and also the whole issue of how binary numbers work, and how to convert from binary to decimal and vice versa - at least for very small numbers, in this case.  That may be basic computer science, from an old-school perspective, but I think nowadays many programmers don't find much need to know those things, day to day.  How many extra pages would that take to cover, for those unfamiliar with those concepts?

The book does say:

For the exam, though, you don't need to know anything about numeric bitwise comparisons, so we'll leave that educational aspect to other books.

This seems like a totally reasonable decision, based on an unfortunately false premise, that such details will not be asked on the exam.  Probably, they were not asked much on previous versions of the exam, and it was thought that this would continue to be true.  But it seems the latest OCP 17 may indeed ask questions that depend on understanding bitwise operators.

Yeah, I don't have a copy of the book, but it's hard to imagine that they would simply skip how to create a Statement.  Unless they went directly to PreparedStatement instead?  The OCP 17 objectives do include (emphasis mine):

Accessing databases using JDBC

Create connections, create and execute basic, prepared and callable statements, process query results and control transactions using JDBC API

This is really the way to create a basic Statement.  Do they not show anything like that in the book?

From the table of contents:

Chapter 15: JDBC

Introducing Relational Databases and SQL

Introducing the Interfaces of JDBC

Connecting to a Database

Working with a PreparedStatement

Getting Data from a ResultSet

Calling a CallableStatement

Controlling Data with Transactions

Closing Database Resources

Summary

Exam Essentials

Review Questions

Hm, I guess it's possible they largely skipped Statement, and only spent time on PreparedStatement and CallableStatement.  Still, the original objective is pretty clear that creating and using a "basic" Statement should be understood as well.

I wonder if the exam objectives have changed at all?

It would have been nice if they pointed that out in the JavaDoc when they deprecated the class, but they did not.  However, the Changelog for Tomcat 9.0 does contain the helpful line

Switch to using the Base64 encoder and decoder provided by the JRE rather than the version provided by Commons Codec. The internal fork of Commons Codec has been deprecated and will be removed in Tomcat 11.

I agree, Tim.  It seems that by trying to re-use similar code, they've created a more confusing situation that doesn't quite fit.  There's also more than just one "long form" and one "short form" - e.g. these are also possible, and equivalent to the first version:
(a, b) -> { return a.equals(b); }
(String a, String b) -> a.equals(b)
(a, b) -> a.equals(b)
For a one-argument version, perhaps it would be easier to just replace b with a literal of some sort, and skip the "where did b come from?" confusion:
a -> a.equals("YES")

Honestly, I've been finding the terminology very confusing for this one all along.

What does a CaseRequestHandler represent?  Is it a case?  A request for a case?  A thing that handles a case?  Those seem like different roles, and this class feels like it might be confused about what its job is.  Does a "handler" handle only one case?  

Is a case ID a unique thing in the database?  That is, does each case have a different ID?  That's the sort of thing I'd normally assume when I hear of an ID, but not sure here...

Is this DefaultCaseFactory.CAR - is that an ID for one particular case or case request?  Or is it maybe a type of case or case request?

(Does it have anything to do with an automobile?  Or some other kind of "CAR"?)

(And what, roughly, is a Case?)

Maybe those last ones should have been first.  I'm just having a hard time imagining a situation where this makes sense, so I'm checking assumptions.

I forget what the trick is to remove the < br /> nonsense - obviously, that wasn't in my original.

Campbell Ritchie wrote:But you can't use mapToInt() in the following scenario.String noSpaces =   /* Take array and make Stream to transmit it */   Arrays.stream(   /* Create array */            "Campbell Ritchie is brilliant".split(" "))   /* Reduce to Optional */   .reduce((x, y) -> x + y)   /* Get result fromOptional */   .orElse("No result");

Interestingly though, this code masks a rather inefficient implementation, which is roughly equivalent to:
   var array = "Campbell Ritchie is brilliant".split(" ");    String result;    if (array.length == 0) {      result = "No result";    } else {      result = array[0];      for (int i = 1; i < array.length; i++) {        result = result + array[i];      }    }
This is mostly OK... until we get to the
       result = result + array[i];
which is concatenating a String inside a loop.  This is probably fine for a small number of iterations - in this case, we have just four elements.  But it's O(n*n) performance overall, because every single time we go through the loop, we're building a new String by recopying everything in the previous string, plus one more word.  As the string length increases, the performance just gets worse and worse.  Instead, we'd be much better off with
     Arrays.stream("Campbell Ritchie is brilliant".split(" "))        .collect(Collector.of(          StringBuilder::new,          (c, s) -> c.append(s),          StringBuilder::append,          Object::toString        ));
Or
     String noSpaces = Arrays.stream("Campbell Ritchie is brilliant".split(" "))        .collect(Collectors.joining());
Of course, this effect could also be achieved more easily with
     String noSpaces = "Campbell Ritchie is brilliant".replace(" ",  "");
But that wasn't your point. ;)

Campbell Ritchie wrote:By the way, read the documentation for reduce() and find out whyxyz.reduce((x, y) -> x - y)won't work correctly.

Aside from the fact that String has no "-" operator defined?  I guess you meant using the Integer example from before, not the String version you just gave.

tangara goh wrote:Note: the oracle's site using map instead of stream() really stumbled me...or is there something I did not comprehend about that part that uses stream.map(Object::toString)

They aren't using map instead of stream.  They are using a map on a stream.  You don't see the call to the stream() method in their example - instead, they use a variable named "stream" to indicate that they're dealing with something that's already a stream. In your example, you still need the stream() call to convert a List to a Stream.  Compare these two possibilities:
   List<String> strings = persons.stream()      .map(Object::toString)      .collect(ArrayList::new, ArrayList::add, ArrayList::addAll);    List<Person>  copy = persons.stream()      .collect(ArrayList::new, ArrayList::add, ArrayList::addAll);
One gives you a List of Strings, while the other gives a List of Persons.  Which is correct will depend on what you need to do with this list - which do you need?

Actually I think Jack's original code is wrong, but Carey's code seems to match what Jack said he wants.  That is, in this original code:
                           if (!crh.getCaseID().equals(DefaultCaseFactory.CAR)) {                                crh.cancel();                            }                            if (crh.getCaseID().equals(DefaultCaseFactory.CAR)) {                                // You don't need to create one.                            } else {                                // create case request for CAR
It seems that the condition in line 1 and the condition in line 5 (using the numbering in this post) are exactly opposite - which means that the else in line 8 will be active for the same condition as the original condition in line 1.  That is, if the caseID is not for a car, then you will cancel it, and you will create a case request for a CAR.  And if the caseID is for a car, you will do nothing.  So it's equivalent to this:
                           if (!crh.getCaseID().equals(DefaultCaseFactory.CAR)) {                                crh.cancel();                                // create case request for CAR
I don't think that's what was intended, but it is what the original code does.  I think Carey's code is probably what you want here, instead.

Sorry, I meant to post LocalTime.of(7,0).  Or LocalTime.of(7,10) would be good, too.  I see how easy it is to slip in a value that doesn't quite make the point you want to make.