Issues with the JDK, Eclipse Galileo and PATH Environment variable

Problems with the JDK and Eclipse:

"JDK Not found...." & "JNI Error..."

I had quite a lot of trouble fixing my Java JDK and Eclipse Galileo IDE. Thing was that I was trying to reuse my old installation of Eclipse (which being portable does not require a setup/installation) with the old JDK 1.6.0 Setup, I had saved. My old eclipse started throwing up strange problems when I tried working on new projects in my old workspace, even though the previous projects and files were working fine with the IDE.
I decided on updating my Java which gave me a new JRE 1.7 which existed with JDK 1.6.0 (Creating more path related confusions). This created more hassles with my system when I tried installing a new version of Eclipse IDE Kepler. The IDE started throwing "JDK not found" errors and my command prompt (Yes, I'm still stuck with Windows 7. I will build a dual boot with Linux Mint, as soon as I get the download finished.) also did not respond to "java" or "java -version" commands. So, I figured out that my JDK has been screwed.

Ineffective Solution:

I tried all the fixes available from altering the "eclipse.ini" configuration file shipped with eclipse to point to my JDK using "-vm %JAVA_HOME%"\bin\" and other similar combinations. Then the system started throwing JNI Error of a missing .dll file from the jre in the client folder. One way was to link to its path the location in the configuration file (Messy! Don't do that! Well, unless you know what you're doing).

Solution:

Uninstalled and Reinstalled Java (JDK 1.7). [My suggestion; You should try CCleaner after uninstalls to clean and fix Windows Registry.] Set the PATH environment variable from:

Advanced System Settings (From My Computer Properties after Right Clicking) > System Properties (Dialog) > Advanced (Tab) > Environment Variables (Button) > System Variables (Window) > New/Edit (Button below the window depending whether "path" or "PATH" variable exists or not) > Adding the path/address to "%JAVA_HOME%\bin". Then you may need to restart the system.

  

I downloaded the download available from Oracle with the latest Netbeans IDE bundled together. [Link] (For the JDK only try this Link.)

Did You Know: There are different JDKs available to use. They have the same standard libraries but, they also have special libraries bundled with them to be compatible with the other vendor services and tools. The two giants IBM and Oracle, there are Open Source versions too, like the one from GNU and OpenJDK; Courtesy of Sun Microsystems, which had released the Source Code as open source sometime, back in 2006.

Conclusion: My JDK, Eclipse Kepler and NetBeans IDE works like magic.

Other known Reasons for similar JDK and Eclipse Problems are incompatible softwares, like using 64 Bit JDK or IDE on a 32 Bit System. Here is a small note on it:

Working: 32 Bit OS + 32 Bit JDK + 32 Bit Eclipse IDE

Working: 64 Bit OS + 32 Bit JDK + 32 Bit Eclipse IDE

Working: 64 Bit OS + 64 Bit JDK + 64 Bit Eclipse IDE

Related articles

• Install Eclipse on Your Windows OS, A Step by Step Guide with Screenshots (ashout.com)
• Installing jdk and eclipse (haramritpanesar.wordpress.com)

Javadoc: The Bible of Your Java Source Code

Today I'll be sermonizing on Java, my dear readers. I have observed since I began learning Java in my third semester of Computer Science Engineering undergraduate course that comments are a vital part of a program or rather the source code. But, never were we taught about good commenting standards and commenting conventions. Also, our exposure to the Javadocs was minimal. Our only interaction with the Javadoc was when the IDE (Netbeans or Eclipse or any other) would produce a small popup window with a summary about the keyword over which our mouse pointer was hovering.

It fills me with sadness that such vital skills of reading, navigating, understanding and producing Javadocs was never taught or even appreciated. Like some unspoken truth, we all kept mum and so did our teachers, that we’ll eventually learn it “on the job” or “later in life”. I seriously doubt about the many Indian, so called, software professionals knowledge on how to comment code correctly and generate usable Javadocs or read other programmer’s Javadocs. Any Java programmer worth his salt must have this essential skill of playing around with the Javadocs.

There are various commenting styles in the art of programming each style has a certain aim in mind. Some of the commenting styles can be roughly categorized as:

• Explanatory/Verbose Commenting – Used by experts, teachers and trainers to explain in detail what each line of the code does. It is generally regarded as “How?” themed commenting. It is also used when a complicated piece of algorithm is implemented which cannot be understood without certain explanatory aid. This style is generally picked up by students from their teachers, but, is not good for day to day professional use. Most of what any programmer will code in life will be simple and easy to understand without any comments. The best code is self-explanatory without necessitating a single line of code.

• Reasoning/Terse Commenting – Used by professionals in day to day coding, it involves adding comments only when a certain part of the code is not self-explanatory and departs from the ordinary trend of coding. For example the forking of a certain thread to handle background tasks etc. It is generally regarded as “Why?” themed commenting. In other words it is a minimalist approach to commenting. You comment only when it is most required.

• Documentation Commenting – Used to generate documents or guide other programmers using your source-code either as an API or a Legacy code. It may detail hardware and software dependencies, performance issues, code vulnerability (Yeah, you’ll find in some legacy codes useless warning comments such as, “//DON’T TOUCH THIS CODE! EVERYTHING WILL BREAK. TALK TO BOB BEFORE EDITING THIS CLASS”, where Bob is someone who has left the company 15 years ago. Good luck with that, mate.) This commenting style is best seen in Open Source APIs, where you can seek help from Open Source communities which may take a longer time to resolve your issues and even third party licenced APIs, though they provide a paid support service to resolve your issues in the least time possible.

Note: No adherence to a single style is requisite. Often, a mix of all styles will be required to deliver a useable and malleable source-code.

Javadocs, ahoy!!

 

Javadoc is a documentation generator from Oracle Corporation for generating API documentation in HTML format from Java source code. (Yes. This line is ripped off from Wikipedia. Now, please, don’t label me as a plagiarist.)

Javadoc handles only a specific format of commenting within the Java source codes. It can be either generated by using the pre-bundled javadoc tool with the JDK or invoking it via any Java compatible IDE (I’ll be sticking with Eclipse in this blog. Go to hell, Netbeans! *Just joking! I know how many of you still depend on it and I can empathize with you.*).

I’ve attached the source-code of a simple java program (which I did not care to test run even once. Don’t bother compiling and running it. Our focus should be on commenting for Javadoc.) with screen shots of generating and using the related Javadocs of this project. [The screen-shots are available here only, as my paid internet data usage quota has expired and I am currently blogging at the speed of 3~4 Kbps. I promise to update the bundled project with screen shots after I get my internet connection recharged which is looking doubtful considering I have already paid for the recharge and the confirmation SMS or transaction SMS has not yet been received since today morning 8 AM or so.]

Now, let’s see. Step 1:

Select the Element you want to comment on. Like in the above screen grab, I’ve selected method Circle from class FigureStore.

 

Step 2:

Select the Generate Element Comment option from the drop down menu of Source button from the main menu.

Step 3:

Eclipse auto-generates the comments depending on the selected element. As here the selected method Circle has two parameters, the Radius as X and the Diameter as Y.

Step 4:

Now, edit the element comment as required. Try adding details as briefly as possible.

Step 5:

After you’ve added all the element comments you need to generate the Javadoc. For generating the Javadoc for your project, select it in the package explorer and the choose Generate Javadoc from the Project option in the main menu.

Step 6:

Now, you’ll see a dialog as shown in the above image. Make sure your project is selected as well as all of its components. The Javadoc tool is selected via the Configure button. The Javadoc tool is present in the “bin” directory of the JDK. Also, set the path of your doclet to a new “doc” directory of your project.

Step 7:

You can add a specific document title to your doclet and you may add any referenced/dependent jars and packages which mainly comprise of the JDK libraries. Then select Finish. (Yes, I don’t go any further with that alluring “Next” button.)

Step 8:

Now, sit back and relax for a few moments while the Javadoc is being generated. The time take for Javadoc generation is dependent on the number of Elemental Comments, program size, structure etc. Your Console should show something like this:

 

Alternate Method:

Here’s an alternate method to generate Javadocs. Right click on your project in the Package Explorer. Select “Export” from the drop down menu and a dialog will appear as shown below.

Select Javadoc from the Java directory and Bam! It’s done (It’ll take you to the Javadoc Generaton Dialog). 

What to expect from Javadocs?

You’ll see a new directory under your Project in your Package Explorer called “doc”. Exanded it’ll look like this;

The “index” html file is the start or main page of your Javadoc. Double click on it to open it inside Eclipse. A sample Javadoc is shown below;

 

Also, now you’ll be able to invoke small popup help windows for your project/package which can be used in other projects as well if the Javadoc is imported in there Project directories.

 

IMPORTANT END NOTE:

A good habit is to keep on making Element Comments while programming in order to keep the burden of commenting low. Once the size of the source code gets out of hand commenting becomes difficult and you’ll not be able to leverage the Javadoc prompts for other parts of your source-code.

“Also, one must always try to keep deprecated (i.e discontinued) methods in future iterations and newer versions of the program/package in order to maintain backward compatibility.”

Sample Documents and Source Codes::

https://drive.google.com/folderview?id=0B4e1TZA7mwrNWnFRMmxmS05pc3M&usp=sharing