What the difference between -Xss and -XX:ThreadStackSize ?

There's basically no difference between -Xss and -XX:ThreadStackSize, except
that the former dates before HotSpot became the default JVM in Sun's JDK,
where as the latter is an internal VM flag of HotSpot. In effect, the former
is support in a lot of other JVMs, but the latter is specific to HotSpot.

As an historical aside, the command line arguments for Sun JDK 1.0.x and
1.1.x had these:
-ss<number>       set the C stack size of a process
-oss<number>      set the JAVA stack size of a process

These arguments got deprecated by -Xss and -Xoss in later versions of JDK.

Non-internal flags either get processd by the java launcher (such as
-server, -client, -verbosegc, etc.) or get converted into VM internal flags
by HotSpot. See hotspot/src/share/vm/runtime/arguments.cpp for details.

For example, see this version:
the launcher part:
http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/f097ca2434b1/src/share/bin/java.c
lines 1052 - 1058,
and the VM part:
http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/81d815b05abb/src/share/vm/runtime/arguments.cpp
lines 2227 - 2240.

As you can see, -Xss gets converted into ThreadStackSize before the VM gets
to use it.
If the user did specify -ss or -Xss in command line arguments, that'll get
picked up directly by the launcher to run the main Java thread. Otherwise,
the launcher asks the VM for a preferred stack size, and HotSpot will return
ThreadStackSize, see here:
http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/81d815b05abb/src/share/vm/prims/jni.cpp,
lines 3286 - 3295.

That should explain how they've been implemented to be basically equivalent
in HotSpot.

One thing, though: because the -Xss/-XX:ThreadStackSize argument is handled
by the VM, *after* the primordial thread has been created, so they won't
cover the stack size of the primordial thread. In order to control stack
size correctly, Oracle/Sun's JDK doesn't run Java code in the primordial
thread. See this bug: http://bugs.sun.com/view_bug.do?bug_id=6316197.
If you ever felt the function "ContinueInNewThread" in the launcher was
weird, that's the fix for this issue, so that Java code doesn't get run in
the primordial thread in HotSpot.

resource from@ http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-June/004272.html

Changing the default Java Stack size for JVM

In VM arguments, pass the following parameter.

Example: I want to change it to 4MB as my JVM stacksize.

-Xss4096K

more info @http://www.onkarjoshi.com/blog/209/using-xss-to-adjust-java-default-thread-stack-size-to-save-memory-and-prevent-stackoverflowerror/comment-page-1/#comment-135809

Get thread stack size at runtime

jinfo -flag ThreadStackSize PID

resource @ https://www.java.net//node/680392

How to get process ID of current JVM

import java.lang.management.ManagementFactory;

public class ProcessID {
   public static void main(String[] args) {
      getProcessId();
   }

   public static String getProcessId() {
      String pname = ManagementFactory.getRuntimeMXBean().getName();
      System.out.println("process name = " + pname);
      String pid = pname;
      int i = pname.indexOf("@");
      if (i!=-1) pid = pname.substring(0,i);
      System.out.println("process id = " + pid);
      return pid;
   }

}


Output:

process name = 7108@KH1205
process id = 7108

Lot of other resources @ https://sites.google.com/site/baohuagu/java-codes

NLS.bind(...) vs MessageFormat.format(...)

Follow the discussion on this @ http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg08041.html

I prefer to use NLS.bind() when I am working with PDE, since this is simple, fast.

Java Code Metrics

Google CodePro AnalytiX - Metrics

http://sourceforge.net/projects/metrics/

I liked Google Analytix. It is simple, easy to use, fast and accurate

Update site @ 

http://dl.google.com/eclipse/inst/codepro/latest/3.6   for eclipse 3.6


Tested Results for my plug-in:

Lines of Code: 5,18,178

This is a count of the number of lines in the target elements that contain characters other than white space and comments

Number of Lines:  This represents lines of code with comments.

Global Results

Metric Name	Value
Abstractness	4.8%
Average Block Depth	1.18
Average Cyclomatic Complexity	2.94
Average Lines Of Code Per Method	12.96
Average Number of Constructors Per Type	0.45
Average Number of Fields Per Type	2.84
Average Number of Methods Per Type	5.79
Average Number of Parameters	0.90
Comments Ratio	5%
Efferent Couplings	3,302
Lines of Code	518,178
Number of Characters	26,077,514
Number of Comments	26,156
Number of Constructors	2,636
Number of Fields	27,006
Number of Lines	695,811
Number of Methods	33,343
Number of Packages	220
Number of Semicolons	308,386
Number of Types	5,751
Weighted Methods	107,977

Why would one mark local variables and method parameters as “final” in Java?

http://mindprod.com/jgloss/final.html

http://www.javaperformancetuning.com/tips/final.shtml

http://www.javaperformancetuning.com/tips/rawtips.shtml

http://www.javapractices.com/topic/TopicAction.do?Id=23