Tuesday, October 7, 2014

How To Resolve "Java compiler level does not match the version of the installed Java project facet." Issue in Eclipse, STS tool or Eclipse Based Tools

                  I have faced this issue during the Java 7 upgrade from Java 6 into one of our application. You will face this issue suppose if your application or project built on lower versions of Java (in my case it is Java 1.6) and you are trying to upgrade it to the Higher versions of Java (in My case it is Java 1.7), then Eclipse will throw this error in the tool. You will face this error even after changing the compiler version from build path. To fix this issue Follow the Below Mentioned Steps.


1.  Open the 'Markers' Tab at the bottom of the eclipse or STS tool beside the 'Properties' Tab. (as shown in the below figure)




2. Right Click on the Error as mentioned in the below figure. in The context menu click on the 'Quick Fix' item as shown below in the figure.



3. Select the correct Java Project Facet from the 'Quick Fix' Window. and click on the 'Finish' Button.



4.  After Clicking on 'Finish' button you cannot see the error. Please check the figure below for the result.



That's it. It is that simple...?


Saturday, October 4, 2014

Java Important Links

Java Performance Checklist

Specify the required performance.
  • Ensure performance objectives are clear.
  • Specify target response times for as much of the system as possible.
  • Specify all variations in benchmarks, including expected response ranges (e.g., 80% of responses for X must fall within 3 seconds).
  • Include benchmarks for the full range of scaling expected (e.g., low to high numbers of users, data, files, file sizes, objects, etc.).
  • Specify and use a benchmark suite based on real user behavior. This is particularly important for multi-user benchmarks.
  • Agree on all target times with users, customers, managers, etc., before tuning.


Make your benchmarks long enough: over five seconds is a good target.
  • Use elapsed time (wall-clock time) for the primary time measurements.
  • Ensure the benchmark harness does not interfere with the performance of the application.
  • Run benchmarks before starting tuning, and again after each tuning exercise.
  • Take care that you are not measuring artificial situations, such as full caches containing exactly the data needed for the test.


Break down distributed application measurements into components, transfer layers, and network transfer times.

Tune systematically: understand what affects the performance; define targets; tune; monitor and redefine targets when necessary.
  • Approach tuning scientifically: measure performance; identify bottlenecks; hypothesize on causes; test hypothesis; make changes; measure improved performance.
  • Determine which resources are limiting performance: CPU, memory, or I/O.
  • Accurately identify the causes of the performance problems before trying to tune them.
  • Use the strategy of identifying the main bottlenecks, fixing the easiest, then repeating.
  • Don't tune what does not need tuning. Avoid "fixing" non-bottlenecked parts of the application.
  • Measure that the tuning exercise has improved speed.
  • Target one bottleneck at a time. The application running characteristics can change after each alteration.
  • Improve a CPU limitation with faster code and better algorithms, and fewer short-lived objects.
  • Improve a system-memory limitation by using fewer objects or smaller long-lived objects.
  • Improve I/O limitations by targeted redesigns or speeding up I/O, perhaps by multi-threading the I/O.


Work with user expectations to provide the appearance of better performance.
  • Hold back releasing tuning improvements until there is at least a 20% improvement in response times.
  • Avoid giving users a false expectation that a task will be finished sooner than it will.
  • Reduce the variation in response times. Bear in mind that users perceive the mean response time as the actual 90th percentile value of the response times.
  • Keep the user interface responsive at all times.
  • Aim to always give user feedback. The interface should not be dead for more than two seconds when carrying out tasks.
  • Provide the ability to abort or carry on alternative tasks.
  • Provide user-selectable tuning parameters where this makes sense.
  • Use threads to separate out potentially blocking functions.
  • Calculate "look-ahead" possibilities while the user response is awaited.
  • Provide partial data for viewing as soon as possible, without waiting for all requested data to be received.
  • Cache locally items that may be looked at again or recalculated.


Quality-test the application after any optimizations have been made.


• Document optimizations fully in the code. Retain old code in comments.

Be-Aware of the Performance of the String Concatenation...

                 The string concatenation operator (+) is a convenient way to combine a few strings into one. It is fine for generating a single line of output or for constructing the string representation of a small, fixed-size object, but it does not scale. Using the string concatenation operator repeatedly to concatenate n strings requires time quadratic in n. It is an unfortunate consequence of the fact that strings are immutable. When two strings are concatenated, the contents of both are copied.

For example, consider the following method that constructs a string representation of a billing statement by repeatedly concatenating a line for each item:


// In-appropriate use of string concatenation - Hits Performance drastically!

public String statement() {
     String res = "";
     for (int i = 0; i < numOfItems(); i++)
      res += lineOfItem(i); // String concatenation
      return res;
}

                 This method performs very slow if the number of items is large. To achieve acceptable performance, use a StringBuilder in place of a String to store the statement under construction. (The StringBuilder class, added in release 1.5, is an unsynchronized replacement for StringBuffer, which is now obsolete.)

public String statement() {
      StringBuilder sb = new StringBuilder(numItems() * LINE_WIDTH);
      for (int i = 0; i < numOfItems(); i++)
       sb.append(lineOfItem(i));
      return sb.toString();
}

                The difference in performance is dramatic. If numOfItems returns 100 and lineOfItem returns a constant 80-character string, the second method is 85 times faster than the first on my machine. Because the first method is quadratic in the number of items and the second is linear, the performance difference is even more dramatic for larger numbers of items. Note that the second method pre-allocates a StringBuilder large enough to hold the result. Even if it is retuned to use a default-sized StringBuilder, it is still fifty times faster.

                The moral is simple: don’t use the string concatenation operator to combine more than a few strings unless performance is irrelevant. Use StringBuilder’s append method instead. Alternatively, use a character array, or process the strings one at a time instead of combining them.