General Java Questions - IV

General Java Questions - IV

Q: I need to programmatically replace an entry in a zip file.
I could not quite get it using the ZipOutputStream because it simply creates a new file and write
only that entry for me. The rest of the original entries are gone.
Does anyone have a solution for this?
Answer:
1) Read the file (myfile.properties) out of the original Zip Archive (original.zip)
2) Make your changes, write the file to the file system
3) Create a New Archive (originalNew.zip)
4) Write your edited file (myfile.properties) to originalNew.zip
5) loop through all the entries in the original Zip archive (original.zip), adding them to the new
archive (originalNew.zip) EXCEPT for the file you are replacing (myfile.properties)
6) When you're done, erase the original and rename your new one to original.zip.
I believe that this may be the only way to do this, since there doesn't seem to be any random
access in the ZIP file.
--
Kevin T. Smith
Q: What is better to use: array or vector?
Just wondering as I am using Vectors to store large amounts of objects from 50 to 4000 and
file:///C|/330_new/330_new/general_java-IV.htm (1 of 6) [2003-07-22 22:07:55]
General Java Questions IV
each one has to be "looked at" every time paint is called...
Just wondering if it would be better to use an array, list etc?
Answer 1: Since the Vector method uses an array for storage but has extra steps involved in
getting an element, use an array for fastest access.
--
WBB Java Cert mock exams http://www.lanw.com/java/javacert/
Answer 2: arrays are faster, vectors are more dynamic.
This should be evident just looking at the amount of code you need to traverse one versus the
other. It might also be beneficial to write a linkedlist class and use that. That way you have a
dynamic container which has potential to be faster than a vector (though still not as fast as an
array). The problem with arrays is that if you need more space than the current size, you have
to hardcode their copying into a bigger array.
Conversely, if you never (or rarely) use the entire array, its a waste of space and memory.
The following are benchmark test results of vector vs. array (ran on a 200-Mhz Pentium w/ 96
Mbytes of memory and Windows95 ):
Allocating vector elements: 17910 milliseconds
Allocating array elements: 4220 milliseconds
Accessing Vector elements: 18130 milliseconds
Accessing array elements: 10110 milliseconds
One other reason for vectors being slower that I did not mention above is that vector methods
are synchronized, which creates a performance bottleneck.
Hope this helps
--
MSW
Q: Would anyone know the performance issues regarding Vector's?
I am actually talking about resource pooling. I have objects that wait in a queue. It is a vector
that keeps growing, as the queue gets bigger.
Do Vectors have much performance hit? Is there a better way to implement vectors to get the
best out of them? Or am I better of creating a fixed size array?
Answer 1:
If you just want a LIFO or LILO queue, you may be better off with
LinkedList than with Vector, as then you'll never have to wait for the contents to be copied.
Vectors perform pretty well, but if you know (even roughly) how big you're going to need it to
be, specifying that in the constructor call can help.
How sure are you that this will be a performance bottleneck? Premature optimisation is the root
file:///C|/330_new/330_new/general_java-IV.htm (2 of 6) [2003-07-22 22:07:55]
General Java Questions IV
of all evil...
The Vector class is thread-safe. By that I mean that there is no way to corrupt the internal
representation of the data by accessing the vector from more than one thread. However, it is
still possible, very easy in fact, to use a vector in a way that is not thread safe.
Consider this code:
for (int i = 0; i < vector.size(); i++) {
System.out.println(vector.elementAt(i));
}
It looks safe, but there's a subtle flaw...
Q: More about Robot! I met with a problem in using class Robot.mousePress...
The compiling process is successful. But when I run it, I receive "IllegalArgumentException:
Invalid combination of button flags". I don't quit understand this information. Part of my code is
as following:
Robot rMouse=new Robot();
int button=1;
rMouse.mousePress(button);
rMouse.mouseRelease(button);
I am really confused. Will you please give me some advice? Thank you in advance!
Answer: You are not using a valid value for the argument to the mousePress() and
mouseRelease() methods. If you check the API documentation, you'll find the valid values are a
combination of one or more of the following constants:
InputEvent.BUTTON1_MASK
InputEvent.BUTTON2_MASK
InputEvent.BUTTON3_MASK
plus others which represent the Ctrl, Alt, and Shift keys. To press the left
mouse button, you want to use:
rMouse.mousePress(InputEvent.BUTTON1_MASK);
--
Lee Weiner
Q: In what situation an exception has to be caught otherwise the compiler will complain?
e.g. IOException does NOT have to be explicitly caught, however, SQLException has to be
caught otherwise VisalAge will not compile the program.
Answer: The only unchecked exceptions in Java are RuntimeException and its subclasses.
file:///C|/330_new/330_new/general_java-IV.htm (3 of 6) [2003-07-22 22:07:55]
General Java Questions IV
This includes such familiar classes as NullPointerException, ClassCastException, and
IndexOutOfBoundsException.
IOException is not one of these, and *does* have to be explicitly caught or thrown
--
jeff_robertson
Q: I wrote a program that use a few RS232 ports. The operators are unskilled and often
start multiple instances of the program. Will someone please be so kind and tell me how I can
prevent them doing it?
Answer 1: The first instance might write a file. Subsequent instances could check for the
existence of that file, or else check it's contents.
Another method could involve creating a server socket on a specific port. Subsequent efforts to
create a socket on that same port would throw an exception.
Answer 2: Actually a better way is to (on launch):
1) Check if the file exists. If not, create it, open it and run. Leave it open until you quit, upon
which time you close it.
2) If the file _does_ exist, try to delete it. If the delete fails, then someone else has it open,
which means another copy of your app is running. Inform the user and quit.
3) If you succeeded in deleting it, then you are the first. Now create, open and run.
Doing the above prevents the problem of having the semaphore file left around when the
system crashes. I implemented it recently in one of our apps, and it works like a charm.
--
Burt Johnson
MindStorm Productions, Inc.
http://www.mindstorm-inc.com
Q: Can you call a class static abstract method from an abstract class or does it need to be
extended and then called from its concrete class?
I've been told that abstract classes do not actually have any code in them cause they are like a
placeholder, so I guess you wouldn't bother calling a static method in an abstract class cause it
wouldn't have any code to begin with....?
Answer: You have been told wrong. Abstract classes can and do have code in them.
See, for example, java.awt.Component, an abstract class with a lot of code and no abstract
methods at all. If a class has any abstract method member, directly declared or inherited, it is
required to be declared abstract. If not, it is the programmer's decision and should be based on
whether it would make sense to have an instance of that class.
Perhaps whoever told you was confusing abstract classes with interfaces, which don't contain
file:///C|/330_new/330_new/general_java-IV.htm (4 of 6) [2003-07-22 22:07:55]
General Java Questions IV
implementation, only abstract method and constant declarations.
You cannot declare a method to be both static and abstract. Abstract requires the method to be
overridden before you can have a concrete class, static prevents overriding. You can have a
static method in an abstract class - such a method could be called without creating an instance
of the class, the only thing that is prohibited for abstract classes.
And when a subclass of an abstract method has been instantiated, all the methods from the
original class will keep the same code in the instance. Most of the time an abstract class will
have abstract methods.
However, there are several examples of abstract classes that don't have any abstract methods
at all. Some examples are Component and FontMetrics from the AWT. It doesn't make sense
to have just a Component that's not a specific type of component. It doesn't make sense to
have a FontMetrics that doesn't measure any specific kind of Font.
Also being abstract never prevents overriding, it just requires overriding in order to derive a nonabstract
subclass. And if a class is a subclass of an abstract class, it only MUST override those
methods declared abstract. The other methods do not require overriding.
Q: I write java about 2 years, but I still confuse one thing that is why should we use
interface???
If I need to implement an interface and just use its every methods name.
Why shouldn't just write every methods statments in a class, not in interface??
I only can think about that if I extend a class, than can implement another or the others
interface.
As you can saw, I really confuse about this. And I do see many books for the reasons , but I
can't get the answer, please tell me !
Answer: "Interface" is the Java way to do multiple inheritance, or a better way to think of it is as
a way to design plug-ins.
For example, let's say we have an application that monitors a network of computers. Our
monitors might check for web pages, or they may check for other ports, or they may have
hooks for hardware checks.
The interface to our main control panel is always the same: We need some means to poll the
monitor object for an answer. This is the "NetworkMonitor" interface and all network monitors
will share this interface, but they may have a class heirarchy that is very different, for example,
port-monitors may all fork a thread that periodically checks whereas our control panel interface
just asks for the most recent answer; hardware monitors may ask for their data in real-time or
over RPC and thus have no need of inheriting from Thread.
Because they share the same Interface definition, the control panel application does not need
to know if they are polling monitors or real-time monitors because, from the control panel's
point of view, it does not matter

No comments: