java program fails when instantiating a class but no stack trace or other information present on console

A java program I've written is failing when a class is instantiated in some environments.   I suspect it is a memory problem but would like to confirm this with some kind of stack trace.  I've tried putting a try catch block around the statement where the class is instantiated but I still see nothing (the module just stops running).   Is there some way I can force some error message or stack trace in this situation?  This is running in a windows environment.   When run from the command line, it just returns to the command line.   There is no other information.  There is nothing in system.out after the statement that tries to instantiate the class.
efamilantAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

krakatoaCommented:
Do you want to post the code where this happens, so that we can see it?

If there are no exceptions or runtime errors as you say, then how do you know it has not run and executed?
0
efamilantAuthor Commented:
Several reasons:

1.  The program does not produce the expected output
2.  Debugging statements that follow the class instantiation do not appear in the console
3.  log4j logging ceases right before the statement causing the problem.
0
krakatoaCommented:
I would say that without the code it's unlikely anyone can really help much.

You say that it fails when running in certain environments, then say that it is under Windows.  This apparent contradiction, and no code, is not going to attract many comments - apart from ones like this.
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

mrcoffee365Commented:
krakatoa is right -- it's hard to help when you don't post any code or error messages.

However -- to print a stack trace from a running java program in a terminal window in Windows, you do this:
<ctrl><break>
0
efamilantAuthor Commented:
I've solved the problem. As stated, an inspection of the code would have been a waste of time. I was hoping someone would have pointed me to a page like this, oracle.com/technetwork/java/javase/clopts-139448.html. But in my situation, even this did not work. Instead, it turns out that I was missing a couple of jar files and I guess, that in some situations, it results in the jre simply existing the program prematurely without any error messages or stack traces
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
krakatoaCommented:
. . . which is why I said this :

then how do you know it has not run and executed?
0
mrcoffee365Commented:
efamilant: should you ask another question where you want help, it is much more successful to respond to the experts who are trying to help you.  Without feedback, it's very hard for us to guess what you are seeing.
0
mccarlIT Business Systems Analyst / Software DeveloperCommented:
As stated, an inspection of the code would have been a waste of time
As stated? Where did you state this?

I guess, that in some situations, it results in the jre simply existing the program prematurely without any error messages or stack traces
No, unless you have stumbled across some fairly hidden bug in the JRE then I highly doubt this. A much more likely situation is that either some part of yor code, or some third party library that you are using, is what is responsible for exiting with no feedback, or is swallowing any feedback that may have been provided. Personally, that is something that I would look into more deeply if I were in the same situation, because it may rear itself again at a later time in a different place, and this would make debugging quite difficult. This is where providing the code (or at least some of the code) could of allowed us to provide more help, and possibly pinpointed the actual problem.
0
efamilantAuthor Commented:
It is the answer
0
krakatoaCommented:
Bad.
0
efamilantAuthor Commented:
I respectfully disagree.   Code inspection would not have helped in this case.   Here is why.  When Java instantiates a class, it finds all the jars that are needed to create that class and uses them during the instantiation.   What I learned from this problem is that if some of those jars are not present, then the entire program can simply abend.    How could you have known this by simple code inspection?    All you would have seen was the instantiation of a class:
    Myclass myclass = new Myclass(paramenter1, parameter2);

This tells you nothing.   The class itself uses jars which when present in the running environment allows the class to be instantiated.   It is a fallacy, I believe, that every programming problem can be addressed by code inspection.   Some of the most pernicious problems I've encountered recently are environment issues.   Issues related to the computer environment outside the code module itself (missing jar issues or memory issues).  That is my point.
0
krakatoaCommented:
Well, I suppose some possibility like that might exist; but mccarl especially is unlikely to have made the comment he did just in passing as they say. Only his return will tell if he is convinced of your argument. I can't say I am convinced, since any programme consists of references, and if those references are broken, then you would or should be able to see that from inspecting the code.
0
efamilantAuthor Commented:
Here is how it happens.   The jar is built in an ide like Eclipse where the path in the development environment points to a set of jars that are used by the module.    Then only some of the jars make it to some other environment (say a production environment).   In the ide there are no hanging references because the missing jars are present in the development environment.  But are missing in the other environment, causing the error at runtime.   What I learned was putting a run time try catch clause around the code that instantiates the class, does not result in java throwing an error (at least in this case).   Instead, the module simply stops working at the point where the class is instantiated.
0
mrcoffee365Commented:
You're right except for the "just stop working" part.  What happens is that the java process throws an exception.  However, it is from the classloader, which is why a try/catch around the attempt to create a new object will not catch the exception.

If you had worked with us on this, we would have started pointing you to the logs from the process -- at the very least, the stderr log from your process.  You would have seen the classnotfound (or whatever it was ) exception there.
0
efamilantAuthor Commented:
I was running this from the console.   You are saying that stderr does not throw its messages to the console but somewhere else?
0
mrcoffee365Commented:
ClassNotFound and other classloader exceptions are thrown and jetty should not be hiding them.  So I assume jetty puts them somewhere.  Maybe not -- check your jetty configuration.
0
mrcoffee365Commented:
Sorry -- you're not the one using jetty.  The console should have shown the errors.

However, lots of things can redirect output.  Are you using log4j for your logging?  It's possible that exceptions are being captured and written to a log rather than showing in the console.
0
efamilantAuthor Commented:
I am using log4j but the errors did not appear there, unfortunately.
0
mrcoffee365Commented:
Right -- your log4j properties file would have had to redirect stderr somewhere else in order for them not to come to the console.  If you looked in all your log4j files and didn't find the exception, then probably that didn't happen.

It's hard to debug this remotely, but the main facts are that exceptions are thrown, and unless something odd is done, they are displayed back to the user.  This happens even if (especially if) it's a runtime-only exception, as it seems yours was.

If the classnotfound (or whatever the classloader exception) exception is in a 3rd party jar, then possibly the log from that jar is being swallowed somewhere.  Bad application design, but people often don't think about errors which can happen in the multitude of user execution environments.
0
krakatoaCommented:
There is no other information.

No. Not for you, nor for us. Not even the information that you are not relying solely on Java for debugging, but for something else like log4j.

I didn't sign up to EE as a clairvoyant.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.