Bob Ruth

Ranch Hand
+ Follow
since Jun 04, 2007
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
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Bob Ruth

Thanks for the response. If I may, let me ask one more question that was prompted by these two statements:
3. Therefore, the AJAX event listener method can lookup that barcode in the database and update the backing bean's property for the descriptive text with the result. You can also, of course, update other properties as well, in case you want to display unit price, quantity on hand, or whatever.

4. When the AJAX event listener completes, JSF's "render response" lifecycle phase posts the updated backing bean properties back to the user's webpage. And that's all there is.

those two statements seem to indicate that, if I were in a "listener" handler method on the server and could get the domain object and updated properties in the backing bean AND THEN executed a "RenderResponse" , that the new properties would show up in their associated components on the page. I can verify with debugger that a) I am grabbing the domain object and updating the property in the backing bean for the "description text" AND am executing a "FacesContext.getCurrentInstance().renderResponse();" the question is..... "is that enough!!!". Should this (if properly done) work or does the art of "getting text from the server code stuffed into an input box as a hint" REQUIRE client side support of some kind?

I hope that I am being clear, but I probably sound like an idiot!!! Oh well........

But thanks for looking....
4 years ago
It has been QUITE a while since I have bee to the Ranch! I finally got my SCJP 6 certification AND a job in the Java world. I find myself assigned a task at the moment that I am not certain how to handle and thought I might at least ask for ideas or direction here.

The application is a legacy app here at the center, uses JSF 1.2 straight up. ONe of the pages here has two inputText components the upper is a barcode box, the lower is a description of the box. What they want to see happen is: when a barcode is entered into the upper inputText box a handler is executed that detects the change in barcode, attempts to fetch it from the database and, if it is there, it tries to grab the existing description and writes it to the property referenced by the existing "description inputText box" as a hint. I then get the context, get the currentInstance and render the page but, the text never appears in the box on the page. ( I hope you can muster some pity, I really don't know JSF ... I was just assigned to try this and am doing the best I can to learn at lightning speed!).

Using "onblur" I got the handler part working. I can actually debug step into the handler, see it take the barcode, see it fetch the existing tray, see it grab the description and put it in the property. THAT much I have working.

Is there anything that I can do from the server that will get that description text string from the database written into that inputText box. THAT way the users know that the tray exists and they will need to add new samples/primers to it.

Is there a way to do that?

Just like Gene Wilder in "Blazing Saddles" I will appreciate "all the help I can get!!!". Thanks!!!

4 years ago
Excellent post Prasad. With your info I would like to add a few more points that may help.

If you are careful, an abstract class can be made to do the same thing AS an interface. It can contain a whole list of abstract classes that ALSO define a "contract" just like an interface. If you give them public access, it will be very similar to an interface. What, then, would be a difference?

An abstract class can do one thing that an interface can NOT do. It can define methods WITH an implementation defined. An interface con not do that. The reason you might want to do this is to define default methods (behaviors) that an extending class does not HAVE to implement but, rather,it can just use the default implementation.

So an abstract class can be designed to do what an interface does BUT

1) an interface does what it does naturally by the way it is designed but ONLY allows one to express methods without implementations (abstract methods that MUST be public)

2) an abstract class can be made to act like an interface BUT will allow you to define default behaviors.
well, they are separate keywords so, in my mind, a class is a class and an interface is an interface.

The primary purpose of an interface is to establish a "contract" or an "agreement". The interface specifes the methods that an implementing class must implement. But it doesn't (make that can't) specify implementation details. The interface can specify the method name(s), the parameters required, and the return type..... nothing else. It is up to the implementing class to provide the implementation of the method.

The real benefit of using interfaces is lower coupling through the use of polymorphism. Once a class implements an interface.... a reference variable of the interface type can hold a reference to any object whose class implemented that interface. As long as the implementing class satisfies all of the methods specified by the interface and the client object only references method types known to the interface you can plug any implementer of the interface into the reference and it will work.
Just a little "point of view" ( I had a hard time with the idea of coupling early on...)

changing the variable from default to private is more about encapsulation than coupling because another class in the same package can have direct access to the variable and THAT is, as I say, an encapsulation problem!

The way you might want to think about the second issue: the quacker() method in class Duck has the following signature:

so you can't ever pass it anything BUT a Main. This is a) inflexible and b) it makes Duck class highly dependent on the existence of the Main class.

Now, how do you decrease that coupling? That is where the magic of the "interface" comes in to play.

What if you created and interface called "Avian" and, in that interface you specified the signatures of some behaviors (like flaps, flies, chirps.... things that all avians do) and then made Duck implement Avian. But, at the same time, you could make a Sparrow that implements Avian, an Ostrich, a seagull, a parakeet..... whatever you want.

Now, alter quacker to the following signature:

Now, quacker no longer has to have a "concrete class" Main object.... it can accept any implementer of Avian. This makes quacker() dependent on the interface type NOT the concrete type Main. That makes the code much more flexible.

I realize that this might be a little confusing because your example class IS Duck and so you might think that...."why would I want anything BUT a duck?" But try to separate this specific example from the issue of coupling that we are discussing.

If I had a method that was designed to implement a logging class called PrintLogger. Let's say that I have another class LogSetup that has a method that is designed to set a log class and it has a signature like this:

