Java RTS 2.0 Update1 Released

Java RTS 2.0 Update-1 (90 days evaluation copy) is available for download. (Link: Download Java RTS)

The version available on Sun's site is for Solaris (both x86 & SPARC) only. IBM offers another version which runs on Linux with open-source real-time Linux extensions. There is no version available for Windows (with third party real-time extension). This update release provides support for Solaris 10 u4 and J2SE 5.0 u13 libraries as well as various security enhancements.

Java RTS features are delivered via a separate real-time enabled version of the Java VM. This VM can process both traditional Java SE components and Java RTS components. With Java RTS, real-time components and non-real-time components can coexist and share data on a single system.

This release is compliant with Real-Time Specification for Java (RTSJ). In fact, it is the first commercial implementation of RTSJ.

Here is more information on Java RTS (Taken from Sun's Document - as it is)

Here are the important features and benefits offered by the RTSJ and Sun's Java RTS implementation:

• New Real-Time Threads, Scheduling, and Synchronization

  The RTSJ introduces the concept of two new threads: real-time threads and no-heap real-time threads (a thread which cannot be interrupted by garbage collection). These threads offer more precise scheduling than with standard Java threads. They have 28 levels of priority and unlike standard Java, their priority is strictly enforced.

  Real-time threads are synchronized and are not subject to so-called priority inversion situations, where a lower priority thread has a block on a resource needed by a higher priority thread and thus prevents the higher priority thread from running. Rigorous testing with partners has shown that Java RTS completely avoids any priority inversions - which is crucial for mission-critical applications.

• New Memory Management Schemes

  The RTSJ defines two new types of memory areas that allow real-time applications to avoid unpredictable delays commonly caused by traditional garbage collectors:

  1. Immortal memory holds objects without destroying them except when the program ends. This means that objects created in immortal memory must be carefully allocated and managed.
  2. Scoped memory is used only while a process works within a particular section, or scope, of the program such as in a method. Objects are automatically destroyed when the process leaves the scope. This is a useful feature akin to garbage collection in that discrete creation and deletion is not required as in the immortal memory case - but the process must be sure to exit the scope to ensure memory is reaped.

  Neither immortal nor scoped memories are garbage collected, so using them avoids problems of GC interference.

• Asynchronous Events Handling & Asynchronous Transfer of Control

  The RTSJ provides two mechanisms for asynchronous communication: asynchronous event handling, and asynchronous transfer of control.

  Asynchronous event handlers deal with external events (known as "happenings") which can occur outside the JVM. The RTSJ is unique in that it allows developers to schedule the response to asynchronous events in order to avoid disrupting the temporal integrity of the rest of the real-time application.

  Asynchronous Transfer of Control (ATC) provides a carefully controlled way for one thread to interrupt another thread in a safe manner.

• Time & Timers

  The RTSJ specifies several ways to specify high-resolution (nanosecond accuracy) time including absolute time and relative time.

• Direct Access to Physical Memory

  While still maintaining security protections, the RTSJ allows direct access to physical memory. This means that device drivers can be created and written entirely in Java. Previously, Java applications had to link to native code to communicate directly with the hardware.

Java RTS Minimum Recommended System Requirements

• Dual core or dual CPU sytem with 512 MB
• Solaris 10 u3 SPARC or x86

Which persistence framework to use (JPA, JDO, Hibernate, Toplink) ?

With multiple persistence technologies in Java world, it was always difficult to evaluate all the existing frameworks and choose the best (& mature) one. Sun came up with unsuccessful technologies like entity beans and JDO. BEA created its own framework JDO based Kodo framework. Oracle's Toplink is another mature framework, which is in use for last several years. Open source communities create great persistence frameworks (Hibernate, iBATIS), which are being used heavily.

Java is an Object Oriented programming language, and it  was an unanimous desire to have a good object-relational mapping (OR Mapping) based persistence framework. In last few years, it has been established that Hibernate & Toplink are winner in this race. These are now considered as de-facto standard for persistence-framework. For last four years, I've seen Hibernate being used on all enterprise projects (except one, which was on iBATIS).

To compete with Hibernate and Toplink, Sun came up with OR-Mapping based framework "JDO". However, it failed to create an impression on java-community. BEA created its product Kodo based on JDO specification. Gavin King has highlighted few shortcomings in JDO in his article (Link: Gavin's Article). Currently, JDO provides more facilities than JPA (see comparison). However, Sun has indicated that JPA is the standard specification for OR-mapping based persistence. Here is one of FAQ from Sun (Link: JPA FAQ):

Q: What will happen to other data persistence APIs now that the Java Persistence API is available?

A: The Java Persistence API is now the standard API for persistence and object/relational mapping for the Java EE platform. Earlier APIs of course will not go away, but we expect that they will become less interesting once this new standard API is available.

Finally, experts from all popular frameworks (Hibernate, Toplink etc.) sat together to come up with a specification to define common APIs, that would be implemented or supported by the existing popular frameworks. And, JPA 1.0 was born. Hibernate, Toplink and other products were enhanced to support JPA specification.

With JPA, it is possible not to use one common APIs for many persistence frameworks. If the application is using JPA with Hibernate, it would not require any change in the code to replace Hibernate with Toplink or any other JPA based framework. Apache is working on another JPA based framework named as OpenJPA.

BEA and IBM are shipping OpenJPA as JPA implementation in their application servers WebLogic and WebSphere respectively. Oracle  has Toplink in its application server.

Conclusion

JPA is not the standard specification for OR-Mapping based persistence framework. It has support from all the major vendors including IBM, BEA, Oracle, SUN etc. Hibernate and Toplink are enhanced to support JPA. These two frameworks are in use for last several years and are mature now. It is easy to find developers with experience with these two frameworks. IBM and BEA are shipping a new OpenJPA framework, which it not proven as a mature product so far. So, in my opinion, the new projects should use Hibernate or Toplink with JPA even if the application would be deployed on WebLogic or WebSphere Application Server. And, while building the application, caution should be taken not to use any proprietary API from Hibernate or Toplink to provide portability in future.

JCP approved JPA 2.0 (JSR-317)

JCP (Java Community Process) has approved next version of Java Persistence API (JSR-317). Here is the link: JSR-317 (JPA 2.0).

The scope of JPA 2.0 is :

1. Expanded object/relational mapping functionality, including greater flexibility in combining existing mapping options, support for collections of embedded objects, multiple levels of embedded objects, ordered lists, combinations of access types, etc.
2. Additions to the Java Persistence query language
3. An API for "criteria" queries
4. Standardization of sets of "hints" for query configuration and for entity manager configuration
5. Standardization of additional metadata to support DDL generation and "Java2DB" mapping
6. Expanded pluggability contracts to support efficient passivation and replication of extended persistence contexts in Java EE environments
7. Standardization of additional contracts for entity detachment and merge, and persistence context management
   Support for validation

Its good to know that JPA 2.0 would include criteria API. I've been using Hibernate for last couple of years and have always liked criteria-API.

Almost all leading companies (including IBM, BEA, Oracle, Red Hat Sun etc.) have voted 'Yes' for this specification. Apache has voted 'No' on the ground that this spec lead - Sun - is in violation of the JSPA http://www.apache.org/jcp/sunopenletter.html and therefore shouldn't be allowed to start another JSR until the above matter is resolved. (Link: Voting Result)

Link: SUN's presentation on JPA 2.0 in JavaOne Conference 2007

How to avoid XSS security threat using Spring MVC

XSS (Cross-site Scripting) is one of the most common vulnerabilities with a web-application. And, it can be exploited by hackers very easily without using any sophisticated tool.

How does it work? Most web-applications have forms (text-box etc.) to receive input-data from user. So, a web-application may have a input-text-field to get 'user-id'. The hacker may enter anything in it including "JavaScript". If the hacker enters JavaScript (a malicious code), the server may process it, and then return it. In this case, user-id is not authenticated and it is sent as it is on the error page.

If the user's input data is returned as it is, the java-script code may execute. And, hacker wins!!

To explain further, the jsp-code may look like as shown below (using Spring MVC Form Tags):

1 <form:form id="personForm">
2 <form:input path="name" />
3 <input type="submit" value="Submit">
4 </form:form>

This will show a simple screen with an input-box and a submit button. The hacker may enter following code:

1 ">Hacker<script>alert("I am destroyer");</script>

When the page is submitted, the page is returned with error as the user is not authenticated. The error page will have the 'name' value too. In this case, the expanded page would look like:

1 <form id="personForm">
2 <input type="text" name="name" value="">Hacker <script>alert("I am destroyer");</script>"/>
3 <input type="submit" value="Submit">
4 </form>

And, while loading this page, the browser may run the script. The hacker may put anything as the java-script.

What is the solution? HTML 4.0 defines 252 Character entities (escape sequences), which include most of characters (excluding alpha-numeric) used to design HTML pages. If the input-text is changed into the html-escape-sequences during processing on server, then browser will receive the escape-sequences. The resultant text would not be a valid java-script and browser will not execute it.

After conversion into html-escape-sequences, the above code would look like:

1 <form id="personForm">
2 <input type="text" name="name" value="&quot;&gt;Hacker&lt;script&gt;alert(&quot;I am destroyer&quot;);&lt;/script&gt;"/>
3 <input type="submit" value="Submit">
4 </form>

Since all instances of characters '<', '>' and other non-alpha-numeric characters are converted into html-character-sequence, it is no longer a java-script code. So, it will not be executed by the browser. For more information on HTML-escape-entities (escape sequences), refer WiKi: http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references

Solution with Spring MVC In Spring-MVC, form-tags are used to create jsp page. Spring MVC provides multiple options to encode the html-escape-sequences on server side.

• At global level, it can be defined in web.xml file. This will be applicable to entire application. All form-tags would refer to this definition. The sample code is shown below:

1 <context-param>
2 <param-name>defaultHtmlEscape</param-name>
3 <param-value>true</param-value>
4 </context-param>

• At page level, it is defined as a tag-declaration. The code is: Any form-tag, after the above declaration uses html-escape-sequence-encoding.

1 <spring:htmlEscape defaultHtmlEscape="true" />

• Third option is to define it as attribute for each form-tag. For example, a input-text can be defined as :

1 <form:input path="name" htmlEscape="true" />

Depending upon requirement, it can be implemented as global, page or tag level.

For more information on XSS, you can refer WiKi: http://en.wikipedia.org/wiki/Cross-site_scripting

Difference between java.exe and javaw.exe

Both commands (java.exe and javaw.exe) are identical. The only difference is that java.exe is associated with a console (Command Prompt), where as javaw.exe is not associated. When java.exe command is invoked, a 'Command Prompt' window is opened automatically. By default, Standard Output and Standard Error streams are directed to the console window. Since javaw.exe is not associated with any console, the text in Standard Output and Standard Error streams is not visible. However, these streams can be directed to a file by using the methods System.setOut(…) and System.setErr(…).