🚀 go-pugleaf

Ron Albright <moron(at)pobox.com> <Ron Albright <moron(at)pobox.com>> 
wrote:
> I just switched to JBuilder 6 Ent from JBuilder 5. Same
> project using Sun JDK 1.3.1-b24 in both cases to build. On
> JBuilder 6 the following class only builds if the explicit
> import of base class
> com.greenbird.persistence.PersistentRdbmsObject is
> uncommented. com.greenbird.persistence is a required
> library. What's even weirder is that there are several other
> classes from the com.greenbird.persistence lib being
> referenced in the class definition. Why is an explicit
> import of the base class required?

Because otherwise the compiler has no idea what you mean by 
"PersistentRdbmsObject". There could be any number of classes with that 
name in various packages.

> Why would JBuilder have anything to do with this when the build 
> is being done using a Sun JDK?

I don't see why it should ever have built in anything else, frankly.
 
> package com.greenbird.persistence.test;
> 
> import java.sql.*;
> import java.lang.reflect.Field;
> 
> // Builds only if the following line is uncommented
> //import com.greenbird.persistence.PersistentRdbmsObject;
> 
> import com.greenbird.persistence.*;
> 
> public class Jdbc_Test extends PersistentRdbmsObject
> {
> ....< Class definition includes references to
> com.greenbird.persistence.PersistenceException >....
> }

-- 
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

On Tue, 4 Dec 2001 18:12:08 -0000, Jon Skeet
<skeet@pobox.com> wrote:

>Ron Albright <moron(at)pobox.com> <Ron Albright <moron(at)pobox.com>> 
>wrote:
>> I just switched to JBuilder 6 Ent from JBuilder 5. Same
>> project using Sun JDK 1.3.1-b24 in both cases to build. On
>> JBuilder 6 the following class only builds if the explicit
>> import of base class
>> com.greenbird.persistence.PersistentRdbmsObject is
>> uncommented. com.greenbird.persistence is a required
>> library. What's even weirder is that there are several other
>> classes from the com.greenbird.persistence lib being
>> referenced in the class definition. Why is an explicit
>> import of the base class required?
>
>Because otherwise the compiler has no idea what you mean by 
>"PersistentRdbmsObject". There could be any number of classes with that 
>name in various packages.

So you're implying the 'import <package>.*' statement does
nothing? If you have the following 2 imports the compiler
gives an ambiguous reference error if a 'Date' object is
declared without specifying the package.

import java.sql.*;
import java.util.*;

>
>> Why would JBuilder have anything to do with this when the build 
>> is being done using a Sun JDK?
>
>I don't see why it should ever have built in anything else, frankly.
> 
>> package com.greenbird.persistence.test;
>> 
>> import java.sql.*;
>> import java.lang.reflect.Field;
>> 
>> // Builds only if the following line is uncommented
>> //import com.greenbird.persistence.PersistentRdbmsObject;
>> 
>> import com.greenbird.persistence.*;
>> 
>> public class Jdbc_Test extends PersistentRdbmsObject
>> {
>> ....< Class definition includes references to
>> com.greenbird.persistence.PersistenceException >....
>> }


Ron Albright
greenbird(at)KILLSPAM.pobox.com
______________________________________________________________________________
Posted Via Binaries.net = SPEED+RETENTION+COMPLETION = http://www.binaries.net

Ron Albright <moron(at)pobox.com> <Ron Albright <moron(at)pobox.com>> 
wrote:

> >Because otherwise the compiler has no idea what you mean by 
> >"PersistentRdbmsObject". There could be any number of classes with that 
> >name in various packages.
> 
> So you're implying the 'import <package>.*' statement does
> nothing? 

I'm saying that you there is no difference in the compiled class file 
between:

import java.util.*;
public class Test
{
    Vector v = new Vector();
}

and

public class Test
{
    java.util.Vector v = new java.util.Vector();
}

> If you have the following 2 imports the compiler
> gives an ambiguous reference error if a 'Date' object is
> declared without specifying the package.
> 
> import java.sql.*;
> import java.util.*;

I don't see the relevance of this. You just need to tell the compiler 
which to use in preference, eg:

import java.sql.*;
import java.util.*;
import java.sql.Date;

-- 
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Hi Ron,

Jon is right.

The 'import <package>.*' statement does nothing AT RUN TIME.  This makes the
die-hard Java enthusiasts very happy [no conditional compilation].

