Win a copy of Event Streams in Action this week in the Java in General forum!

Junilu Lacar

+ Follow
since Feb 26, 2001
Junilu likes ...
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
Forum Moderator
Junilu Lacar currently moderates these forums:
Columbus OH
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Junilu Lacar

Alberto Bacchelli wrote:
2. Then, we ask you to do the code review, asking you to focus on the bugs (that is, errors that make the code not work in all scenarios) rather than maintainability issues (e.g., readability).

Interesting. I do exactly the opposite for code reviews I conduct. My thinking is that bugs should be address by unit testing. Team level code reviews are for ensuring everyone who looks at the code comes to the same understanding of its intent. That often doesn't happen when code is not expressive and readable.

In my book, bugs are caused by misunderstanding. If you focus first on bugs without making the code readable and understandable, then you are ignoring the root of the problem.
9 hours ago
I want to say "Obviously, use a new byte array with known byte values" but it doesn't seem that it's obvious to you. I'm just not understanding how it's not obvious.

The example code you cited uses this:

To write a unit test that is repeatable, you can't just use a randomly generated value though so use a known value. Here's one way you can do that:
21 hours ago
One clarification: I am going by Michael Feathers' definition of a "unit test," namely that anything that touches the database is NOT a unit test.

Before you save the salt value to the DB as a byte array, what type of value do you have? I would assume a String but the actual type is not relevant to my point which is that anything that goes on between having the value in memory and saving that value in the DB as a byte array is outside the realm of concern of unit testing. Just write your unit test as though the translation from DB byte array to whatever native Java type has already occurred. Again, the type used to save the value in the DB is irrelevant to the unit test so why bother? Treat that as a separate problem.
22 hours ago
Documentation also says "may cache other values outside this range" but doesn't specify anything else. So again, I would not write any code that depends on the caching behavior. For that matter, optimizations like the String constant pool and the caching of small integers is nice to know but shouldn't be anything you rely on unless you're trying to squeeze every last bit of memory and performance as you can.
2 days ago
As far as I know, String is the only type that has special handling by the JVM for performance. Small Integer values also are cached but you should not rely on that behavior.

The second line will autobox the double literal in a Double object which would be eligible for GC once any references to it become unreacheable.
2 days ago

Jake Monhan wrote:So had it not been for the constructor initializing the name with passed literals, then name would not have been referenced by the String pool and would have been GC eligible like the array[]. Is this the mechanics of it?

That is actually not the mechanics of it.

The String literals "g1" and "g2" are interned in the String Pool. When you pass the literal to the Rectangle constructor, the name field of the Rectangle object that is being instantiated is made to reference that String object. So it's wrong to say that "name is referenced by the String pool." It is, in fact, the other way around: a String object that just happens to be in the String pool is referenced by the name field of the Rectangle that was instantiated.

Even if you set the name field to null, that String object will not be GD'd due to the fact that it is in the String Pool. And even if you set name to null, name itself does not get GC'd because it is a reference variable, not an object. This distinction is important to understand.
2 days ago
lastname is not an object, it is an object reference variable. As I tried to explain before, variables don't get GC'd. You have to understand the distinction between reference variables and the objects themselves. Only objects are eligible for GC
3 days ago
Here's a different example to illustrate some of the points I made previously:

Since Java 11, you can do this:
$ java bar

On line 3, you create a String object that is not in the String pool. That String object will be referenced by the bar local variable.
On line 5, you pass bar to the Rectangle constructor and instantiate a Rectangle object whose name instance variable references the same String object that bar references.
On line 6, you create another Rectangle object whose name instance variable again references the same String object.

At this point, there are three reachable references to the same String object: bar,, and

On line 8, you set bar to null. There are now only two reachable references left that reference the same String object:, and
On line 9, you set one to null. Now, while still references the same String object (you never set it to null), it is no longer reachable through
So you only have one reachable reference to the same String object ("foo" + args[0]):
On line 10, you set two to null. Again, still references that String object but it's no longer reachable.

Only at this point do you have 0 reachable references to the String object created on line 3 and only then is it eligible for GC.

