Board index » jbuilder » getClassLoader() again

getClassLoader() again


2003-10-22 02:21:18 AM
jbuilder10
With JBuilder7,
I try to do
URL url = getClass().getClassLoader().getResource("a file that is in the
same directory as the.jpx file");
I also tried to put the file in the bin directory of JBuilder, in the root
of the classPath
It always return a null pointer for url.
What is amasing is that the same code is working with
Eclipse, and BlueJ but it does'nt work in Jbuilder.
Anybody as an idea what to do with JBuilder to automatically find where the
user have put his personnal Read-Write data file just by knowing the name of
that file, without asking user?.
Thanks ,
Guy Perron.
 
 

Re:getClassLoader() again

In < XXXX@XXXXX.COM >Guy Perron wrote:
Quote
With JBuilder7,
I try to do
URL url = getClass().getClassLoader().getResource("a file that is in
the same directory as the.jpx file"); I also tried to put the file in
the bin directory of JBuilder, in the root of the classPath It always
return a null pointer for url. What is amasing is that the same code
is working with Eclipse, and BlueJ but it does'nt work in Jbuilder.
Anybody as an idea what to do with JBuilder to automatically find
where the user have put his personnal Read-Write data file just by
knowing the name of that file, without asking user?.
I thought Tor and Lori answered this a couple weeks ago.
Since you are moving this file around, why not move it
to a place that is "Java sanctioned", that is, where it
would be readable according to the rules used by the
mechanism? You should place this file in the classpath
of your application, not in the project directory.
That means, given the following standard directory
structure in a JBuilder project
d:/myprojects
/thisproject
/bak
/classes
/doc
/src
- myresourcefile.properties
- myimagefile.gif
... etc.
you should place the file(s) in question at least
in the root of the _source_ directory. If you
use JBuilder's standard behavior, .properties and
gif (and other image format) files will be
copied to your "classes" folder upon building the
project. If your resource file is not one of the
ones which is copied by default, go to Project
Properties>Build (tab)>Resource (sub-tab)
and make changes to the "Project-wide defaults
by extension" list.
In addition, if you are making an application
archive, you may control which extensions are
copied into the archive.
A third mechanism for including a file in
the build/deploy output is to add the file
to the project, and alter its "copy/don't copy"
settings in its "Properties" dialog (right-click
on the file's node in the Project Pane, select
"Properties...", and away you go).
(This is all in the online manual which you
agreed to read and understand fully when you
opened the JBuilder box and installed it. If you
haven't done so, be sure to read at least the
section on how JBuilder constructs paths in
the "Managing Paths" section of the manual:
Help (menu)>Help topics>Contents (tab)>
Building Applications with JBuilder (book
topic)>Building Applications (section)>
Managing Paths.)
The fact that Eclipse and BlueJ happen to
allow you to do this is just a non-standard
quirk in their designs. BlueJ in particular is
designed for learning and not producing -- that
means that its author(s) make allowances for
reducing the initial frustration factor of having
to deal with all these kinds of requirements.
Such hand-holding has benefits, but it also has
drawbacks when you are ready to enter the real
world of producing code for a living.
(I remember having to do some hacking to get
it to run on Mac OS X because of assumptions they
made to "make things easier". Based on my input
they changed a few things to make things _correct_
rather than just _easier_ to run anywhere.)
Metrowerks' CodeWarrior used to allow you to put
all .java files in one directory, even though the
classes which those files represented were in
different packages. That makes it _easier_ for
C and C++ programmers who are migrating to Java --
a bulk of Metrowerks customers probably fell into
this category -- but it was just plain wrong according
to the most common interpretation of the Java spec.
You shouldn't base your work on quirks and non-standard
features of any particular IDE. JBuilder follows
the standard quite closely for just about everything,
from developing, running/debugging, and deploying
desktop apps to complex Web apps.
Paul Furbacher [TeamB]
Save time, search the archives:
info.borland.com/newsgroups/ngsearch.html
Is it in Joi Ellis's Faq-O-Matic?
www.visi.com/~gyles19/fom-serve/cache/1.html
Finally, please send responses to the newsgroup only.
That means, do not send email directly to me.
Thank you.
 

Re:getClassLoader() again

Thanks a lot for your excellent answer, Paul
Guy.
"Paul Furbacher [TeamB]" < XXXX@XXXXX.COM >a écrit dans le message de
Quote
In < XXXX@XXXXX.COM >Guy Perron wrote:

>With JBuilder7,
>I try to do
>URL url = getClass().getClassLoader().getResource("a file that is in
>the same directory as the.jpx file"); I also tried to put the file in
>the bin directory of JBuilder, in the root of the classPath It always
>return a null pointer for url. What is amasing is that the same code
>is working with Eclipse, and BlueJ but it does'nt work in Jbuilder.
>Anybody as an idea what to do with JBuilder to automatically find
>where the user have put his personnal Read-Write data file just by
>knowing the name of that file, without asking user?.

I thought Tor and Lori answered this a couple weeks ago.

Since you are moving this file around, why not move it
to a place that is "Java sanctioned", that is, where it
would be readable according to the rules used by the
mechanism? You should place this file in the classpath
of your application, not in the project directory.
That means, given the following standard directory
structure in a JBuilder project

d:/myprojects
/thisproject
/bak
/classes
/doc
/src
- myresourcefile.properties
- myimagefile.gif
... etc.

you should place the file(s) in question at least
in the root of the _source_ directory. If you
use JBuilder's standard behavior, .properties and
gif (and other image format) files will be
copied to your "classes" folder upon building the
project. If your resource file is not one of the
ones which is copied by default, go to Project
Properties>Build (tab)>Resource (sub-tab)
and make changes to the "Project-wide defaults
by extension" list.

In addition, if you are making an application
archive, you may control which extensions are
copied into the archive.

A third mechanism for including a file in
the build/deploy output is to add the file
to the project, and alter its "copy/don't copy"
settings in its "Properties" dialog (right-click
on the file's node in the Project Pane, select
"Properties...", and away you go).

(This is all in the online manual which you
agreed to read and understand fully when you
opened the JBuilder box and installed it. If you
haven't done so, be sure to read at least the
section on how JBuilder constructs paths in
the "Managing Paths" section of the manual:
Help (menu)>Help topics>Contents (tab)>
Building Applications with JBuilder (book
topic)>Building Applications (section)>
Managing Paths.)


The fact that Eclipse and BlueJ happen to
allow you to do this is just a non-standard
quirk in their designs. BlueJ in particular is
designed for learning and not producing -- that
means that its author(s) make allowances for
reducing the initial frustration factor of having
to deal with all these kinds of requirements.
Such hand-holding has benefits, but it also has
drawbacks when you are ready to enter the real
world of producing code for a living.
(I remember having to do some hacking to get
it to run on Mac OS X because of assumptions they
made to "make things easier". Based on my input
they changed a few things to make things _correct_
rather than just _easier_ to run anywhere.)

Metrowerks' CodeWarrior used to allow you to put
all .java files in one directory, even though the
classes which those files represented were in
different packages. That makes it _easier_ for
C and C++ programmers who are migrating to Java --
a bulk of Metrowerks customers probably fell into
this category -- but it was just plain wrong according
to the most common interpretation of the Java spec.

You shouldn't base your work on quirks and non-standard
features of any particular IDE. JBuilder follows
the standard quite closely for just about everything,
from developing, running/debugging, and deploying
desktop apps to complex Web apps.


Paul Furbacher [TeamB]

Save time, search the archives:
info.borland.com/newsgroups/ngsearch.html

Is it in Joi Ellis's Faq-O-Matic?
www.visi.com/~gyles19/fom-serve/cache/1.html

Finally, please send responses to the newsgroup only.
That means, do not send email directly to me.
Thank you.
 

{smallsort}