Trey Carroll

Greenhorn
+ Follow
since May 06, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Trey Carroll

Hello,

I have taken another job and now I am trying to help my school to find a replacement. We need someone with Java skills to work from March 2nd to June 7th. I'm trying to get these kiddos ready for the AP exam on May 5th. These are great kids - very sharp, very well-behaved. The pay is pretty good. If you are Texas CS Certified they will pay (DOE) 42+K. If you serve as a non-certified, long-term sub the pay is about the same except you don't get benefits. If you do a good job there is a possibility that you will be hired as the CS teacher for 2009-2010. This is a fantastic school.

Please contact me at treycarroll et gmail dt cm for more info. Please contact me ASAP as we are interviewing right now and I'm afraid that they're about to settle for someone who knows zilch about Java. The job is posted on the district website: www.mckinneyisd.net. You will need to fill out the electronic application and then call 469-424-5400 to set up an interview with Mr. McDaniel.

Thanks,

Trey Carroll
McKinney Boyd HS
Computer Science
15 years ago
Why does this cause an error:



Isn't char a 16 bit type? How could assigning a short to a char cause a loss of precision?

I realize that the problem can be eliminated by adding an explicit cast to char, but I want to understand why it's necessary here.

Thanks,
Thanks Sumi

Corey's Tipline was exactly what I needed. (He confirms my hypothesis.)

Also, Thanks to you, Lakuma. Your example:

a = a++ + a;//a = 11



Shed light on the process too. It taught me that the last step is always the assignment so increments and decrements will never "write through" to the LHS.

Thank you,

Trey Carroll
[ October 02, 2008: Message edited by: Trey Carroll ]
Hello,

Thanks for the feedback. I'm afraid that I haven't made my question clear or that the subtlety of this question has been overlooked.

I understand the difference between prefix and postfix increment/decrement operators. If the original code were replaced with this:



I would have no problems at all. However, my question is this:

If we think of a as a labeled 32 bit bucket, then the code:



brings up a strange situation.

So far, so good, but then, after the assignment is complete, the -- is applied to the value stored in a!

Am I missing something here? After the assignment the -- is supposed to decrement the value stored in a.

The only scenario I can come up with to understand this output is to hypothesize that the actual process here runs like this:

1) evaluate the current value of in a and store this for later use in the assignment.
2) allow the decrement operation to run
3) assign the previously stored value to variable.

Thus, the diagram for my conjecture would be:

Can anyone confirm this or offer an alternative explanation?
[ October 02, 2008: Message edited by: Trey Carroll ]
Hello,

I'm having trouble understanding why the output of the following is 5 instead of 4:



I know that the postfix operators affect the value AFTER the assignment. But since the variable, a, IS the variable being decremented, shouldn't it be affected by the -- after the assignment of the value of 5? This is clearly not the case. Why not? What is going on here?
Hi,

I need some help with a Thread question that was originally raised in the SCJP forum, but that went for a month and 1/2 without a satisfactory answer.

Original post

For the sake of convenience I will repost the relevant parts here. It began with a question from Sun's pre-evaluation test:


5. class Order implements Runnable {
6. public void run() {
7. try { Thread.sleep(2000); } catch (Exception e) { }
8. System.out.print("in ");
9. }
10. public static void main(String [] args) {
11. Thread t = new Thread(new Order());
12. t.start();
13. System.out.print("pre ");
14. try { t.join(); } catch (Exception e) { }
15. System.out.print("post ");
16. } }



The issue is that the correct answer seems to be both: 1) in pre post and 2) pre in post

Output 2 is easy to understand, but output 1 just doesn't make any sense to me. I understand the principle of no-guarantees with Thread behavior. However, I need to clearly understand which behaviors are guaranteed and which are JVM dependent.

In the previous post someone has stated that a JVM is free to ignore a call to sleep. However, the K&B 1.5 page 699 seems to contradict this:

sleep() is guaranteed to cause the current Thread to stop executing for at least the specified sleep duration.



If the statement that the JVM may choose to ignore a call to sleep() then I have no problem with the "in pre post" output. Yet if the K&B book is correct that the sleeping behavior is guaranteed, then it seems absurd that the main Thread would sit in the runnable pool unselected by the Thread scheduler during the entire 2,000+ milliseconds that Thread t will spend in the waiting/sleeping/blocking state! Or is the no-guarantees principle simply telling us that we can never predict what the Thread scheduler will do; that it could indeed sit idly, never selecting Thread main during the time Thread t is sleeping?

Any clarification that you can provide would be greatly appreciated.

In summary, I need to know if a JVM is free to ignore a call to sleep and whether my reasoning for the "in pre post" output is valid.

Thank you,
[ October 01, 2008: Message edited by: Trey Carroll ]
This is in response to Paul.

Sorry to keep the posts coming but I'm still in the dark so I'm afraid that I need to keep beating the proverbial dead horse here.

