Re: retrieve data from hashtable
christopher_board@yahoo.co.uk wrote:
I am currently developing a java application that allows the user to
"Java" application"
wake up computers using Wake On Lan. The program reads in a CSV file
whic has the computer names and there MAC Address. Once the file has
been read it then populates a HashTable to add the records. What I
Do you mean 'Hashtable', as in java.util.Hashtable, or do you actually mean
'HashTable', in which case tell us more about that class, where it's from,
etc. (Your code sample used only 'Hashtable'.)
Unless you really need coarse-grained synchronization (ConcurrentHashMap is
the better choice) or the obsolete, non-Collection methods of Hashtable, you
should use a different Map implementation from Hashtable.
would like to happen is when the user selects a computer name from
the JList on the application it searches through the hashtable [sic] to
find its MAC address. However whether I use the variable used for
the computer name or hard code the computer name into the program it
keeps on returning null and am not sure why this is happening.
Gordon Beaton wrote:
You've created a new Hashtable for each line you read from the file,
i.e. one table per computer, instead of one Hashtable for all entries.
Presumably your code will work if (and only if) the user chooses the
host that was last in the file.
Also, your diagnostic message ("Retrieving data for") only looks for
CBO_TEST, regardless of the user's choice.
A couple of small points:
- Do not use TABs for Usenet post source-code indentation. Use spaces (2, 3,
or 4 spaces per indent level recommended).
- Watch out for line breaks. You had a long string break up over a line
boundary. (TABs make this worse.)
- Members are initialized to null by default. In your code:
public class WakeOnLan {
Hashtable macTable = null;
String ipStr;
String macStr;
String mac;
you redundantly set macTable to null but not the other members. The '= null'
was not actually needed. It appears that this redundant initialization is
related to the error that Gordon Beaton pointed out, that you set the
'macTable' member to a new Hashtable (or whatever Map) each time through the loop.
- It is not a good idea to embed implementation ('Table') in a variable name
('macTable'), in that a new implementation would require renaming the variable
('macMap'). Use variable names that represent the algorithmic role
('macAddresses'), not the implementation.
- Watch out for using the wrong API classes:
FileInputStream fstream =
new FileInputStream( "/path/to/DHCP Export.csv" );
// Get the object of DataInputStream
DataInputStream in = new DataInputStream(fstream);
BufferedReader br = new BufferedReader( new InputStreamReader(fstream) );
You should not DataInputStream.
<http://java.sun.com/javase/6/docs/api/java/io/DataInputStream.html>
A data input stream lets an application read primitive Java data types
from an underlying input stream in a machine-independent way.
You should review the Javadocs before you use such classes. In this case
they'd have steered you away from DataInputStream.
It is not for reading character data. Wrapping your input in a Reader is a
dead giveaway that DataInputStream is the wrong kind of InputStream. Just
wrap your reader around the FileInputStream, or use a FileReader instead.
- System.out.println() is the worst logging tool available. Use a logging
library (java.util.logging is part of the language, for Pete's sake, and
Apache log4j is free and powerful), or at the very least, use System.err. For
the kinds of logging statements that you showed, you should use none of the
above - a debugger would give you what you want and not require that you
rewrite (and possibly damage) the program before deployment.
The problem with instrumentation that you have to remove is that the code you
deploy is not the code that you tested.
--
Lew