Rob Shields

I notice that the file starts with the iso-2022-jp escape sequence 1B 24 42 which is defined here as the escape sequence for the charset JIS X 0208-1983, as part of is-2022-jp-2.

I have tried using is-2022-jp-2 as the charset, but this not supported by Java 1.5.

I supposed I could manually parse the escape sequences and try a different charset.

Oops, that HTML-encoded text should look like:

纊鍈昱曻伀佖侔倞傔冝匀咜喆埇夋奣孖寘

Just as a correction, it doesn't actually look like garbage when is displayed, it looks like this:

������������������

The file I linked to displays properly in a web browser when you select iso-2022-jp as the encoding.

However, when I copy the text from my browser into a new text file in gedit and hit file -> save as and choose iso-2022-jp as the encoding, it says:

The document contains one or more characters that cannot be encoded using the specified character coding.
Select a different character coding from the menu and try again.

I guess this may be a clue.

Trying to load and display some iso-2022-jp characters, but they just look like garbage. Tested with Java 1.5 and 6. It's supposed to look like this:

纊鍈昱曻伀佖侔倞傔冝匀咜喆埇夋奣孖寘

File is saved here.

Here's the code I'm using to load and display:

import java.awt.Font; import java.io.File; import java.io.FileInputStream; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; import java.io.Reader; import javax.swing.JFrame; import javax.swing.JLabel; import javax.swing.JTextPane; public class Viewer { /* * HelloWorldSwing.java requires no other files. */ /** * Create the GUI and show it. For thread safety, * this method should be invoked from the * event-dispatching thread. */ private static void createAndShowGUI() throws IOException { //Create and set up the window. JFrame frame = new JFrame("HelloWorldSwing"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); //Add the ubiquitous "Hello World" label. JLabel label = new JLabel("Hello World"); frame.getContentPane().add(label); InputStream is = new FileInputStream(new File("JISCharacters.txt")); Reader r = new InputStreamReader(is, "iso-2022-jp"); // r = new RemoveHTMLReader(r); StringBuffer sb = new StringBuffer(); int i; while ((i = r.read()) != -1) { char c = (char) i; sb.append(c); } JTextPane textPane = new JTextPane(); textPane.setText(sb.toString()); Font font = new Font("Kochi Gothic", 0, 24); textPane.setFont(font); frame.getContentPane().add(textPane); //Display the window. frame.pack(); frame.setVisible(true); } public static void main(String[] args) { //Schedule a job for the event-dispatching thread: //creating and showing this application's GUI. javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { try { createAndShowGUI(); } catch (IOException ioe) { System.out.println(ioe); } } }); } }

You may have to change the font for your system. It's definitely not the font, since I have successfully loaded and displayed the following HTML-encoded version of the text:

纊鍈昱曻伀佖侔倞= 傔冝匀咜喆埇夋奣孖&= #23512;

Hi

Wouldn't life be easier if we could use any checked exceptions

Indeed.
I wonder what a C# developer would do - they don't have checked exceptions

Rob

Are you sure you don't need garbage collection? What is to be gained by turning it off if it's not required?

Can you post the error message you're getting?

Also try typing echo %CLASSPATH% at the command prompt to see the contents of the classpath system variable.

Hi Jared,

I'm currently facing the same questions as you, here are some of my thoughts.

I think that an IOException is usually pretty terminal (e.g. someone removed the hard disk or network cable, or some low level OS failure), so there may be little point trying to recover from it. One execption I can think of (of which there are probably many more) is EOFException, which is-an IOException, thrown from RandomAccessFile read methods if you try to read beyond the end of the file. In my case, that should never happen, so if it does, I'll probably choose exit too. Popping up a message in the client telling the user that the application will exit would probably be acceptable, like Matt suggested. One other option I thought of would be an Abort, Retry, Fail box, but that would require more code.

With regard to your other question, consistency is important for code maintainability. Also, it may not be appropriate to nest certain exceptions e.g. an IOException nested within a RecordNotFoundException might not make sense.

Rob
[ October 13, 2004: Message edited by: Rob Shields ]

Hi

IMO throwing unchecked exceptions is far more desirable than using error codes. If you use error codes, you're taking a journey back in time.

It may not be as desirable as throwing checked exceptions, but part of the assignment is to overcome these obstacles in the best possible way, given the constraints.

Rob
[ October 13, 2004: Message edited by: Rob Shields ]

From the Javadoc:

Output operations that write past the current end of the implied array cause the array to be extended...

It is generally true of all the reading routines in this class that if end-of-file is reached before the desired number of bytes has been read, an EOFException (which is a kind of IOException) is thrown. ...

seek():
Sets the file-pointer offset, measured from the beginning of this file, at which the next read or write occurs. The offset may be set beyond the end of the file. Setting the offset beyond the end of the file does not change the file length. The file length will change only by writing after the offset has been set beyond the end of the file.

Hi

Writing beyond the end of the file should cause the file to be automatically extended without this exception being thrown.

Are you sure you're not trying read beyond the end of the file, because that would cause EOFException to be thrown.

Rob

Hi

Originally posted by Omar Kalaldeh:

I am not sure if the picture gets clear.

Yes, perfectly clear, thankyou

So my lock and unlock methods now look like:

/* (non-Javadoc) * @see suncertify.db.DB#lock(int) */ public long lock(int recNo) throws RecordNotFoundException { synchronized (lockMap) { while (recordIsLocked(recNo)) { try { lockMap.wait(); } catch (InterruptedException ie) { logger.log(Level.WARNING, "Thread interrupted.", ie); } } synchronized (raf) { if (seekToRecordNum(recNo) && !isDeletedRecord()) { lockMap.put(new Integer(recNo), new Long(++lastLockCookie)); return lastLockCookie; } else { throw new RecordNotFoundException("Record " + recNo + " does not exist in this database."); } } } }

The other methods are still synchronised on the RandomAccessFile instance.

Thanks for your help.
Rob

[Andrew: I have removed some of your posted code, as we do not allow major sections of the assignment to be posted in this forum. The locking code is worth 20% of the assignment, and this is far too much to post in total. This policy is described in the question "What is the policy on posting questions I saw on the exam / details of how to do the assignment?" in the JavaRanch SCJD FAQ.]
[ October 12, 2004: Message edited by: Andrew Monkhouse ]

Hi Omar

Again I am talking about unLock method not delete method.

Sorry, yes, I meant unlock, not delete.

$myPost =~ s/delete method/unlock method/;

Rob
[ October 12, 2004: Message edited by: Rob Shields ]

Noooooooooooooooooooo,

you should Lock\Unlock records in deleting just like any other database method, what I was saying there is no need to throw RecordNotFoundException in unLock method

Righty-ho, I'm glad we've got that cleared up

The only thing I'm concerned about is why would the delete method be declared to throw RecordNotFoundException if it's never going to be thrown? Do you think there's a chance of being marked down for not throwing it? After all, it's no much trouble to catch and ignore it if you have just deleted the record.

Hi

I have a LockCookieGenerator to generate the unique cookie.
I turn the concept of DataAdapter into session facade so that the Data is a singleton. So I can use "synchronized" on the Data object, say the methods in Data other than modifying database are synchronized. I also model the lock as a object, not a pair of cookie/recNo values.

Yes, I was thinking of having the data object as a singleton and synchronised that, but it says in the requirements:

You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.

So I took that to mean there was no need to make a singleton, although I'm thinking of making one anyway just to be sure

It sounds like you have gone to more effort with the cookie generator na dlock object. I'm trying to do the bare minimum to meet the requirements, on the basis that I'm less likely to make mistakes that way.

Regards,
Rob

Hi

what is raf? I am assuming its the file object.

Yes, it's the RandomAccessFile instance I'm using to read, write and seek.

I think You should put the synchronization block on the Map object.

Just for the lock and unlock methods, or for all of them? What is the reason for this?

No need to throw exception when waiting thread get Interrupted.

Should I just log it instead?

Should throw securityException not IllegalArgumentException.

D'oh! I was wondering what the SecurityException was for..

Thanks for your help.
Rob