Twisted <twisted0n3@gmail.com> wrote:
Now you're ust being silly. Are you intending to put
- properties files
- help text
- localization data
- any of many other resources..
..'stitched in' to the code?
If it gets complex enough to involve such, then there will be separate
files for some of those, and I'll have to worry about how to get a user
directory in a system-independent way to put the properties files in,
and how to get the app's directory to look for help and non-English
localizations in.
Actually, getResource is exactly the solution to everything you are
mentioning. Nothing is stored in some directory on some disk somewhere.
Everything is stored in the same JAR file with all of your code; one
file that you can distribute around that contains the whole application.
All this, and you don't have to do kludgy things like build images into
the source code of your classes.
(By the way, if exceptions should never happen, as is the case when
using getResource on a resource that's packaged in a JAR file with your
application, then it's pretty trivial to add
try
{
...
}
catch (SomeException e)
{
throw new RuntimeException(e);
}
No information is lost, and you don't have to write any complex error
reporting code or anything like that. Just be careful that you don't
catch some exceptions indicating real plausible problems like this.)
become a requirement. Putting resources into the code itself is what we've
been trying to get away from for all these years. That's why we have rc