Originally posted by Mark Fletcher:
Aha!
Ive got it working, heres what I did.
Running the last line successfully runs the driver program
Thanks for the pointers Michael!
To Mike, can you try this on your PC and see if you get the same results?
Cheers,
Mark
Originally posted by Rob Ross:
Full article here: http://java.sun.com/j2se/1.4/compatibility.html#source
(Item #8)
Originally posted by Greg Brouelette:
Mike: I just want to make sure I understand what you're saying because now it might be "me" that's misunderstanding.
Are you saying that A.java is in the com.hamilsci package BUT it's not in the com/hamilsci directory? Instead it's in the . directory. However, when you compile it you want it placed in the com/hamilsci directory ?
If so then may I ask why? I'm not flaming or anything I just want to know if there is a business case for placing the source files in a directory structure that doesn't match the package structure.
Thanks
Originally posted by Greg Brouelette:
As I've said, that is not a limitation, I think you misunderstood Rob. Let me try to help clear this up with an example.
Originally posted by Rob Ross:
Two things:
first, your directory structure must match your package hierarchy. If you declare that class A is in package com.hamilsci, then your source file A.java MUST be in a directory tree ./com/hamilsci/A.java.
*************
What u r saying is not always true. My dir structure is /usr/local/java/examples/com/hamilsci
And I should have A.java either in /usr/local/java/examples/com/hamilsci or /usr/local/java/examples.
In second case however while compileing I've to use javac -d . A.java
*************
The "./" in front of com just means that whatever directory the com directory is in, THAT must be in your classpath.
********************
CLASSPATH variable contains both the directory structure. I mean i've correct CLASSPATH setting
********************
For example, say your com directory is in a directory called foo:
foo/com/hamilsci/A.java
you must include the directory "foo" in your classpath. That way, the compiler and the JVM can location your A.class file in the right package.
Your next problem is that you must understand ALL classes are in a package. The package is the basic unit of organization in a java program. If you don't explicitly include a package statement in your source file, that class gets added to the "default" package.
However, this "default" package should only be used for "hello-world" type applications. If you're going to be creating more than one class for your java app, don't use the default package. You cannot import classes from the default package in jdk1.4, so they're basically useless to you. I would suggest for your program that you put your class B in the same package as class A.
*****************
Does you mean that from jdk1.4, you CANNOT make use of classes from default package(without package structure). If that's the case I think this limitation will break many people's code. I know its good to use the package sructure but right now we hava already developed an application using classes from default packages. I CANNOT chn that. I've that limitation. I'd appreciate you can suggest any other solution.
***************
[ March 11, 2002: Message edited by: Rob Ross ]
Originally posted by Mark Spritzler:
Congrats Mike
Mark
Originally posted by Roman Rytov:
Congrat!!!
What's your next step?
Originally posted by Mathew Sam:
In the LockManager class i have only two synchronized methods.Do I need to sychronize the access to the HashMap like
synchronized(locks) { }
class LockManager {
private HashMap locks = new HashMap();
pubilc synchronized void lock (){
// Access HashMap
}
pubilc synchronized void unlock (){
// Access HashMap
}
}
Originally posted by Andre Mermegas:
I was thinking of doing something like
wait(10000); if its a full database lock
and there are current record locks.If the
records are'nt unlocked by then, there may
be a problem with the client who made the
original lock.
what ya think?
Originally posted by Richard Walter:
Just would like to confirm that you do not need to lock the record if you just want to get a record from the database with no itention of modifying it.
My concern is that without locking the record, another client might be modifying the record while Im reading it, therefore I might get some erroneous data in my record.
I presume this will not happen as the getRecord and modifyRecord are both synchronised in the Data clas, thus preventing a read while a record is being written.
In my current implmentation I lock the record before reading it. If a connection attempts to read a record without obtaining a lock first an exception is thrown. I think this is all uncesssary.
am I right in my thinking or am I missing something?
Thanks,
Rich
Originally posted by Mark Spritzler:
What about a little bit of recursion. That way you don't have to keep track of who has locks, and who is waiting.
It will wait just like the rest of the threads for a lock on a record that someone else has. Eventually it will get all the locks, and you will have a database lock.
Just an idea
Mark