Re: @tekHedd - I haven't downvoted a post in a long time...
Actually, unhandled exceptions seem to be the problem here. The stack trace in this case might be the only means of this user to get support from Cisco TAC in resolving the issue.
This case in my opinion is that :
1) The sysadmin has a point but doesn't know what his point is and therefore is not well suited for problem solving. He's the type that simply asks the wrong question due to lack of knowledge. Instead of learning more about what stack traces are and finding the right thing to complain about, he's simply picking the first thing he doesn't understand and focusing his hate at Java unfairly
2) Cisco as always has done a shit job on writing code. I can see a mom and pop operation or open source project dumping a stack trace without an exception handler. But Cisco should have enough developer resources to not only implement program flow, but also implement error management even if it's just a top level exception handler for 'Unknown exception'.
3) Cisco ACS is an old product that only receives update begrudgingly. It was written during the dark era of Cisco which means their products were meant to be used but never seen by anyone. Cisco has a long an glorious history of absolutely disgusting user interfaces. They're getting a little better.
4) This won't be a big problem in the future. Cisco has more or less moved to Python. Cisco does programming languages like a flake does religions. Java used to be king... now Python. The marketing and management at Cisco know even less about what an API is than Oracle's lawyers. Believe it or not, all new Cisco courses this past year have at least one slide making a huge deal about what a northbound and a southbound API is. They also all seem to try and fit a plug on programming Python in. So... without exception, Cisco HAS NEVER made a single point as to why someone would need an API, but instead makes a huge point out of making incredibly bad scripts that do absolutely nothing in a programming language that is not particularly well suited for calling the APIs as opposed to implementing them. You should see the shitload of new information on "YANG" which must be the most insanely lazy and somewhat sloppy approach to API development in history.
Java is a perfectly ok language... it's not particularly good as a runtime environment anymore. JVM could use a massive update and Google did a little with that in Dalvik. Sadly, there are no good and modern extensions to Java regarding things like assisted auto-vectorization... or things like OpenMP style multithreading assistance. Their libraries are impressively bad for things like threading in general. There are far too many conflicting models in Java for multitasking programming. Due to REALLY REALLY bad GUI support in Java, there's no decent runtime for handling calls to the UI thread. Microsoft "solved this" in C# by building a serialized delegate mechanism which doesn't suck... too badly. Even better was the Task<> structures attached to the language async mechanisms. Java has sort of died in this place. There are solutions, but you can't find which one to use or how to intermix them when needed.
After this case, Google should probably make a replacement for Java which operates on the Java class libraries but fork them substantially enough that they can extend and improve the language as much as possible
Biting the hand that feeds IT
