Paul Clapham

The API documentation for the next() method of ResultSet says this:

The API docs wrote:When a call to the next method returns false, the cursor is positioned after the last row. Any invocation of a ResultSet method which requires a current row will result in a SQLException being thrown. If the result set type is TYPE_FORWARD_ONLY, it is vendor specified whether their JDBC driver implementation will return false or throw an SQLException on a subsequent call to next.

Now, I see that you're using TYPE_FORWARD_ONLY. So it might be that your JDBC driver throws the exception for that reason, instead of politely returning false as one would expect.

Eclipse runs under a particular JVM which is specified in that .ini file. You probably don't need to change that.

When you create a Java project in Eclipse, you can specify what JVM that project uses. You can download any JVM you like from the web and have that project use it. You can do that for every project, although there's a default JVM if you don't choose one. You can specify what that default you should be, too. But none of this affects the JVM under which Eclipse runs.

I don't know what the default JVM for Eclipse Photon is, but since that Eclipse version is 6 or 7 years old now I wouldn't be surprised if it's Java 8. Although as I said earlier, it doesn't matter. If you want to have your project use Java 17, then download Java 17 and put it somewhere on your disk. Then find "Installed JREs" in the Java configuration and add the Java 17 JRE to its list.

Although it might be better to get a newer version of Eclipse, don't you think?

The API documentation for the Thread class contains many, many instances of the phrase "current thread". But it never gets around to saying what that means. Perhaps the writers thought it was too obvious to mention.

It looks like you've found an example which shows why it isn't that obvious. Basically, the documentation of Thread goes on and on about the "current thread" without mentioning that it's a thread, a native resource in the JVM, and not a Thread object. The two concepts are different. Once a Thread's start() method is called, that Thread object is associated with a thread. The start() method calls the run() method which is associated with the Thread object and from then on, every time that code in that Thread calls Thread.currentThread(), it gets a reference to itself.

But before the Thread object becomes associated with a thread by having its start() method called, a call to Thread.currentThread() can't return a reference to that object because it isn't associated with any thread. Some other thread is the current thread. Your example shows this in action.

The instance initializer of the Task1 class changes the name of the current thread to "Bingo". It's true that a Task1 object is a Thread, but I don't see how it can be the current thread when its instance initializer is only just running. So that line of code changes the name of some other Thread... presumably the thread which is creating the Task1 object. You could try changing the initializer to    {        setName("Bingo");    }and see what happens.

As for your question about t1.join() and whether it makes a difference, I would leave it out and see whether that makes a difference.

There's the "java" command which you'd use to run a compiled class. Once you have actually managed to compile one, that is! And there's the "dir" command which displays the files in the current working directory.

"Current working directory"? You use the "cd" command to set a directory to be the CWD, if you haven't already seen that term. You need to know about that because Java's classpath is a list of directories (and jar files) which are declared relative to the CWD, and you'll pretty soon run into problems where your classpath isn't set correctly.

Indeed. It's possible that a class can have many total orderings -- for example an Employee class could be ordered by name or date of hire or other characteristics. But if the class is going to implement Comparable then you can only choose one total ordering for that, so it's natural to call that one the "natural" ordering. The others can only be implemented by writing Comparators. Campbell and I are just griping that a "natural" ordering may not look that natural, but yes, that's distracting.

Incidentally the java.text package contains classes which help manage the un-naturalness of the sequence of characters in Unicode, in particular java.text.Collator.

Campbell Ritchie wrote:I have my own ideas about String, which differ from Java®'s. Thee are at least two ways of comparing Strings, the classic IT version, unofficially called ASCIIbetical, where Zymurgy comes before aardvark, and case‑insensitive, where aardvark comes first. I think that means the Strings don't have a natural ordering. But I shan't manage to implement that notion anywhere.

People talking about Java Strings typically forget, or ignore, that a String is a sequence of Unicode characters, instead simply looking at ASCII characters in English.

It should be clear that a natural ordering for Strings must be based on a natural ordering for the Unicode characters. Now you might say that the natural ordering for the Unicode characters is the ordering based on the Unicode values of the characters. And fair enough, there aren't any other good candidates. Now let me ask you this: in this "natural" ordering, do the Cyrillic characters come before or after the Greek characters? (No fair peeking.) And why is that more natural than the opposite? And how can this ordering be called "natural" when the order it provides for the letters used in Turkish doesn't match the order used by Turks in real life?

So yes, I'm saying that String does not have a natural ordering.

No. That hour is just the same as the hour from 1:00 pm to 1:59 pm, except 12 hours earlier. I mean, I'm usually asleep during that hour but if I'm awake for whatever reason I still don't experience it backwards.

Piet Souris wrote:Do you mean by 'proceeding' 'following'? Here is a third version, after Careys and Rons code:

I think they might have meant "preceding" (i.e. before).

The API documentation tells you how to create a synchronized version of a TreeSet. It's not complicated, check it out.

I would suggest that question 2 needs the option of answering "I don't know"... at least, that would be my answer.

You could certainly do that, yes. A more advanced technique would be to write a class which does what you want, and then override it with the changes you want. But yes, copy and paste is ancient technology which still works.

Not according to Mike's comprehensive explanation, no.

I don't think that you need two instances to have a problem. You already have a problem with only one instance, don't you?

Chirayu Gangadkar wrote:Later found out: Float.MIN_VALUE does not represent the smallest negative float but instead represents the smallest positive float value.

Could you explain this?

You seem to be thinking here of "smallest" as meaning "closest to zero". But in your statement, "smallest" uses the < operator to determine when a number is smaller than another number. For example -10 is smaller than -8. Which is a perfectly reasonable way to define "smallest".

Another source of confusion: Integer.MIN_VALUE is -2147483648, which is what you might think of as the "smallest" integer value. The API documentation, though, describes it as the "minimum" integer value, possibly avoiding the issue of what "smallest" means for negative values.

So you aren't wrong. It's just that it isn't useful to have a constant which you can use if you want to use the smallest positive integer value. People are just going to use "1" and be done with it. However it is useful to have a constant for the smallest positive float value, for the use of people who are really into the details of floating-point representations. I'm not sure what the largest float value less than zero is, but presumably it's easy to figure out if you're one of those details people.