At COMPILE TIME is a different story...  Per your example, the compiler doesn't
know which Date object you mean.  It merely ASSUMES what imports have told it are
true.  If not [say, you change a method, and somehow its .class doesn't get
recompiled, you have an old .JAR which doesn't match an import, or whatever], you
get a RUNTIME EXCEPTION [when the .class bytecodes are being interpreted].

There's a major difference between the old, compiled languages [Modern Basic
(including VB), Pascal, C, C++, etc.] vs. the newer interpreted bytecode/script
kind of theory [Java, C# (Java ripoff), Python, Perl, JavaScript].  The former
rely on COMPILE TIME LINKING and the latter on RUN TIME CLASS RESOLUTION.  Both
have distinct advantages beyond the scope of this thread.

Sorry; I didn't mean to insult your intelligence.  The discussion just turned on
a light bulb for and old C/C++ jockey I thought I'd try to articulate.

HTH,
JR

On Tue, 4 Dec 2001 22:56:01 -0000, Jon Skeet
<skeet@pobox.com> wrote:

>
>I'm saying that you there is no difference in the compiled class file 
>between:
>
>import java.util.*;
>public class Test
>{
>    Vector v = new Vector();
>}
>
>and
>
>public class Test
>{
>    java.util.Vector v = new java.util.Vector();
>}
>


This in no way explains why the second import statement
below is not sufficient for the compiler to locating the
base class. It implies that the second statement is
sufficient.

//import com.greenbird.persistence.PersistentRdbmsObject;

import com.greenbird.persistence.*;

public class Jdbc_Test extends PersistentRdbmsObject
{
.....
}

Ron Albright
greenbird(at)KILLSPAM.pobox.com
______________________________________________________________________________
Posted Via Binaries.net = SPEED+RETENTION+COMPLETION = http://www.binaries.net

Ron Albright <moron(at)pobox.com> <Ron Albright <moron(at)pobox.com>> 
wrote:

> This in no way explains why the second import statement
> below is not sufficient for the compiler to locating the
> base class.

No indeed. It seems that I misread your post - I failed to spot the .* 
import.

Okay, you've got a different problem: somewhere, you've got another class 
called PersistentRdbmsObject. It may be in the default package, or in 
the test package. If you could say exactly what the compiler error 
message was, we could help further.

Sorry for the confusion...

-- 
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

On Wed, 5 Dec 2001 00:19:00 -0000, Jon Skeet
<skeet@pobox.com> wrote:

>Ron Albright <moron(at)pobox.com> <Ron Albright <moron(at)pobox.com>> 
>wrote:
>
>> This in no way explains why the second import statement
>> below is not sufficient for the compiler to locating the
>> base class.
>
>No indeed. It seems that I misread your post - I failed to spot the .* 
>import.
>
>Okay, you've got a different problem: somewhere, you've got another class 
>called PersistentRdbmsObject. It may be in the default package, or in 
>the test package. If you could say exactly what the compiler error 
>message was, we could help further.
>
>Sorry for the confusion...

"Jdbc_Test.java": Error #: 300 : class PersistentRdbmsObject
not found in class com.greenbird.persistence.test.Jdbc_Test
at line 9, column 32


Ron Albright
greenbird(at)KILLSPAM.pobox.com
______________________________________________________________________________
Posted Via Binaries.net = SPEED+RETENTION+COMPLETION = http://www.binaries.net

Ron Albright <moron(at)pobox.com> <Ron Albright <moron(at)pobox.com>> 
wrote:

> >Okay, you've got a different problem: somewhere, you've got another class 
> >called PersistentRdbmsObject. It may be in the default package, or in 
> >the test package. If you could say exactly what the compiler error 
> >message was, we could help further.
> >
> >Sorry for the confusion...
> 
> "Jdbc_Test.java": Error #: 300 : class PersistentRdbmsObject
> not found in class com.greenbird.persistence.test.Jdbc_Test
> at line 9, column 32

And yet with specific import it works? That's very strange, I'll grant 
you. Have you tried taking JBuilder out of the equation by compiling 
from scratch with the JDK?

I seem to remember someone else having a similar problem ages ago, and 
cleaning everything up (ie getting rid of old classes etc) removed the 
problem, but we never quite understood why...

If you ever manage to come up with a small working set of example files, 
I'd be happy to look into it further for you.

-- 
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

On Wed, 5 Dec 2001 01:40:59 -0000, Jon Skeet
<skeet@pobox.com> wrote:

>And yet with specific import it works? That's very strange, I'll grant 
>you. Have you tried taking JBuilder out of the equation by compiling 
>from scratch with the JDK?
>
>I seem to remember someone else having a similar problem ages ago, and 
>cleaning everything up (ie getting rid of old classes etc) removed the 
>problem, but we never quite understood why...
>

You know, I don't know why I didn't think of deleting the
class files. It's fixed weirdness for me before and it seems
to have done the trick in this case also. I appreciate the
suggestion.

Ron Albright
greenbird(at)KILLSPAM.pobox.com
______________________________________________________________________________
Posted Via Binaries.net = SPEED+RETENTION+COMPLETION = http://www.binaries.net

If you're using JBuilder you should just be able to get away with deleting the
"dependency cache". That way if you've got a load of servlets for example, you
don't have to recompile all of them again.

Bob

On Tue, 04 Dec 2001 20:14:36 -0600, in post
<4b0r0u4b99qcmki1aeslec4n3ji583vvmk@4ax.com>, at opened their fat mouth and
spewed forth:
>
>On Wed, 5 Dec 2001 01:40:59 -0000, Jon Skeet
><skeet@pobox.com> wrote:
>
>>And yet with specific import it works? That's very strange, I'll grant 
>>you. Have you tried taking JBuilder out of the equation by compiling 
>>from scratch with the JDK?
>>
>>I seem to remember someone else having a similar problem ages ago, and 
>>cleaning everything up (ie getting rid of old classes etc) removed the 
>>problem, but we never quite understood why...
>>
>
>You know, I don't know why I didn't think of deleting the
>class files. It's fixed weirdness for me before and it seems
>to have done the trick in this case also. I appreciate the
>suggestion.
>
>Ron Albright
>greenbird(at)KILLSPAM.pobox.com
>______________________________________________________________________________
>Posted Via Binaries.net = SPEED+RETENTION+COMPLETION = http://www.binaries.net

"All I wanted in the end was world domination and a whole lot of money to spend"
- Justin Sullivan

Registered Linux User #228620

On Wed, 05 Dec 2001 10:28:03 GMT, Cowboy
Bob<matt.parker@NODAMNSPAMintertops.com> wrote:

>If you're using JBuilder you should just be able to get away with deleting the
>"dependency cache". That way if you've got a load of servlets for example, you
>don't have to recompile all of them again.
>
>Bob

I wasn't aware of that. That's a useful tidbit of knowledge.