N
Navneet Mathpal
HTTP Status 500 - Handler processing failed; nested exception is java.lang.NoClassDefFoundError: org/apache/commons/lang/ArrayUtils
L
Lew
R
Roedy Green
My condolences. This is my least favourite error message.
see
http://mindprod.com/jgloss/runerrormessages.html#NOCLASSDEFFOUNDERROR
A
Arne Vajhøj
Apache Commons Lang jar file is missing in lib !?!?
Arne
R
Roedy Green
The problem is there are so many different things you can do wrong
that generate the error.
I would hope Oracle could find some way to subclass
NoClassDefFoundError the way IOException is, to give you a better hint
on just what you screwed up, or perhaps to include more hints in the
message.
Tracking down NoClassDefFoundError is one of the most onerous errors.
J
Joerg Meier
Jarfinder is helpful in these scenarios, although unless you are stuck in
the dark ages I recommend searching the Maven repository for the classname
before anything else.
Liebe Gruesse,
Joerg
J
Jukka Lahtinen
Roedy Green said:
I don't think it's so easy to subclass it.
After all, when the compiler or jre doesn't find a class, it probably
has no way to know WHERE the class really is (if anywhere) or WHY it
isn't anywhere that it looks for classes. It only knows where it DIDN'T
find the missing classes.
Probably about the only thing it could do is tell all the places where
it looked for, and didn't find, the missing class definition.
J
Joerg Meier
I looked at Maven once. As soon as it started 'updating' itself I shut
it down, un-installed it and never went near that abomination again
Well, that is explicitly what Maven is for, so I must say, as much as there
are valid reasons to be unhappy with Maven, in this case the fault lies
with you. It's like uninstalling an Email program because it connected to
the Internet. One of, if not THE top feature of Maven is that it
automatically resolves dependencies and updates jars from the Internet.
Liebe Gruesse,
Joerg
R
Roedy Green
Perhaps it would be within reason to:
1. scan all jars on the current computer
2. consult a database somewhere of what popular jars contain.
And hand that info to you with the error message.
It is such a PITA, I think it deserves unusual effort.
Perhaps a separate utility.
J
Joerg Meier
Absolutely not. There is no telling what file systems might be mounted and
what kind of volume such a scan could trigger, and there are a thousand
ways that could go wrong, from different versions of the same file to
malicious jars that only need to be dropped on someones HDD to be executed
like that.
That's pretty much the way Maven goes.
Liebe Gruesse,
Joerg
G
Gene Wirchenko
I was going to answer, but you did an excellent job.
I hate it when I have to clean up a mess because of something
that a "helpful" program did.
[snip]
Sincerely,
Gene Wirchenko
J
Joerg Meier
If it used Maven, then it would at this point have downloaded everything
you needed. Of course, it would have downloaded it from the internet, which
you seem to find objectionable for some reason, yet here you are, looking
for a way to download these files in painstaking manual steps from the very
same internet.
Apologies, it is findjar.com, not jarfinder.com. I haven't used it ever
since I left Ant behind so my memory was a bit hazy.
I'm honestly surprised that you are stumped by what even a cursory
knowledge of Java should have made trivial - simply remove the missing jars
from the class path, compile, and you will get the names and package names
of classes that are missing.
I agree. Luckily, the rest of the development world agreed that dependency
management was a pain, and came up with a solution:
<http://maven.apache.org/>
Sorry for the cheek, but you do seem to be primarily complaining that
nobody has invented Maven yet ;-)
Liebe Gruesse,
Joerg
J
Joerg Meier
As Leif already said, this is obviously not a good solution, but even in
this case, where Maven indeed wouldn't have been able to FIX the problem
for you, you still would have benefited from a pom.xml, because it has a
proper and well specified way of describing dependencies - you would, at a
single glance have known: the name of the jar, the name of the package
(which should be easily googleable), and the fact that it was something you
had to install yourself manually.
Like I said, Maven would at the very least have given you all the
neccessary information needed to find the missing jars to compile.
There is a distinct difference between learning and doing. It is of course
entirely reasonable to want to learn how to compile things in Java, and
naturally, no sane person would recommend to learn that by using Maven.
No, of course not. I wasn't born with Maven knowledge implanted into my
brain, then unable to learn anything else. In fact, as you can tell from my
earlier explanation, I was easily able to tell you how to solve a problem
you had without using Maven, thanks to my understanding of the Java build
process.
That is an unfair and disgenuine argument. Nobody is suggesting people
don't LEARN how things work. You asked how to get something to work, not
how to learn about how the Java build process works. Going by your answer,
I would suggest you abandon Java completely, and instead focus on learning
Assembler, which of course you should only ever write using Notepad.
After all, you would only want to use the bare minimum of tools, and not
have fancy things like garbage collection and abstraction, right ? How much
time you would save, by not learning the latest greatest language, only for
it to be superseded a few years later ?
Understanding how things work at their core is a useful skill that should
certainly be part of any decent education, whether in class or as an
autodidact. On the other hand, suggesting to stick to the lower and most
primitive solution while actually working is ridiculous and held only by
the most ancient and inflexible dinosaurs.
Hopefully, you didn't really mean to suggest that it's actually better to
use Notepad instead of Eclipse, a command line to compile and a hand
written batch file to package instead of Ant/Maven and whatever other way
to do things manually you can think of while doing actual work. As much as
these things should be part of learning, they shouldn't be part of
producing.
Liebe Gruesse,
Joerg
J
Joerg Meier
Every few years, someone links this, and every time, I read it again to my
great delight. As my life progresses, it's interesting for me to note how
my view of Mel changed over the years - from uncompromising and unreflected
hero worship when I was still young and a cowboy, to "I hope I never have
to fix code like that" when I started working on multi-person projects for
the first time, to "I hope I never have a coworker like that", ending with
"I hope I never have an employee like that".
Mel is, at once, the best and the worst aspects of a clever programmer.
Liebe Gruesse,
Joerg
S
Simon Lewis
Joerg Meier said:
Very well said. Also ties in with the sorts who claim "IDEs are rubbish"
and stick with vim or emacs. Vim or Emacs with a huge & complex & rich class
set would be like trying to build a house using grains of sand instead
of bricks. Yes they're great tools but the ease of use and built in vcs
management, debugger, class browsing, javadoc fetching etc simply
"eclipse" (if you'll excuse the pun) anything that Emacs and CEDET (for
example) could manage. Yes they have their places. As the key tool in
developing from complex object orientated code bases not.
S
Simon Lewis
Joerg Meier said:
Does he also say only losers need a debugger? That's another cracker
based on something Kernighan said 50 years ago when a large program was
about 32 lines long....
J
Joerg Meier
Then I missunderstood you. When you wrote
I thought that meant you had trouble getting the Java DBus bindings to
compile, because you couldn't find the required jars. In fairness, if you
were in fact trying to convey that this is a problem you were intending or
already did solve yourself, and were only sharing as some sort of
LiveJournal entry, I would argue that the blame for this misunderstanding
lies with you.
It must be a cultural thing, but it explains why I was confused by so many
of your past postings. Personally, I am here to educate both myself and
others, and to further our collective understanding of Java and programming
in general. I thought that was the implicit goal and intend of all posters
here, and the fact that you not only see it that way, but consider that
goal to be some sort of personal insult certainly explains a lot.
With that, then, I really have not much more to say - our views of what
this newsgroup is for seem to be fundamentally opposed. Maybe it's best to
avoid each other in the future.
Liebe Gruesse,
Joerg
E
Eric Sosman
Mel wrought his wonders when the economics of computing were
quite the opposite of those that prevail today. CPU's were slow,
so CPU cycles were in short supply and therefore expensive. Memories
were small, and also expensive (I toured a factory once and saw core
memory being assembled by hand, one ferrite doughnut at a time).
Programmers, on the other hand were cheap and plentiful, "plentiful"
in the sense that a small number of programmers could produce enough
code to keep the small, slow machines running at full capacity; more
programmers would only have increased the backlogs.
Today it's the other way around. CPU cycles are so plentiful and
cheap that we routinely waste them on things like screen "savers."
Memories are so big that we cheerfully spend sixteen bytes or more
on a `Double' in preference to an eight-byte `double'. And as the
demand for programmers' output has grown, the programmers themselves
have become expensive. The foot is in the other shoe: Instead of
spending programmer time lavishly to rewrite a program for a new
machine, we strain every nerve to amortize development effort over
multiple hardware generations. Damn the inefficiencies, full
speed ahead!
Mel wrote clever code because that's the only code that would
work: The program had to fit in the tiny memory, and it had to finish
before the sponsor's CPU funds ran out. Today, you and I use words
like "asymptotically" and studiously avoid being clever. Guess what?
The fact that we *are* right doesn't mean Mel *was* wrong; the fact
that he *was* right doesn't mean we *are* wrong. We work in radically
different circumstances; it's not too much of a stretch to say we work
in radically different industries.
The interesting question, I think, is What Happens Tomorrow?
Will quantum computers or thought-directed computing or positronic
brains change things as fundamentally as they have changed since
Mel? Will the Best Practices we promote today be dismissed as just
so much primitive bunkum? Naturally, I don't know -- but I wouldn't
bet against it ...
E
Eric Sosman
(Topic drift severe enough to be called "topic lurch"):
Hadn't thought of that, specifically, but you may be right
about energy expenditure changing the whole face of computing.
Years ago I read an article (in Scientific American, maybe?)
about thermodynamically efficient computers, in which the authors
maintained that such computers would have to be reversible: Apply
a positive bias voltage to the components and the computation runs
forward, apply a negative bias and it runs backward.
(The article presupposed that information-theoretic "entropy"
a la Shannon was equivalent to the thermodynamic "entropy" of Carnot
et al. I wasn't the least bit sure of the equivalence, but later
read a transcript of an address by Richard Feynman in which he
seemed to take it as axiomatic. Feynman's Nobel Prize collection
is larger than my own, so I'm inclined to take his word for it.)
Anyhow, if efficient computation has to be reversible, what
can we deduce about an efficient programming language? One
immediate consequence: NO ASSIGNMENT OPERATOR, because such an
operation wipes out the former contents of the target and is
thus not reversible. Start thinking about programming entirely
with exchange operators, and today's Best Practices start to
look somewhat beside the point ...