7

While discussing another question I asked, @Aaron Digulla pointed out the following:

If you installed the Java SDK, there should be a "src.zip" file in the root directory of the Java installation. If it's missing, download Java again. Eclipse should find the source automatically and show it to you when you open the type JTable (or when you click on the line in the stack trace).

The file src.zip is present for me, but I still can't access the source of JTable like @Aaron said. What could be the problem? How can I solve this with Eclipse?

The "Unknown Source" worries me, though. it means your version of Java doesn't have debug symbols. Make sure that you a) use a SDK while developing, b) that your SDK contains debug symbols, c) don't tell the command java to strip debug symbols when it loads classes.

a) I'm using Eclipse, why shouldn't I being using SDK?

b) How do I know if my SDK contains debug symbols? And if it doesn't, how can I add them?

c) How can I check if Eclipse is telling java to strip debug symbols?

Sorry for these banal questions, but I feel like I don't fully understand the Java development process.

Community
  • 1
  • 1
Heisenbug
  • 38,762
  • 28
  • 132
  • 190

2 Answers2

6

a) Eclipse comes with it's own Java compiler, so if you are using the Java Runtime Environment, you won't run into many issues, except that extras like jarsigner and possibly the JRE source code may be missing. The best way to verify your installation is through your package manager; however, if you installed by some other means, careful directory observation can usually differentiate the two (see below).

b) JRE libraries are typically compiled without debugging symbols present. SDK libraries typically have them. Java debugging is done by starting the JVM with command line options which open a debugging port. The SDK talks to the JVM requesting breakpoints be set through this port. Later if you decide to step the JVM, it also sends the step / jump / rewind debugging commands through this port. The "debugging" symbols are actually JVM bytecode tables, which reference which line of source code is in effect starting at a particular bytecode instruction. This allows debuggers to associate the running bytecodes with line numbers in the original source code.

c) Verify it by (from the menu) Window->Preferences (on the selector column) expand "Java", expand "Build Path" under "Java", and select "ClassPath variables". You will see a few variables, including one called "JRE_SRC", which should point to the src.zip file containing the public facing JRE library source code. It is a good idea to verify JRE_LIB at the same time.

A JDK home directory typically contains a "bin" sub-directory and a "jre" sub-directory, so if you only see a "bin" sub-directory, odds are good you are in a JRE home directory. With this knowledge, hopefully you'll be able to figure the rest out.

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
  • +1 thank you so much for the help. Now it's all more clear. JRC_SRC is actually empty, I'll fix that. Just another question: I think I'm using JRE libraries not SDK, how do I change that? – Heisenbug Jun 01 '11 at 15:40
  • @0verbose, first download the JDK and install it. If you are on Linux, Windows, or Solaris download the SUN/Oracle JDK. On something else, refer to your vendor's instructions for the JDK. Then make a note of the "root" directory of the JDK. From the same "Java" context in the config dialog, select "installed JREs" and add your JDK root directory. Check the box next to the JRE to make it default for new projects. Then go back and set the "Compiler" compilance level to that of your JDK. Finally you might need to set the build path of existing projects to correspond to the new settings. – Edwin Buck Jun 01 '11 at 15:51
1

Go to the preferences (Window -> Preferences) and type "JRE" in the search field.

Select "Installed JREs". Make sure that the Java Runtime uses the version of Java which you expect.

If it does, select it, click "Edit". The icon for "rt.jar" should have a little text symbol on top of it (it should look different than the dnsns.jar, for example).

If it doesn't, click "Restore Defaults". If that doesn't work, double check the path.

This should also solve your other problems.

To check whether a class contains debug symbols, decompile it with javap -v (see this question: Check if Java bytecode contains debug symbols)

Some Java implementations allow to ignore debug symbols as classes are loaded. This can cause "Unknown Source" for classes which contain symbols. I was sure that there was such an option for Sun's Java but I can't find it anymore.

Community
  • 1
  • 1
Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820