Quoting Paul Somnath:

JVM decides that the worker thread runs first. In this case, the thread sleeps (may not sleep!, depends on JVM) but lets assume it sleeps. Then in gets printed first.



I don't know how to reconcile this statement with the statement from K&B 1.5 pg 699.

sleep() is guaranteed to cause the current Thread to stop executing for at least the specified sleep duration.



These two statements seem contradictory. If sleep() is guaranteed to cause the current Thread to go into the waiting/blocking/sleeping state for 2 seconds - how can a JVM choose to ignore it?

Paul, you say,

"In this case...the Thread [t] sleeps... Then in gets printed first"

But that doesn't make sense to me. The Thread t is the thread that prints "in". If it gets put to sleep how can this mean that "in" will be printed first? Doesn't t getting put to sleep suggest the opposite, that Thread main will jump in an print "pre"?

I have been banging my head on this one for a couple of days so please forgive my verbosity, but this is driving my crazy. I have put together a scenario that I think might explain the "in pre post". Somebody please put me out of my misery and either confirm it or rip it to shreds!

"in pre post" Scenario:
The main Thread must run first. When the statement is encountered, the JVM selects the Thread t to be executed first. It then encounters the call. K&B 1.5 pg 699 says that sleep() is guaranteed to cause the current Thread to stop executing for at least the specified sleep duration. According to this guarantee, the Thread MUST stop executing for 2 seconds.

(Now this is where the part that is hard to believe happens.) Under some implementation of the JVM, though there are only 2 Threads and one of them is asleep, as part of the no guarantees clause, we cannot say for certain that the main Thread will get a chance to execute at all during the 2000 millisecond period that Thread t spends in the waiting/blocking/sleeping state.

In order for "in" to precede "pre", the main thread just sits in the runnable pool for 2000+ milliseconds while Thread t sleeps. Thread t then awakens, joins the Runnable pool and is selected to enter the Running state. Thread t prints "in"...

Is this scenario actually possible? Can a JVM choose to ignore a call to sleep, or is sleeping guaranteed? Can a JVM choose to sit idly while there is a Runnable Thread (like main) waiting in the pool?

Any specific help would be greatly appreciated.
The Rule is that if the 2 objects are equal then the hashcode must be the same for both objects. (The reverse is not true. Just because two objects have the same hash code they do not have to be equal.)

I like to make up specific values to try for these:

Equality scenario 1:

Object A
+++++++++
+ a = 5 +
+ b = 6 +
+++++++++

Object B
+++++++++
+ a = 5 +
+ b = 6 +
+++++++++


Equality scenario 2:

Object A
+++++++++
+ a = 3 +
+ b = 2 +
+++++++++

Object B
+++++++++
+ a = 2 +
+ b = 3 +
+++++++++

Now the question is which expression guarantees that you'll get an identical hash code under both scenarios.

return 0

This ALWAYS give the same hashCode including when you have equal objects, so this must be correct.

return a

Scenario 2 shows a situation where the a's are different and the objects are deemed equal, so "return a" fails.

return a+b

Under both equality scenarios the sum of a and b are the same, so this choice is correct.

return a-b

The sign of the result will be different under equality scenario 2. This option fails. (return Math.abs(a-b) would work)

return a^b

XOR is a bitwise "difference detector". It flips bits on when bits in corresponding slots in 2 numbers are different. (e.g. one is a 1 and the other is a 0). Under scenario 1 a^b will clearly return the same value for both objects. Under scenario 2 the order of the arguments is reversed, but since XOR is commutative it doesn't matter; a^b is the same as b^a. This choice is correct.

return a<<16|b

This one makes me glad that bitwise shift operators are off the exam. I'm sure that there must be a better way to proceed, but I set out to find a situation where the objects could be the same and different hashcodes could still be produced. Scenario 1 is trivial (tautology). Scenario 2 is interesting. I assumed that a was all 1's and b was a pattern of repeating 1's and 0's. When you left shift you zero fill so this gave me

11111111111111110000000000000000
or 10101010101010101010101010101010
--------------------------------
11111111111111111010101010101010

and

10101010101010100000000000000000
11111111111111111111111111111111
or --------------------------------
11111111111111111111111111111111

Since different hashcodes can be produced even when the objects evaluate as equal, this option fails.


IMHO, the correct answers are:
return 0
return a+b
return a^b

If I am wrong I will bless you for correcting me.
Hello All,

From what I can see the output "pre in post" is very intuitive and undisputed, the problem is how is the output: "in pre post" possible?

I know that this must be infuriatingly simple to some, but I would like to make certain that I understand the whys behind this output. I have appreciated the time and effort that various members have put into clearing this up, but, unfortunately, the issue remains cloudy for me. I have come up with a very specific scenario under which the output could be created.

