Bob Chandler

Ranch Hand
+ Follow
since Jan 13, 2004
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Bob Chandler

Hey Joel,

statement at the top of each src file is:
package project.db;

oh my God!....lightbulb moment!

I just changed the package statement to:
package db;
and everything now compiles

What was I thinking?
Cheers Joel and Ray - now I can get some work done, yay!
15 years ago

yeah, I checked the classpath issue and I'm thinking that's not the problem - the classes in question are all grouped together in a dir called db which, in turn can be found in my project dir.

The compiler should be able to find all the classes as it comes across references to any one of them.

So, in conclusion:

Cabin class 'has-a' instances of BookableDate - compiler says...
Cannot resolve symbol: class BookableDate

BookableDate class 'has-a' instance of Guest - compiler says...
Cannot resolve symbol: class Guest

Guest has no references to the other classes and compiles fine.

All 3 classes live in c:\project\db\[classname]

It's the simple things that get me!
Bob (a bit fed up as it goes) Chandler
15 years ago
hey guys,

got a problem compiling source code that worked perfectly well before I moved all my .java files and .class files into a new folder.

All .java files now include a package statement at the top, I changed directory on the command line ...

Compiler can read the file (, but can't recognise an instance of another class ( that is created in it.
i.e. Cabin has-a BookableDate

I tried to compile BookableDate, but compiler does not recognise Guest instance within it
i.e. BookableDate has-a Guest does compile.
What's all that about?

(confused) Bob
15 years ago
for some reason, this forum will not let me add a reply to a post that I start....pah!!
so once again I hope that Jeanne picks this up...
I read your post with interest and, on closer inspection, I have found that the records causing the exception were created before I made further development of the class structure.
I have removed the offending data, re-populated the db and the problem seems to have been resolved
Thank you so much for your help.
all the best,
Due to the fact that I was unable to continue with my last topic, I have to begin a new one:
Here is the story so far...
Bob Chandler
ranch hand
Member # 64584
posted May 05, 2004 08:01 AM
Hey there Java peeps,
having problems with some code I'm working on... hope you can help.
I have a class that implements Serializable and, therefore has serialVersionUID number when I run serialVer tool. I'm clear about this part.
However, when I run the part of my code which is retrieving a record from the database, I sometimes get an error that reads:
an Exception occurred: Cabin; local class incompatible: stream classdesc serialVersionUID = 3448415719576074304, local class serialVersionUID = -1390977758539970494
If I have created the record in the current session, it runs ok....
Any suggestions?

Posts: 31 | Registered: Jan 2004 | IP: Logged

Jeanne Boyarsky
Member # 50496
posted May 05, 2004 06:07 PM
Well it's saying that you changed the serialver id. When this id changes, you are stating that the object should not be read in.
Did you change the id on purpose? Are old objects in the database from a previous deployment with a different id?

Posts: 916 | Registered: May 2003 | IP: Logged

ok, Jeanne, I have not changed or even referred directly to the serialver id in my code.
What's this about previous deployment?
I have written methods that retrieve, modify and persist records back to the database (db is nothing fancy, just a folder in the same directory as my other code files)
The data is still there ie. it doesn't disappear between sessions and the relevant classes implement serializable.
Maybe there is something I don't yet know about - but I just want to be able to access my stored data...
I have much to learn (chuckle)....
once again, thanks for the tips - and yes, I will attempt
to write the conversion code.
Thanks for all of your responses...

I have no idea if I am right, but isn't the source code written in the book?

Mark and Andrew, there is a snippet of DVDDbAdapter in the book, but I wanted to view the class in it's entirity
I made a lil' mistake when I viewed the downloaded file, though....
A cursory glance had me thinking in was in bytecode'd thinmk the .java file extension would be a dead giveaway :roll:
turns out it is in fact the source file in question, but without any structured format (i.e. spaces appear as square boxes and there's no white space visible - just a jumble)
I will endeavour to re-format it by hand later - but thank you guys for all your helpful comments
Foolish Bob
Hey guys,
does anyone have a copy of the actual source code for DVDDbAdapter
class (Max Habibi study guide example project)?
It's the only one that downloads from as a class file and
I would really like to take a look at the source.
apologies - my question wasn't clear...
The 'rule' or concept I was referring to was indeed the blank line
at the end of a file.
So thanks for the explanation, small issues like this one may seem
'a detail hardly worth mentioning' to the more advanced programmer/developer, but is something that had me scratching my head
for days - very frustrating!
(grateful) Bob

Try adding a blank line to the end of your manifest file. Java sometimes has a problem reading that file at runtime if it does not have a trailing blank line.

How wierd is that?
I checked the order of params which was ok - then I tried adding the blank line as you suggested.....well, I can't worked!
Cheers mate
btw, does this rule apply to any other file types in other contexts?
just curious...
Bob (not crazy after all) Chandler
I'm working through the Java Developer Exam study guide - chapter 8, compiling and packaging the application.
Page 320 explains the role of the manifest file and goes on to give the content which tells the JVM where to start running the application from...
ok, I understand all that.
Managed to create the JAR file but when I try to run the application, the
message on command prompt reads....
'Failed to load Main-Class manifest attribute from sampleproject .jar'
The Manifest file I made was in notepad but I changed the file extention to
type .MF
I read an article on modifying a manifest file....

The Jar tool's m option allows you to add information to the default manifest during creation of a JAR file. You must first prepare a text file containing the information you wish to add to the default manifest. You can then use the Jar tool's m option to add the information in your file to the default manifest.
The basic command has this format:
jar cmf manifest-addition jar-file input-file(s)

So, in that case, shouldn't my own file have a .txt extension?
Hope you guys can help Bob
[ March 27, 2004: Message edited by: Bob Chandler ]
you were absolutely right with the classpath solution!
Everything was in order as regards system settings, but
I was trying to access my code from the command line in
completely the wrong way.
Thanks so much for your help
15 years ago
Hey ppl,
picture this....
I have 3 java source files each starting with the same package declaration, and each defining a separate class (ClassOne, ClassTwo & ClassThree).
They are saved in the same directory bearing the package name.
ClassOne compiles fine.
ClassTwo and ClassThree use instances of ClassOne and will not compile.
(there is an error for every mention of the ClassOne instance)
Does anyone know why the compiler can't see ClassOne?
Cheers, Bob
15 years ago
thank you so much for this detailed explanation, now it
makes more sense to me and I shall be more organised in future!
...time to empty my junk out of the bin methinks...
cheers mate,
Hey Deepa,
do them all - it can't hurt!
If you feel you're going over the same stuff, check out Javaranch's
mock exam list....
I can recommend Marcus Green's questions - they really helped me!
but there are many others you can try too...
Good luck
Bob (SCJP 1.2, SCJP 1.4)
[ March 12, 2004: Message edited by: Bob Chandler ]