Re: need help about code mobility

Brian Pontarelli wrote:
> Niclas Hedhman wrote:
>> On Friday 29 December 2006 11:38, Brian Pontarelli wrote:
>>
>>> I highly doubt this was arrogance. More than likely a language
>>> barrier issue.
>>>
>>
>> Point taken. Still, general advice to everyone: If you want help, listen to
>> what the helper is asking for.

+1

>>
> Agreed. And I think as the mail lists move over a set of guidelines will
> probably be setup as part of the Apache process. This will help in
> guiding newer users, but there will still be a lot of users who don't
> read them, so be prepared.
>

If a lot of users won't read them, why would we waste the effort writing
them?

IMHO, we are all grown up enough to know about social contracts and how
to behave on mailing lists same as we all know enough to behave
appropriately in public/at work.  Those social contracts change over
time and are defined by the community as a whole.  And if someone
breaches the contract, the community as a whole should speak up.

And, as an experienced helper there's probably a few things I'd mention:

(1)     It costs me time and effort to provide help - I look for signs that
the helpee is putting in similar effort (e.g.  I don't want to see
endless questions which could be answered better by existing
documentation that the helpee should go wade through just as I have).

(2)     Some people can't be helped - you ask for information and they don't
provide it for one of many reasons.  I've personally lost count of the
number of times I've seen someone complain they get an exception without
naming it and posting the stack trace.  I also marvel at the number of
people that can't simply copy the contents of the console output and
mail it.  That said, we do have one consistent troublespot to work on
and that is network config - we need a better way to collect up and
communicate that information - network diagrams with IP addresses,
location/position of firewalls etc.  This isn't easily solved by a tool
as that can only capture config local to a machine and that often is not
the issue.

(3)     Some people can't be helped part II - they listen to your advice,
ignore it and proceed in their own direction - nothing wrong with that
but if you walk your own path, you can't expect others to walk it with
you, though they might.

>
>>> BTW loadClass can eventually call defineClass, which can throw a
>>> NoClassDefFoundError. I didn't test but if I recall correctly this happens
>>> during linkage to parents, interfaces, etc.
>>>
>>
>> Correct, NCDFE happens when the loaded(!) class is being resolved (afaik not
>> during defineClass), i.e. the referred classes are linked and possibly
>> loaded.
>>
>> But, cl.loadClass( "B" ) will not generate "NCDFE: class B".
>>
> It occurs in the defineClass and not in the loadClass. What happens is
> that if the class being requested can be loaded but something it extends
> can't, you get the NCDFE. The reason is that the extended class is
> linked to in defineClass. Here is an example stack trace that
> illustrates this:
>
> Exception in thread "main" java.lang.NoClassDefFoundError: A
> � � � � � � � at java.lang.ClassLoader.defineClass1(Native Method)
> � � � � � � � at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> � � � � � � � at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> � � � � � � � at
> java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> � � � � � � � at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> � � � � � � � at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> � � � � � � � at java.security.AccessController.doPrivileged(Native Method)
> � � � � � � � at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> � � � � � � � at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> � � � � � � � at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> � � � � � � � at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> � � � � � � � at
> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>
>
> Here is the code:
>
> public class A {
> }
>
> public class B extends A {
> }
>
>
> Here is the command line:
>
> rm A.class; java -cp . B
>
>
> What happens this:
>
> 1. B is loaded
> 2. B is defined (i.e. all of its parents and interfaces are resolved and
> loaded) and everything is linked together.
>
> Since A.class is not in the classpath (since I removed it prior to
> running B), during linkage of B in step 2 a NCDFE is thrown.
>

Yep - as the JavaDoc for NCDFE says:

"Thrown if the Java Virtual Machine or a ClassLoader instance tries to
load in the definition of a class (as part of a normal method call or as
part of creating a new instance using the new expression) and no
definition of the class could be found.

The searched-for class definition existed when the currently executing
class was compiled, but the definition can no longer be found."

Note this statement re: compilation ^^^^^^^^^^^^^^^^^^^^^^


Dan.

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]