If it is correct please let me know. If it is incorrect, please respond in
kind, with a very specific description of the Threads entering and exiting states and which rules are controlling their behaviors.

Let me start out by establishing a fact:

K&B 1.5 pg 699 says that sleep() is guaranteed to cause the current Thread to stop executing for at least the specified sleep duration.



So, as I understand things, for the String "in" to be printed first the following must happen:

The JVM select the Thread t to be executed first. It then encounters the sleep(2000) call. According to the above guarantee, the Thread must stop executing for 2 seconds. (Now this is where the part that is hard to believe happens.) Under some implementation of the JVM, though there are only 2 Threads and one of them is asleep, as part of the no guarantees clause, we cannot say for certain that the main Thread will get a chance to execute at all during the 2000 millisecond period that Thread t spends in the waiting/blocking/sleeping state. The main thread just sits in the runnable pool for 2000+ milliseconds while Thread t sleeps. Thread t then awakens, joins the Runnable pool and is selected to enter the Running state. Thread t prints "in" and its run method completes and it enters the dead state. The main Thread (now the only Thread in the Runnable pool) finally gets to run. It prints "pre". It then attempts to join the now dead Thread t.

(Interpreted from K&B 1.5 pg 700 paragraph 1: You can join a dead (completed) Thread without getting an error. The current executing Thread just doesn't "back out" of executing.

Since t is dead, the main Thread just keeps executing and prints "post".

I think the reason that the previous chain of posts may have dragged on so long was that this scenario seems implausible. I will accept it, however, on faith in the "no guarantees" principle if someone authoritative will confirm the details. I respectfully request that you do not post a reply to this unless you have carefully read what I have written above.

Thanks in advance for your for your help.
Thank you so much Samus. I got it to compile.

I feel embarrassed for posting this, but your reply really helped me to track down the problem: I wasn't recompiling the latest version of the Testable Interface.

I like working with JCreator's new>file for creating "toy" apps to test concepts as I read K&B, but the lack of a project really got me on this one. I could see the class file in /pkg1. I just didn't realize that it was for a version of Testable that didn't declare any Exceptions! Thanks again. I was completely baffled.

For anyone following this thread, the code that I posted was good; I was making a stupid error. You CAN throw new CheckedExceptions when you implement an interface, provided that the new CheckedException is a subclass of an Exception that the method in the interface declares. The idea of a narrower exception corresponds to an Exception that is a subclass.
Thanks for the help on this Ankit. I have inserted the statement that you suggested:


throw new FileNotFoundException();



but I still can't get it to compile.

I'm afraid that the trouble may be that I am interpreting "narrower" incorrectly. I *think* that what is supposed to be true is that the method in the implementing class can declare new CheckedExceptions provided that they are "narrower", that is, a subclass of the CheckedException declared by the method declared in the interface.

If anyone can tell me what is wrong with this I will be very grateful.
Now I understand what was meant by the statement.

Thank you for taking the time to clarify it for me.
Hello all,

I'm having trouble understanding something. K&B 1.5 pg 70 says:

A legal non-abstract implementing class has the following properties... It must not declare any checked exceptions that are broader than the exceptions declared in the interface method.



To check my understanding of this statement I created an interface Testable:


and a class, Test:



My intent was to prove to myself that I understood the statement. Since FileNotFoundException is a subclass of IOException (and therefore a narrower exception), I predicted that the code would compile. I was wrong. I get the following compile error:

test() in pkg1.Test cannot implement test() in pkg1.Testable; overridden method does not throw java.io.FileNotFoundException
public void test() throws FileNotFoundException{



Can someone please help me to understand what's going on here?

TIA
Hello all,

I'm studying K&B and I just came across something that I thought might benefit the community.

K&B 1.5 pg 69 says

"Interfaces can be implemented by any class, from any inheritance tree".

That sounded fishy to me so I coded up a little sample app to test it.





The statement in K&B is very broad and seems to imply that any interface in any package will always be accessible to any other class. I started thinking that all interfaces must be public implicitly or something, but I have verified that this is not true. If you remove the public access modifier from the Testable interface in the code above, the Test class will no longer compile. You get this error:

pkg1.Testable is not public in pkg1; cannot be accessed from outside package
import pkg1.Testable;



The moral of the story is that the K&B statement is misleading. Interfaces can have default access; if they do you may not implement them from outside their own package.

Hope this is beneficial to someone else.
Hello,

I have a question regarding the companies mentioned in this thread. I would like to purchase some test preparation materials and I am unsure what company to buy from. What I feel like I really need is mock exams that offer the ability to see what you did wrong. I love the section of the K&B book (Self test answers) where they explain why wrong choices are wrong and why correct choices are correct. What I find useless for preparation purposes is the practice exam software that comes with the book. I don't know which questions I got right and which ones I got wrong. Which prep materials are like the book (test you and then give detailed explanations of answers)? Do either Whiz Labs or uCertify do this?