The only thing that you can ever pass to setLogger() is a PrintLogger.

Let's change that a little...

Let's design an interface called Loggable. It might have method signatures like logFine(), logInfo(), logFatal()...just to make an example.
Then we change PrintLogger class to implement Loggable

now, you can change LogSetup to look like this:

now, you can implement a FileLogger, a NetworkLogger, a TapeDriveLogger, a ScreenLogger that all implement the Loggable
interface and you can pass any of them to the setLogger method, not JUST the PrintLogger.

This is much more flexible design and you can, if you care to add and remove logger types without breaking the LogSetup code.

So, cutting it down to the essentials, any time you specify the use of a concrete class and pass concrete classes around it increases coupling.
When you design interface types, then design concrete classes that implement the interfaces, then have your code specify and pass by interface
type rather than concrete type, this reduces coupling.

I hope that this will give you some help in understanding.

consider a nested pair of splits....

an outer doing a split(",") to separate each of the key value pairs...
for each token
an inner doing a split("=") to separate each key and value
then do a put (key, value)

now watch out..... some of your strings(values) have single quotes. They are already inside a string so the single quotes will be taken in as part of the value string.
7 years ago
I'm going to jump in here and try this... I think that the correct question is "when we search for an element or remove an element from a HashMap , does the time to locate an element depend on the size of the HashMap."

The answer is yes but it is going to depend largely on the hashing method that you define. The secret to hash based storage is that it is a "two part" scheme. A hashing algorithm is supposed to use calculation of some sort to divide all of the possible values into a number of coarse units... .often called hash buckets. Then, in each hash bucket... a more linear search is used.

If the hash algorithm chosen is reasonably effective then the object being stored will be somewhat evenly divided between the buckets and no ONE bucket will have an unreasonably long linear search. That is the "time smoothing" effect that is desired in large searches.

If the hash algorithm is not so good then you may have unevenly populated hash buckets which means some buckets will have many things in them (longer linear search) and some buckets will have not much... maybe even none (very short linear search... in the case of not much).

The better the hash.... the more evenly the buckets are filled... the more uniform the response time.

The worse the hash... the more UNevenly the buckets are filled.... and the response time will be irregular.

Does that answer your question?

Just one thing to add to the "contract" notion..... when you refer to an object by interface all that you can reference are the methods/properties defined by the interface... nothing else. So, in effect, you are locking callers out of anything except the methods/properties of the interface. That is the part that limits the "coupling". The code that references the object knows the other object only by the interface... so any object that implements the interface can be "plugged in" without a problem.
Well, I guess I found my own answer. I found a reference on the web to Sun Certification Manager, Googled that, found a link to it, got my password updated and found the link to the download logos page. I got there... and the list of logos to download is empty.

Oh well....
This seemed like the right place... I hope it is. I searched the message base in a number of various attempts but any question that popped up on getting the professional logos was prior to the Oracle acquisition ... so I am going to ask: Now that Oracle has taken Sun in.... what happened to the access to the Certified Professional web site that Sun used to run? I admit that I don't know what the URL was... but I figured that some clever Googling should make it show up... and I couldn't. Plus... any links that I follow that I did find on Sun's professional logos went to a generic Oracle training/education page.

Does anyone know... did the old site vaporize in the acquisition? Does the old web site still work... or map to a site in the Oracle domain that works?

Many congratulations Aakash!
Your questions can't have been TOO stupid.... they got you to this point!!!
8 years ago
Looking at the last one first..... Two threads are instantiated and each one is passed a SEPARATE DISTINCT Chess object. So, when each thread starts up it refers to a different instance of Chess object. What THAT part means is that the synchronization applied to the method in I is useless. The method in each object synchronizes on its OWN "this" and they are different so there will be no coordination at all.
The other part on the number sequence comes from this: Each thread that is started has an ID and that ID will stay the same for it's entire life cycle. So any answer with three values is wrong because there are only two runnable objects being run, so there will only ever be two IDs show up. The one that has 4, 2, AND three, is obviously wrong. Since the run method defines what each "runnable" will do, the ID will only be printed twice for each instance of the runnable. So any answer that shows a given ID 3 times is wrong.
The only issue that remains is the order. Since they are unsynchronized with respect to each other the IDs can really come out in any pattern/permutation.
(ie 4422, 2244, 2442, 4224, 2424, 4242)
I don't think that it serves as the ONLY factor and it really shouldn't be. Being able to pass a test in one's own language does NOT make one an exceptional or even decent author. Knowing the Java language is one thing. Being able to create a good object oriented design is another thing. I think that if you prove that you hold the SCJP certification I would maybe ask a couple of questions on the language but then move on to assess the person's ability to develop/design code. I think that it would provide a little more assurance that the individual knows the ins and outs of the language.
Well, if the "equals contract" is fulfilled then two distinct objects of the same type can be meaningfully "equal" (that is... .equals() is true) while NOT being the same identical objects (that is..... == is false.)

== tests to see if they are the same identical object.

.equals() tests to see if they are "meaningfully equal". Meaningfully equal depends on the implementation of the .equals() method.
Thank you all three. It was fun actually. That is the first time I have ever taken a certification exam and really the first time that I have been given a serious exam since I was in college. It felt good.
8 years ago