Betty Reynolds

Thanks.

I am currently using a method that creates new StringBuffer and new Strings objects whenever it is invoked. I'm considering moving these items to the class, which uses this method, to be defined as private members for the sake of efficiency. The method then will simply reference these members, and, in the case of the StringBuffer, reset its length.
The method gets called about 150 times when an item change event occurs. This event could theoretically happen any number of times, but in actual usage, it probably won't be that often.
Is it worth it? What are the tradeoffs in making this decision? Thanks.

Thanks Manfred, but I found a way. It has to do with using the ImageGlyph constructor, but that's part of IBM's VAJ functionality, so not particularly useful information unless you're using this package. My approach still needs some refinement, but it's a good start. I probably spent as much time dinking around with the wiring as I would if I had coded and debugged it myself.

This topic is very similar to the question I have. I am working in VAJ. I have several components in a container already (I have no control over the container The top level was provide by VAJ when I set up the Applet. I want to isolate an area in this container and draw a set of images to that area. The images are stored in an array that was loaded from a directory during initialization.
The number of images can vary each time repaint() occurs, but basically I want them displayed side to side one after the other.
I tried setting up a panel and drawing the images to that, but it didn't work.
Does anyone have any suggestion.?

I've designed an Applet using VAJ and am having difficulty with image processing. I'm primarily relying on beans to do most of the work, and was hoping to avoid the low level code associated with painting images.
I have a number of components already in my applet. I would like to add a series of images (gif files) that are stored within an image array in my bean. I've been using g.drawimage, but I have to generate my own code for the coordinates and it does not address the problem of what happens to the images when the window is resized. Does anyone know of any beans or combination of beans that will do the work for me? Can anyone suggest an approach? Thanks.

I am a recently certified Java 2 programmer (passed May 5, 86%) seeking work in this area. Ideally, I am seeking engagements where I can leverage my vast legacy systems experience on projects that are transitioning MF applications to the Internet.
I have homes in both Hawaii and Chicago and am willing to work in either location.
Please see the following link for contact information.
http://Betty_Reynolds.tripod.com/resume.html


[This message has been edited by Betty Reynolds (edited May 11, 2000).]

I had always equated obtaining a lock on the object with maintaining its integrity with respect to its data, but given that the monitor gives up its lock when issuing the wait (I guess it has to--how else can the thread that issues the notify or notifyall execute) my question is: Are the variables defined by the object threadsafe at this point? That is, can they be modified by some thread in between the time the wait is issued and the notify takes place? Or is it a question of scope (i.e., just those inside the synchronized code are, etc.)

4) The questins aren't meant to be a commentary on the Language Specification. Many of them are purposely ambiguous, so that raw facts alone aren't enough. You must also make decisions based on principles.

What principles are you referring to - OOP? If not a commentary, I hope the questions are at least based on the specification. That's what I'm basing my knowledge on.
If this comment seems inappropriate, I apologize. It's just that I am going through the rather painful process of preparing for the exam and I find the ambiguity and the lack of reliable information frustrating. Luckily, this journey is almost at an end. It's been quite a trip.


[This message has been edited by Betty Reynolds (edited April 24, 2000).]

Maha,
The info on this is not very good. I just read somewhere that wait() and yield() releases the lock (I'm going to stop mentioning the source of misinformation).
This never really made sense to me. Why bother to enqueue on an object, if you are going to release the lock. Are you sure that wait does release the lock?

Well, this time I thought I would save the sheriffs some work. I've confirmed this myself from the JLS:
Section 11.2 The Compile Time Check of Exceptions

The unchecked exceptions classes are the class RuntimeException and its subclasses, and the class Error and its subclasses. All other exception classes are checked exception classes.
(I wish I could link you to the section, but I only know how to link to the document page, so I copied the relevant statement here. Maybe Jim could share this secret with us sometime.)
My practical interpretation of this is that unless you are extending RuntimeException or Error or any of their subclasses, then by default, your exception class is checked.
This means that in extending Throwable, as well as Exception or any of its checked subclasses, your class is defined as checked.
I hope that's good enough satya.

[This message has been edited by Betty Reynolds (edited April 21, 2000).]

I think what we are looking for JavaNut, is confirmation that any user defined exception that extends Exception will, by default, be a checked exception. We've only confirmed that programmatically. Thanks.

satya5,
I see your point now. I completely misread the question.
a & b are right only if they are defined as runtime exceptions.
Sorry for the confusion, but it was a confusing question.

satya5,
I don't think you're getting my point. If you answer a, b and c, then don't go running for Chapter 8, because your instincts are probably correct. This is the better answer.
Just look at his own answer:
A method in a subclass cannot add new exception types that it might throw. Since it�s superclass, Second, does not define any exceptions in its test() method, Third can�t either. (See chapter 8.) This implies that a & b are correct also.
The only way that a & b might be incorrect is if Exception1 and Exception2 extend RuntimeException, in which case you won't get an error and then answer c only is valid. It's not likely that this would happen, as it's not good practice to extend RuntimeException. If you are going through the trouble to set up an exception, you probably want to extend Exception.
The point is what would happen in this case would depend on how you design the Exception. If you are asking if just extending Exception would make these fall into the category of checked exceptions, you won't find the answer in the book. You just have to try out an example yourself. The answer is yes.

4/21/2000
I think I should point out that there were at least two sites that had exam objectives and only one of them had the error.
This one, which has the I/O objectives, was the one in error.
This was probably always correct.
The good news is that Sun appears to have corrected the problem. Hopefully, the mock exam authors will do the same.

[This message has been edited by Betty Reynolds (edited April 21, 2000).]

Here is yet another example of an ambiguous question that could mislead:
Question 28: Imagine there are two exception classes called Exception1 and Exception2 that descend from the Exception class. Given these two class definitions: class First { void test() throws Exception1, Exception2 { . . . } } class Second extends First { void test() { . . . } } Create a class called Third that extends Second and defines a test() method. What exceptions can Third�s test() method throw? Select all valid answers. a. Exception1 b. Exception2 c. no checked exceptions d. any exceptions declared in the throws clause of the Third�s test() method.
My Answer: a, b, c
Correct Answer and explanation:
Question 28: c. A method in a subclass cannot add new exception types that it might throw. Since it�s superclass, Second, does not define any exceptions in its test() method, Third can�t either. (See chapter 8.)
I assumed that Exception1 and Exception2 extended Exception. The given answer would be correct only if Exception1 and Exception2 extended RuntimeException.

[This message has been edited by Betty Reynolds (edited April 21, 2000).]