T
Twisted
Thomas said:
Beans, net or otherwise, are outside my scope at least right now.
There's *way* too much Java-related stuff out there (even just from
Sun) to expect any one person to know and use it all.
Beans, net or otherwise, are outside my scope at least right now.
There's *way* too much Java-related stuff out there (even just from
Sun) to expect any one person to know and use it all.
T
Twisted
Ian said:
Create a jar every edit-test-debug cycle? That adds up when you are
rapidly tweaking and adjusting something. As opposed to something you
can just "set and forget".
Hrm. Where is this subdirectory?
You may be missing the fact that I got it working several postings ago?
And in fact before the first reply arrived, once I managed to happen on
a Web page suggesting the method that I used. That page, by the way,
being somewhere in Sun's huge sprawling Java site.
Now, for doing something suggested on Sun's own Web site, I find myself
being harangued and forced to keep posting stuff in my own defense
instead of getting on with my work, in a thread that should be dead now.
J
Joe Attardi
I'm sorry you take it as hostility and bashing. We are all trying to
tell you that what you are trying to do is a really bad way to do it. I
don't understand your resistance to doing it the way that is
universally accepted as the standard way to bundle resources with a
Java app.
I do understand your argument that it's a pain to construct a JAR to
use every time; however, Ant eliminates this inconvenience.
Ant is trivial to use, and has a very short learning curve. When you
set up an Ant buildfile, you can have it automagically build your JAR
file for you.
As I said in an earlier post, why are you opposed to learning how to
use Ant?
C
Chris Smith
Twisted said:
Yes.
T
Twisted
Joe said:
"I'm sorry you..." is not (and never is) a genuine apology.
Sorry; please try again.
Let's consider the following points (ALL of which have been raised
before, but obviously in posts that some participants here have clearly
not bothered to read):
1. At the time I made the initial posting to this thread, a google
search had failed to reveal *any* "standard way" to include icons
whatsoever.
2. Before any replies had been made, further attempts at googling the
topic finally turned up a page on Sun's Java site describing a method
-- the method I actually used. This page also mentioned some other
methods, but those were only applicable to applets, not stand-alone
applications (they involved requesting the icon from a URL, either
relative to document base or code base, from the applet's host server),
while the first method was applicable to both.
3. All of the replies appear to require additional tools (most commonly
Ant). The time investment involved in finding, obtaining, and learning
the additional tools is not justified until I've got more than a single
32x32 gif (and really only if I have stuff that should be localizable
or hot-swappable or something).
I am not. I *am* opposed to the notion that if someone wants to do a
certain thing, then of all the various ways that it can be successfully
done, there is One True Way and anyone who doesn't do it that way,
whatever the additional complications that entails, must Convert Or
Die! (Well, convert or be flamed, anyway.)
Let's see what lessons I would have learned from you lot if I were the
credulous and gullible type:
1. Never research something yourself using Google and figure out a
successful method on your own.
2. Any method that doesn't require lots of work, new tools, and perhaps
expensive new tools is wrong; if you managed to get it done in under
twenty minutes, you can't possibly have done it right.
3. There is only one way to do anything. There are other ways, perhaps,
that appear to accomplish the same thing, but you will bear a stain on
your soul for all eternity, not that this makes any emprical difference
to anything mind you.
4. When the anonymous person on Usenet tells you to do something, you
do it, without question.
5. The very last place to go for trustworthy information on doing stuff
in Java is www.sun.com. Google and wikipedia must also be stringently
avoided.
6. It's far more important to do things the Standard Way(tm) and
conform and fit in than to actually get something working, or to learn
or accomplish things on your own.
7. A simple solution is usually wrong; a complicated one that involves
at least two completely new build tools or distribution tools is
invariably better.
Allrighty then ...
J
Joe Attardi
I wasn't apologizing. I was expressing regret that you are
misinterpreting the advice we are giving you.
-- hyperbole snipped --
You're kidding, right? Lots of work? The approach you are describing
sounds like it's more work. Expensive tools? Yeah, Ant is free, so
there goes that.
-- more hyperbole snipped --
It's not that there's one and only one way and any independent thought
is shunned. But for a simple case like an application's icon, there is
a tried and true method for doing it. It makes sense. You say it's not
worth it because you only have one image. What about designing for
extensibility?
These replies have not been hostile, at least no more than yours have
been. You asked advice, and we gave it. People have a bad habit of
reacting negatively to advice if it doesn't coincide with what they
initially thought - this is not a flame, it's an observation. I do it
too; everybody does it at times.
But please, before you ignore all the good advice that's been given,
really think about what advantage your approach has. And don't be so
hostile just because people don't agree with your approach.
And what's with The Capitalized Phrases and random (tm) ?
L
Larry Barowski
Twisted said:
No they don't. Whatever tool you're using to jar up your
project will also copy the image files, even if you're just using
the "jar" command. But you say you don't have a jar file, so
there is nothing extra you need to do.
D
Daniel Pitts
http://www.google.com/search?num=10...official&q=java+resource+loading+&btnG=SearchTwisted said:
I see quite a few links to ClassLoader.getResource, hmm, how about
that.
Was this in a forum? Just because its on suns site doesn't mean its
reliable.
Actually, most of them suggested using ClassLoader.getResource, and
that if you thought it was difficult to create jar files, try using ant
instead. The suggestion may have been off topic, but it was only meant
to help.
This seems to be what you do, I usually get my information from Google,
or perhaps a book written on the subject.
Actually, it is important to understand standards and to adhere to
common conventions and best practices. Just like the idea of Patterns
helps everyone communicate better, so does using the same approach to
solving the same problems. "I used the State pattern" is a whole lot
more concise than "I used an object that describes this other objects
current state and defines behaviors based on the state." Most
developers will see your use of ClassLoader.getResource, and know how
to handle, most will see your current solution and say "WTF?".
Actually, I think you've come up with a complicated solution.
Step 1, convert image to XPM,
Step 2, run some tool to convert it to a class file.
Step 3, move the class file into the correct place.
Step 4, use some uncommon third party tool to load and convert the
class's data..
Step 5, Fix the third party tool, because it was broken.
Step 6, Fix the third party tool again, because it was broken in
another way.
The way that most of us have suggested takes this form:
Step 1, move or copy your image into a directory in your project
Step 2, use ClassLoader.getResource() to retrieve the resource
Step 3, use standard Sun class (java.* and javax.*) to load the
resource as an image
Yeah, Alrighty then.
If you're not going to take the advice of people on comp.lang.java.*,
then I suggest you stop wasting your time and ours.
There are a lot of smart people here who take time out of there day to
help people. If all you want to do is come up with your own way, and
then blame the standard library when you encounter a bug, be my guest.
Just don't waste MY time doing it.
T
Twisted
Joe said:
That might have something to do with the tone and attitude expressed by
this "advice".
Well, that's good to know. Let's actually compare work shall we?
Method 1 involved: getting a couple of class files, editing one of them
to fix a simple bug, and compiling.
Method 2 would have involved: learning a chunk of new API and either
figuring out how to get Eclipse to tell an app where to find resources
when it's run in the development environment rather than from a final
packaging or building a jar for every edit-test-debug cycle.
Method 3 would have entailed all of the things mentioned in Method 2,
plus obtaining a new tool, learning how to use *that*, and possibly
additional things.
Advantage of method 1: simple and straightforward and quick. (It took
maybe half an hour.)
Advantages of methods 2 and 3: it sounds like they scale better once
you have lots of resources, and resources that shouldn't be hard-coded
into the binaries (such as localizable strings). Once those conditions
are met, the scaling and other issues of the first method outweigh the
additional complications and training involved in employing method 2 or
method 3.
A cost-benefit analysis clearly shows that I'm not wrong -- and neither
are you. Different conditions and circumstances warrant the choice of
different tools. On the other hand, anyone advocating a
one-size-fits-all approach that mandates always solving a certain class
of problem with one specific tool in the One True Way clearly *is*
wrong.
It seems a significant cause of the recent *ahem* controversy here has
been the unstated assumption many people have made that if someone
isn't doing it the same way they personally would, then that someone is
necessarily doing it wrong.
I find it curious that this "tried and true" method was not the first
relevant Google result for the topic, while the method you deride
*was*.
That's one I'll cross when I come to it, of course. Perhaps you forget
the old adage YAGNI -- "you ain't gonna need it". Overdesigning is a
frequent source of missed deadlines, bloated budgets, and yes, even
bugs.
The interesting thing is that people feel the need to "advise" me on
how to solve a problem I *already solved*, two days ago now.
Me, hostile? I've only reacted negatively to hostility expressed by
others.
If anyone wants to point me to a quick tutorial on managing external
resources that explains how exactly to make Eclipse hide any underlying
complications from you so that you can focus on doing *actual
programming*, I'll bookmark it for future reference. Anything that
involves an extra, manual build-Jar step on every edit-test-debug cycle
is, of course, right out.
Didn't you hear? They're De Rigeur(tm) when discussing certain things
(and certain *attitudes*) on the net.
Perhaps you didn't Get the Memo(tm).
T
Twisted
Larry said:
And another one manages to miss the mark by a country klick.
I'm not using *any* tool to jar up my project -- not yet, anyway. It's
still in early development. There's working runnable code, sure, but
nothing along the lines of installers, jars, or other
distribution-oriented work done yet! So anything that depends on the
existence of such a thing is going to break at this point.
The graphic would need to be located somewhere on, apparently, the
class path. Somewhere the app will find it when run in my development
environment, and simultaneously where Eclipse would know to copy it
into any jar I end up building. Perhaps there's some simple way to
configure an Eclipse project with a directory to hold external
resources for them to be treated this way automagically; if so, I
haven't run across it yet. I suppose I could google some more or browse
the documentation, now that I know there might be such a feature in
there somewhere.
One thing that I find a recurring problem in life generally, and in any
tech-related or net-involving thing particularly, is this sequence of
events:
1. There's something that would be useful to you, if you only knew it
even existed.
2. Eventually you need to accomplish a goal that this "something" could
be handy for, but not knowing about it you can only perform a general
search whose keywords stem from the goal you seek, invent a solution
yourself, or similarly.
3. The "something" does not crop up as a result of the search in event
2, nor does it get mentioned initially in response to queries you made
to actual human beings. (In this case, there *was* no initial response
to queries I made. Only after I'd gotten the darn thing working and
announced this fact did everyone and his brother pop out of the
woodwork to flame me for having done so without their advice!)
4. Of course, "everyone" suddenly pops up after the fact and mentions
the "something", often assuming a criticizing or hostile tone as if
it's somehow your fault that you didn't pop out of your mother's womb
already knowing about the "something" just in case, or somehow your
fault that Google couldn't find it, or somehow your fault that you
didn't know the magic keywords that would have found it (even though
there's no reason those keywords would have occurred to you given your
state of knowledge and goals at the time -- in this case, it sounds
like "jar" would have had to be a keyword, but I am nowhere near the
deployment stage where it would even occur to me to use a keyword
related to packaging and distribution, assuming it *ever* would when
the problem prompting me to perform a search is a "how do I make my
code do X?" rather than a "how do I distribute this thing in a
standalone package that any idiot can install?" type of question.)
I've seen this same syndrome time and again. The two separate
underlying causes seem to be:
1. Web sites and similar with the "preferred" solution seem to arise as
highly relevant search results only for fairly narrow queries that will
probably only be entered by someone who already knows about that
solution, but seeks to either refer someone else to it or brush up on
some specifics. Someone who knows the *problem* but not the specific
*solution* won't find it with a Google search, because the keywords
predominating on the Web page describe the solution more than they
describe the problem it solves. (The page should describe both.) Also,
the page may describe the solution and a specific problem it solves,
but it's a "preferred" solution to other problems that are not also
described on the page in question, and the page gets a poor search
ranking on queries related to these problems as a result.
2. People assume that if you don't know about the "preferred" solution
then you're an idiot and behave accordingly. Well, actually, they don't
behave accordingly -- even a genuine idiot should be treated with some
respect rather than flamed to kingdom come for such heinous acts as
*actually trying to solve a problem on their own after failing to get a
response to a request for assistance*, of all things.
I think number 1 is actually the bigger problem; if it were fixed, then
at least the only people nailed by number 2 would be the ones that
didn't so much as try one or two searches first. But as it stands, we
have a bigger problem. It may be a problem with the way Web sites are
written and SEO'd these days; but I'm guessing it's more a problem with
the search engines themselves. We need a next-generation search that's
smarter about finding relevant results for "how do I?" queries somehow.
I leave its implementation as an exercise for the reader.
O
Oliver Wong
Twisted said:
It doesn't happen to everyone who posts here, but it does seem to happen
to a lot of your posts, so maybe there's something about the style of your
writing that attracts these responses. For example, in one of your posts,
you wrote "I may have discovered another bug in the 1.6.0 release candidate
library implementation." which sounded a bit on the arrogant side to me.
You also seem to think this newsgroup is a lot more social than I think
it is. You've told two stories about how your browser has misbehaved,
perhaps thinking it exposes your human side, allowing us to relate and
establish some camaderie, but in my mind, I figure most people are waiting
for you to get to the point, so they can answer your Java question. I didn't
say anything (until now) 'cause it really wasn't my place to do so, and
because maybe you're right and I'm wrong (about the socialness of this
group).
I mention it now to advise you to not takes things too personally.
People are posting answers here, not only for you, but for future readers
who, perhaps months from now, will have the same problem you're having, and
will search the google archives for an answer and find this post. It's great
that you got an answer that works for you, but the people here want to make
sure that the future readers will understand that there's a conventional,
"standard" solution for this problem, and that it's better than your
solution for certain situations.
Of course, these people, being human, have some emotional attachment to
their solutions. They downplay the reasons why your solution might be better
than theirs. IMHO, if you're happy with your solution, stick with it. If
later on, you start having problems with your solution, come back and
re-read this thread, and see if the alternatives proposed here address some
of those problems.
I think all the benefits of using the classloader to load the image have
been said. Any future person reading this thread will be able to make an
informed decision. In Twisted's particular case, (s)he prefers hardcoding
the image. You might think that's a really dumb choice, but hey: people are
free to make dumb choices if they want to, right?
- Oliver
J
Joe Attardi
You insist on continuing to exaggerate the method we're suggesting.
You don't have to tell the app where to find resources. You simply put
it in the classpath. Whether that's inside a JAR file when you deploy,
or simply inside your class directories, i.e. classes/.
Straightforward and quick? As an earlier poster pointed out, this is
the procedure you've told us you are following:
Step 1, convert image to XPM,
Step 2, run some tool to convert it to a class file.
Step 3, move the class file into the correct place.
Step 4, use some uncommon third party tool to load and convert the
class's data..
Step 5, Fix the third party tool, because it was broken.
Step 6, Fix the third party tool again, because it was broken in
another way.
How is this simple and straightforward?
Because we all know the Google ranking algorithms can determine best
practices for software development.
None of which are an issue with the very simple approach advocated by
myself and others in this thread.
Again you are exaggerating the process we are recommending here.
Eclipse has nothing to do with it. And using the classloader to load
resources such as images is *actual programming*, I'd be curious to see
why you don't see it that way. You don't have to build a JAR file every
edit-test-debug cycle, as we have said several times now. It just needs
to be in your classpath.
No, not really.
I'm trying to understand here. You have no problem hacking some third
party class, and transforming a simple icon image to a weird format,
but you don't feel like using something that's built in to the JVM
(classloader) for this very purpose? You are trying to re-invent the
wheel. External resources like strings, images, etc. can be loaded by
the classloader so that you don't have to worry about where it's
installed or how it's deployed, which I believe was your original
problem.
P
PofN
Many words to cover up that you have no fucking clue.
D
Daniel Dyer
It should take less than a second to create a JAR file, unless you have
hundreds of classes in it or a very slow machine. It should also be
trivial to make it part of the automated build process even if you are not
using Ant.
One advantage of building the JAR every time is that you will be testing
the build that you will eventually deploy, rather than running from a
classes directory that won't be deployed. With a JAR file you don't have
to worry about setting a classpath to run your program and both the main
class and any dependent JAR files can be specified in the manifest.
The problem I see with your approach is there is a lot more work if you
want to change the image. This might not be a problem right now but is
something to keep in mind.
Dan.
T
Twisted
Daniel said:
For a query of "java resource loading", not "java icon loading" which
is one of the ones I used, and other similar ones.
It is not exactly fair to fault me for not using the exact query you
just used. Also, there's the factor that you know exactly what answer
you're looking for, so a) when you tried one related query and didn't
get it, you tried more queries and posted one that produced the planned
conclusion, and b) you recognized the significance of
"ClassLoader.getResource" when you saw it in excerpts by search hits,
whereas I went by the text in the excerpts in deciding what looked like
a promising result.
This supports my conclusion that one frequent cause of problems is that
search engines work mainly when you already know, in detail, exactly
what you're looking for. It's easy to find Porsches with it; hard to
find a car recommendation for a given requirement and budget. Easy to
find ClassLoader.getResource, hard to find "how to incorporate
application icons portably in Java". Etc.
Search engines then end up good for finding references for stuff you
already know, or detailed information on something you vaguely remember
but already had encountered; much harder for answering questions where
you don't already have a good idea of (at least part of) the answer. In
fact, there seem to be three levels of difficulty:
* Digging up references to something you already know, or the
faq/manual/whatever for something you already use: easy. Some questions
you're unsure of too -- was xyz play by Shakespeare? What else did he
write? Where are certain places, cities and such? Who first said
<quotation>? If you have an exact name for something, and it's THE name
rather than one of many choices, it's definitely easier.
* More difficult: answering questions you can state in plain English,
but for which pretty much every key word has many synonyms and the
proper names involved (in our example, just Java) are not sufficient to
narrow things down much ("Java" by itself still leaves a huge body of
subject matter). This can especially be the case if you have a specific
problem to solve and phrase your query in its terms, and the ideal #1
search result solves a general class of similar problems in more
general terms, resulting in a much shoddier result ranking. In my case,
the answer you think I should have gotten probably was ranked
#3,000,000 or so. Even if it was ranked #3, the text excerpt mustn't
have seemed as relevant as for one of the other top ten. And of course
if there are two solutions of which one is (arguably) superior, it's
still the one that someone finds *first* that gets implemented, as a
rule.
* Most difficult: anything whose "query" isn't even translatable into
words. The ones that seem to come up the most are "put a name to this
place/face" and "find pictures like this". The latter has come some
distance in recent times, thanks to large image databases at Google and
elsewhere; *if* you can describe what you're looking for in words and
*if* a picture has been put on the web somewhere with those same words
in close proximity, you stand a chance. Finding more pictures of
something you can hang an unambiguous proper name (rather than a
description) on works best, which often reduces to the first of the two
items I mentioned: putting a name to something you've seen that was
not, however, conveniently labeled with it.
Now search engine technology is one of my interests, so I've even
recently put these last cases to a test of sorts, or recent search
engines to a test on them, mainly Google Image Search. I had some
photographs of unidentified skyscrapers and architecture, and also some
of celebrities, for some of which I had good guesses and for others of
which I didn't. The former, when the guess was accurate, were fairly
easy to confirm; the latter proved well-nigh impossible. For the
former, the guess would turn into a query and a search; if the image or
one very like it cropped up in the results it was likely the guess was
correct, and more so if there were multiple hits on that same image.
For the latter, random stab guessing sometimes worked. I found that it
was easier to nail down architecture in that case -- queries for
"famous skyscraper" and similar turned up a hit within a page or two
for many, and the link led to an identification that could be confirmed
from a couple other sources easily thereafter. Celebrities on the other
hand appear to be a dime a dozen, whatever salaries they command from
Hollywood and elsewhere. It's even worse than that -- rather than a
query analogous to "famous skyscraper" (say "blonde actress") turning
up thousands of hits with the first occurrence of a particular one
hundreds of hits down from the top, such queries actually turn up a
fairly limited selection that can miss some entirely, because where the
images occur they are described in more specific terms, usually with a
proper name. In fact, to ID unknown celebrities it is more useful to
put a description in a text search, and generate guesses that way, then
plug those into an image search.
Of course, I've heard that face recognition is coming soon to a search
engine near you, although eventually we need tools that can more
generally parse images to generate some keywords (for example, by
reducing an image to a 16-color VGA palette and pixel-counting you can
compute reasonable weightings against keywords like "red", "green",
"dark", and so forth; not that any of the major image search engines
appear to do even that much). And, of course, until then putting a
paragraph-length description next to every image on the internet would
help tremendously -- not only for search engines, but in providing an
alternative for visually impaired humans in the form of a description
they can try to visualize, much the way novels without illustrations
have to present their characters and settings. And of course, this is
getting off-topic...
Search difficulty category number two is what is of more concern right
here and now, namely, being able to find a general result from a
more-specific query, and being able to find something you can describe
but can't name (which would go a long way towards helping in area #3,
too, for that matter). Google has some features that help here, for
instance in that it seems to conflate variant spellings and detect
possible typos. Build in a thesaurus and grammar awareness and you
might be getting somewhere -- for example, homographs such as "lead"
(the heavy toxic metal) and "lead" (as in the blind leading the blind)
can be distinguished by their part of speech (one is a noun and one is
a verb in this example), and synonyms can be fuzzy-matched (so that for
a query of "red" the word "red" gets a strong hit, but "maroon" or
"mauve" counts for something rather than nothing; "automobile" and
"car" may be treated almost identically, with fractional preference
being given to hits that use the exact word that's in the query instead
of the other one).
It looked like a developer network article rather than a joe random
forum posting to me. Also, considering that *it bloody worked* (with a
little tweaking) it doesn't seem to have been "unreliable" by most sane
definitions of the term.
I'm sure that when it comes time to distribute something, creating jar
files won't prove too difficult. But I'm leery of creating something
some of whose functionality is dependent on being in a deployment
rather than a development environment. Understandably so! Having to
bundle, install, test, debug, edit rather than just test, debug, edit
would slow down the testing/tweaking/improvement cycle drastically. And
would it even be possible to run it from a jar yet attach a debugger?
If not, then there could be functionality and code paths that could
only run without the debugger attached, making the debugging of those
code paths a history refresher on Victorian software development
methodologies. Not exactly what I am looking for in the way of
continuing education right now.
Somebody obviously hasn't been reading this thread. Which is fine,
except that the same somebody nonetheless posted an opinion into the
thread in question, and a strong one at that.
In the first few posts it becomes apparent that I made some Google
searches that turned up nothing that *looked* relevant (to someone who
didn't already know what they were looking for, anyway -- and those are
the someones good search results are most needed by), then posted here,
then after a while passed without responses tried some more Google
searches and eventually got a hit that led to a method *that worked*.
In other words, I ended up solving my problem with Google, contrary to
what you suggest, and the suggestion that I solved it "wrong" is
therefore a suggestion that I shouldn't have used Google, given what
the result was when I did, and that that result is supposedly "wrong"
(despite having actually worked).
As for "books written on the subject", that is an option for someone
with a higher budget than I. Keep your recommendations and
(revenue-generating, no doubt) Amazon links to yourself, please. And
don't you *dare* suggest that "if you can't afford xyz, you shouldn't
touch any development tool with a ten foot pole", lest I call you a
filthy capitalist pig that discriminates against the poor and supports
raising the barrier to entry to entrepreneurial activities to protect
an incumbent CEO class from any risk of ever facing something
resembling actual competition, then launch into a lengthy political
diatribe. (DISCLAIMER: I am not a communist. I just oppose fiscal
policies that seem designed to raise artificial barriers in the face of
the lower classes to keep them from ever climbing up and threatening to
unseat the incumbents. In other words, I am better described as
capitalist but anti-fascist and somewhat libertarian-leaning.)
Even ones that are documented either a) nowhere or at least b) nowhere
you can find them if you don't already know them? Curious.
All the complication in question is up-front, at development time. Once
solved, it stays solved, and there's no runtime complication involving
I/O that can fail. If the binaries loaded, it will work. If they
didn't, then there are bigger problems anyway.
What directory? How do I make it work seamlessly whether it's in the
development environment or the deployment one? None of that has yet
been explained to my satisfaction; all I've seen are vague assurances
that this can be done, without any detail.
This directory is apparently to be on the class path, which suggests
one of two consequences. Either every project winds up adding another
dir to the class path, or all the files from every project end up in a
single dir jumbled together (and then when one project is packaged, you
risk including extra files that waste disk space or, in trying to avoid
that, accidentally omitting a file that is actually needed).
I didn't say I wouldn't. I did say I wouldn't follow it *blindly*, and
certainly that I won't follow "advice" that consists of vague
suggestions lacking detail in crucial areas. "Get and use tool X"
without any real detail (not so much as the URL where the tool's
official Web page resides, assuming it even has one) and "Do this"
suggestions that leave a lot of questions that, when asked, go
unanswered except with flamage, do not exactly encourage me to be
trusting.
I still haven't heard anyone tell me any of the following, which is
behavior that I find suspicious:
* From those who recommended getting Ant, its official URL at minimum.
* Regarding getResource, the exact way to have the resource found when
the app is tested in the development environment *without* either
jumbling every project together *or* overloading the system class path
with a sub directory for every project.
* Regarding getResource, the exact way to have that same resource
automatically included into a jar when one is built, when the time
comes. One person suggested that Eclipse can be made to do this,
without saying anything in detail about how. Others suggested Ant would
be needed, without saying anything in detail about how to do it with
Ant.
Unfortunately, I have no confidence that I can answer those questions
to your satisfaction purely by my own research and wits. I am somewhat
more confident that I can answer them to *my* satisfaction that way,
mind you; but the events of this thread make it clear that even if I
do, the method I come up with via my own research efforts might
nonetheless be decried as "wrong" and lambasted with what seems to be
almost *religious* fervor...
My suggestion to you is that if you want me to answer those questions
to your satisfaction (rather than just to mine) then you should give me
the answers you want me to end up coming up with. Or is this your
standard MO -- tell someone nothing until they try to solve the problem
themselves, and then criticise them like crazy for all of the
(perceived) shortcomings of their solution?
T
Twisted
Oliver said:
Well, let's see ... what do I do differently?
Oh yeah, of course. When I ask a question I'm asking a question rather
than engaging in some kind of social ritual. What I expect is an answer
rather than a question or riddle of some kind. Also, when challenged by
the alpha male I tell them to go shove it or simply ignore them rather
than bow down in submission and make all of the right noises, because
as I said, I didn't come here to engage in some kind of social ritual.
I'm not actually challenging you for dominance; I consider dominance in
whatever little hierarchy you have here to be completely irrelevant to
my goals, and you're welcome to keep it as long as you don't insist on
involving me in submission rituals of some kind or another just to keep
your ego well-fed. I am simply looking for the answer to a question.
And oh, yes, that means that when what I get is not in the form of an
answer, I pointedly remind people that this is not Jeopardy! and you
most emphatically do not have to phrase your response in the form of a
question.
Any questions?
"I have discovered a bug" might be; "I may have" certainly is not, and
shouldn't be considered even to be particularly contentious considering
that it *is* beta software we're talking about.
Curious -- it's you people that want me, the newbie, to bow down
submissively and act all meek and awed around your alpha males and
never, ever, question them, and generally to answer any question put to
me while you reserve the right to ignore mine; I'm the one treating
this as a medium of information exchange rather than yet another venue
in which to vie for the Testosterone Junkie of the Month Award(tm).
Misbehavior triggered by encountering a Java applet, while researching
a Java-related issue. Hardly offtopic. Far less so than, say, personal
criticisms directed against particular posters in this newsgroup would
be, hm?
Someone is actually man enough to admit that they may be wrong? Wow.
Maybe I misjudged ... some of you.
Suggestions that implicitly question my competence notwithstanding, I
presume?
Another surprise -- you said "for certain situations"! OK, you
definitely scored some points on that one. OTOH, I'm still awaiting
some details regarding this "standard" solution, in the form either of
the details themselves or a (safe) URL (preferably a *.sun.com URL,
which obviously would carry extra credibility).
As, I suppose, might I -- having found something and even fixed a bug
in it myself is definitely more of an accomplishment than having
followed a rote, canned routine...
I'm aware of its limitations -- both in scaling, and in cases where
there are direct advantages to separating a resource from the core
binaries. Those limitations might apply to some stuff in the future, at
which time I might as well move the icon (which would be easy) to the
same place as this hypothetical other stuff. Until then, YAGNI appears
to apply. Also, of course, I'm still missing the information that
people seem to assume I either have or could easily find. Information I
might add that they apparently assumed I could easily find once before,
an assumption that proved to be wrong once before. I've no guarantee
that plugging in "getResource" and following the first plausible
instructions I see won't *also* result in disapproval stemming from
further decision branches. Researching it myself led to a disapproved
result once, so obviously it's plausible that it may do so again.
[Snip remaining paragraph, which seems to slide a bit and suggest,
without coming out and stating, a possible insult.]
T
Thomas Kellerer
Twisted wrote on 21.11.2006 15:27:
NetBeans is an IDE just like Eclipse...
NetBeans is an IDE just like Eclipse...
T
Twisted
Joe said:
Actually, it is you who are underestimating what is involved. You are
to be forgiven of course -- if this is a method you are intimately
familiar with, it will come easily and naturally; the research and
suchlike that I mention is a one-time cost and in your case it's a sunk
cost, probably years ago. So you probably underestimate that cost's
effect in influencing my decisions, since it no longer has any
influence on yours.
This has been mentioned time and again, but it leads to the obvious
issue that either multiple projects clutter the one directory with
their resources, or each project needs its own, and each directory
needs to be added to the class path on the development system. I can
easily see that hitting limits, especially on Windows systems which
have positively archaic limits on path lengths, when many projects have
been/are being developed on one computer.
That contention has yet to be addressed by anyone with any suggestions,
corrected misconceptions, or whatnot. The impression I have is that
each project needs its own resource directory, added to the class path
on the development system, and manually packaged as an extra step at
distribution time, absent additional investment in tools and learning.
It involved coding, which I know, exporting from photoshop, which I
know, and not fiddling with additional, formerly unfamiliar build tools
or anything of that nature.
Determine, no; discover, yes. Supposedly. I mean if I can't find a
"standard" answer with Google, then what am I expected to do? Post
every decision and its alternatives here and wait (perhaps hours or
even days) for you guys to tell me the "correct" answer? And if there's
more than one, and they differ, then what?
Adding additional I/O work and dependencies on external files to the
startup is a "very simple approach"? By what measurement of "simple"?
Changing the icon to be done your way is equivalent to externalizing
some strings, say for localizability. It adds complexity and potential
points of failure (what does the app do for recovery if, at runtime, it
can't find the strings? this failure can't happen for literals but can
for externalized strings), and requires additional tools and knowledge
of the coder versus including them literally. Without a corresponding
benefit (e.g. localizability) why bother?
That part is; figuring out the additional tool and path management
stuff involved, however, isn't.
That alternative, as I'm sure I mentioned at least once before, appears
to lead to either of two results: classpath bloat or a jumble of
resources for multiple projects in one directory. Neither seems
desirable to me.
It's too bad there seem to be unanswered questions and apparent
problems with this approach, to wit, the above jumble/bloat alternative.
T
Twisted
PofN said:
One word to cover up you:
PLONK!
T
Twisted
Daniel said:
That sounds like fun. Every time I edit the code and Eclipse recompiles
it for me, the jar is rebuilt and the icon I'd inserted into it
disappears, and I need to reinsert it before the next test run? Unless
of course there's some way to tell it to keep the icon. I'd still be
leery of its only home being in the jar; properly, files like that are
part of the source code too and should be housed with it and just
*copied* into the jar. Preferably automatically. Now maybe this can be
done, but if so, nobody has bothered to tell me so, or suggest how.
I changed it several times, tweaking it, without difficulty last night
-- it's a matter of re-exporting the image, then pasting in a different
string array literal, and that's all. Now just re-exporting the image
(to some classpath directory) would shave a little off that, but in
return I now have to:
* Find out how to make it get included in the jar automatically;
* Find out how to make it build the jar for every test automatically;
* Have the application do I/O and error recovery on startup, which it
didn't previously have to do;
* Now that it can die at startup with a file not found or whatever
error, make it gracefully report the problem when it does so, and
suggest fixes;
* Worry about end-users' inevitably encountering said problem and
having no clue anyway how to find the file and put it where it needs to
be or otherwise fix whatever went wrong -- likely, their recourse will
have to be to reinstall the app. Yuck! I'll be looking an awful lot
like Microsoft then -- my stuff stops working and has to be reinstalled
and such!