Again, it's the object that becomes GC-eligible, not the reference variables.
3 days ago
I may be nitpicking here but I feel like there's a basic misunderstanding just based on the language used. Call it semantics but a variable is never GC'd. Objects are GC'd. It's technically incorrect to say that an instance variable will ever be GC'd because instance variables are simply references to objects (unless they're primitive types). It's the objects that they reference that may be eligible to be GC'd if you set the instance variables to null and no other reachable reference to the same object exists.

In the given code, two Rectangle objects are created, each one passed in a reference to a String value, which just happens to be a String literal. The name instance variables of the Rectangle objects assigned to local variables one and two reference the String literals "g1" and "g2", respectively. On lines 10 and 11, the Rectangle objects that were created on line 7 and 8 become GC eligible. However, the String object referenced by the name instance variable of either Rectangle never becomes GC eligible because, as MS said, they are in the String Pool and those don't GC'd.

I don't believe it's correct to say that the int[] array instance variable will ever be eligible for GC either because again, reference variables do not get GC'd. Nothing in the code ever assigns an array object to that instance variable either so there's nothing to GC.

If the code had included these lines:

then after one is set to null, the int[] {1, 2, 3} that is referenced by the one.array instance variable will no longer be reachable, therefore it will be eligible for GC.

Again, it's the objects that become GC eligible, not the references to them.

Just want to make sure you understood the distinction.
3 days ago

wayne brandon wrote:in this exercise:

Given an int n, return true if it is within 10 of 100 or 200. Note: Math.abs(num) computes the absolute value of a number.

I'm not so sure about OP being steered wrong by the instructor. Given the above, it's kind of like saying "Build a house that's fit for a canary-sized bird. Note: A jigsaw can cut curves."

To someone who has built such things before, it's obvious that the note meant "You might want to try using a jigsaw at some point if your birdhouse has curves." The naive novice might think, however, that using a jigsaw is a key requirement to building the house and gets fixated on it.

To me, it seems like our OP might have just become fixated on when and how to use Math.abs() to solve the problem without necessarily thinking about the problem from a more holistic perspective. That's quite understandable and, of course, Fred is right in saying that you might want to take pen to paper first and work out the solution by hand before thinking about where in that process you might have a reason to use Math.abs().
4 days ago
5 days ago
Think about how you would calculate how far apart two numbers are. What arithmetic operation would you use. That is, to see if N is within 10 numbers of 100, what would you do? Dont think of abs() yet.

Now think of different values of N that could be provided. If you used the same formula, would you always get a positive result or will you sometimes get a negative result? Will the negative or positive nature of the result matter? If not then that is where abs() comes into play.
6 days ago
If you want special ability to grow more slowly, you can still use an int and a scaling factor, say 10, and use integer division.

Say you use 10 as a scaling factor, then both 21 and 29 will give you 2 (using integer division, 21/10 and 29/10 both give 2) so special ability will have to be incremented 10 times before it goes from 2 to 3.
6 days ago
2 to the power 8 is multiplying two by itself eight times. It's all multiplication, no addition. In other words,

2^8 = 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2

If you break it down and get intermediate results, then you might write this:

2^8 ==> 2 x 2 = 4 x 2 = 8 x 2 = 16 x 2 = 32 x 2 = 64 x 2 = 128 x 2 = 256
        ^   ^       ^       ^        ^        ^        ^         ^
        1   2       3       4        5        6        7         8

You should read the "=" signs as "is" not "is equivalent to". That is, you'd read that as "2 times 2 is 4 times 2 is 8 times 2 is 16 times 2 is 32 times 2 is 64 times 2 is 128 times 2 is 256."

That wasn't my question. I asked why do you need to know the salt "as stored in the database"? Who cares where the salt value comes from? Just make one up! A unit test has to be repeatable. In order for it to be repeatable, you need to know exactly what you're using as input values for the test.

Say your salt is "123456789mySaltValue" -- this is a known value you can use for a unit test. To see if your method works properly, you'll need to know what your expected output is. What return value would you expect from the method if you gave "mySecretPassphrase" as the password to hash and "123456789mySaltValue" as the salt? That is essentially your unit test:

It really is that simple.
1 week ago