Spring Framework 3.0 M2 released

We are pleased to announce that the second Spring 3.0 milestone is finally available (download page).
This release comes with a wealth of revisions and new features:

Further Java 5 style API updates: consistent use of generic Collections and Maps, consistent use of generified FactoryBeans, and also consistent resolution of bridge methods in the Spring AOP API. Generified ApplicationListeners automatically receive specific event types only. All callback interfaces such as TransactionCallback and HibernateCallback declare a generic result value now. Overall, the Spring core codebase is now freshly revised and optimized for Java 5.

Extended concurrency support: Spring’s TaskExecutor abstraction has been updated for close integration with Java 5’s java.util.concurrent facilities. We provide first-class support for Callables and Futures now, as well as ExecutorService adapters, ThreadFactory integration, etc. This has been aligned with JSR-236 (Concurrency Utilities for Java EE 6) as far as possible. Furthermore, we provide support for asynchronous method invocations through the use of the new @Async annotation (or EJB 3.1’s @Asynchronous annotation). And in Spring 3.0 M3, we’ll be adding a scheduling namespace for convenient configuration of it all… including support for cron-style timers.

OXM module in core: We moved the Object/XML Mapping module, as known from the Spring Web Services project, to the Spring core project. OXM has been updated and revised for Java 5 as well, supporting marshalling and unmarshalling through JAXB2, JiBX, Castor, XMLBeans, and XStream. There is also OXM support for Spring JMS (MarshallingMessageConverter) and Spring MVC (MarshallingView).

RestTemplate: We have brand-new client-side REST support: the long-awaited RestTemplate, with HTTP processing infrastructure that is as flexible and extensible as you would expect from a Spring solution. There are also several improvements with respect to REST support in Spring MVC… Stay tuned for Arjen’s upcoming blog post on the latest REST support features!

MVC on Portlet 2.0: Spring Portlet MVC is based on the Portlet 2.0 API (JSR-286) now. We provide specific @ActionMapping, @RenderMapping, @ResourceMapping and @EventMapping annotations for Portlet MVC handler methods, including support for specific characteristics of those request types: e.g. action names, window states, resource ids, and event names (as defined by Portlet 2.0).

Early JPA 2.0 support: Finally, we are actively tracking the JPA 2.0 specification as well as emerging JPA providers with JPA 2.0 preview support. Spring 3.0 M2 already delivers early support for the JPA 2.0 API, e.g. query timeouts within Spring-managed transactions and QueryBuilder access in Spring-managed EntityManager proxies. We’ll wrap this up for Spring 3.0 RC1, as soon as the JPA 2.0 API is stable.

Now is a good time to give Spring 3.0 an early try! Let us know how it works for you… M2 doesn’t include reference documentation yet but comes with extensive javadoc and an extensive test suite. We’ll also be showing specific examples in follow-up blog posts.

We are now working towards our final milestone already: M3 will introduce annotation-based factory methods, declarative validation (based on JSR-303 “Bean Validation”), as well as new XML configuration namespaces (orm, scheduling). Spring MVC will receive an overhaul in terms of conversation management. We are also preparing for JSF 2.0 as far as necessary, keeping up the smooth integration experience with Spring.

How to Stay Technically Ahead?

In the software development industry, it is crucial for a software developer to keep their skills up to date. It concerns me however the amount of developers I find that do not invest in their knowledge portfolio (Dave Thomas from the Pragmatic Programmer). They simply just plod along developing software which is given to them with little drive to do that bit of extra research or to investigate a potentially new technology.

I was recently saddened to hear of a former employee who had spent many years developing against a legacy system but did not pursue the opportunity to upgrade it enough. Unfortunately, when the contract was terminated and he left the company, it was a mad dash to begin tutorials on Spring & Hibernate to get an understanding on some of the technologies which have been out in the Java industry for ages.

So what is the best way to learn new technologies? And how can I develop a culture within myself of keeping up to date with some of the new things coming out? Below are some pointers that I have picked up over the years:

* Subscribe to a technical mail post or RSS feed
Within the Open Source community I read daily posts of new architectural patterns, Java components and Open Source tools. There is no human alive who has the time to sit down and develop a thorough understanding of them all. However it does not hurt to skim over some of the new technologies coming out or have a bit of dig into what is available. I personally subscribe to either JavaLobby or Java World and find 1-2 hours a week on the train to open my laptop and read daily what is emerging in the technical market.
* Don’t get stuck into too much reading
I once heard a speech on the influence of Greek practices on the Western world (resulting in an over dependence on knowledge rather than practice). There is a tendency to spend too much time reading articles, attending seminars and performing analysis before commencing code. This unfortunately leads to developers who can hold technical conversations but are unable to deliver. When learning a new technology my ultimate preference is to sit alongside someone who understands the technology and work on an example and ask questions. In my opinion, it is the best way to learn a new piece of technology. When that is not available I read the bare minimum and then just start coding – you will learn more when your reading is event driven by your coding experiences.
* Have timeouts with colleagues to discuss technical ideas
You should never underestimate the daily 5-10 minute conversations with colleagues over technical ideas. It is helpful to gain other points of view to either strengthen your case or change your perspective. In talking to some of the most junior developers, I have found things I was not aware of. Within my team we have weekly 1 hour innovation sessions. In this we investigate a range of new technologies and learn off one another. Developers love the opportunity for innovation and creativity, and this kind of investment is crucial for staff retention.
* Join a User Group (e.g. JUG)
JUG’s (Java User Groups) are global, and it is the perfect place to get an understanding of new technolgoies and expand your network.
* Establish a strong understanding of the common technologies
Across many organisations you will find a common set of technologies or frameworks used. It is important to gather a moderate understanding of each of these as it will remove any lead up time if you change jobs or projects.
* Work on or start and open source project
I try to reserve a couple of nights in the week (mainly Thursday or Saturday nights) where I can work on a personal project. My family generally goes to sleep around 9pm hence I take the hour from 9-10 to work on something I enjoy. Doing this out of the office gives you more flexibility and uninterupted time to sit relax an enjoy your coding.

Java Threads CPU Usage

It’s a known fact to every Java developer that not being careful on making use of threads on your application would most probably make it your greatest foe instead of making things better for you. Honestly speaking, I tried to stay away with threads as much as I could. Not because, I am not efficient with it but rather, I am just playing safe when it comes to the problems it might pose on my application, especially in terms of memory leaks.

Sad to say, when you are working with a GUI (Graphical User Interface) based application, it’s less likely that you won’t be using threads. This is due to the reason, that there are a lot of methods that would be best called in the background rather than having the user wait for its completion and make your application hang during this time. One good example would be data population on JTables wherein it won’t really look nice for the user to wait until 500,000 rows of data are retrieved and displayed. Wouldn’t it be nice if things would happen in the background and your application’s UI would still be responsive during this time?

Just recently, I had to work on a Swing/AWT based application and there are some instances wherein I needed to use java threads. Our API makes use of custom Swing/AWT objects and for some reasons, our custom JTextField don’t respond to text input listeners. Instead of trying to change the API, I decided to just think of some workaround so as to prevent introducing new bugs on other components, considering that we are already on a tight deadline for the customer delivery. To make the long story short, I had to create a way in which drop-down menus would be disabled when the user inputs a text inside the TextField and enable the said drop-down menus when no text exists inside the TextField. It’s pretty simple actually, if only our TextField component would listen to text input listeners, but it’s not the case. So what I did was to create a thread that checks the TextField if it contains text or not, and then disable or enable the drop-down menus accordingly. This was the first approach I did:

private boolean monitor = true;
class TextFieldMonitorThread extends Thread {
public void run() {
while (monitor) {

}
}
}

This was obviously an unending loop which I thought woud handle the TextField monitoring well in real-time, but I was wrong. Even though it didn’t pose any memory leaks, it made the CPU usage spike above normal taking around 70% – 80% of the CPU resources.

So what I did was just make use of the TimerThread class so as to make things much easier in terms of CPU usage. This basically creates a background thread that checks the TextField every second.

class TextFieldMonitorTask extends TimerTask {
public void run() {

}
}

TextFieldMonitorTask fmt = new TextFieldMonitorTask();
Timer timer = new Timer();
timer.scheduleAtFixedRate(fmt, 0, 1000);

I’m glad this resolved the problem on CPU usage, even though there might be some slight delay before the drop-down menus were disable or enabled considering the 1 second check interval. Then again this is a pretty good trade off rather than slow down the whole application or even the whole server all together.

Fun with Empty String.

Everyone uses pretty heavily IsNullOrEmpty function that is a member of String class. But sometimes we need to implement different behavior for an Empty value versus the null one. There are multiple ways we can check for an Empty value.

Here are three different ways I come up with:

public bool IsEmpty_1(string text)

{

return text == “”;

}

public bool IsEmpty_2(string text)

{

return text.Equals(string.Empty);

}

public bool IsEmpty_3(string text)

{

return text.Length == 0;

}

After looking at these functions in Reflector, it was obvious that the method that uses Length should be the most efficient. To prove it I created a little Console application that executes each comparison 100,000,000 times. Here’s the code that does it:

equality code

Here’s the result:

equality output

The result above compares empty string “” to “text”.

“text” == “”

“text”.Equals(“”)

“text”.Length == 0

You can see that statement with equality operator (==) executes slower than the one with Equals function. However if we compare empty string with empty string we would have different result.

“” == “”

“”.Equals(“”)

“”.Length == 0

Here’s the output when comparing empty string with empty string.

equal output
I am more readable.

Efficient code is important but I would chose the most readable code. Unfortunately we cannot prove with numbers which code is more readable. It can be very subjective which code is easier to read but in any case I’ll be brave enough and make my recommendations.

I would extend String class with extension method.

public static class StringUtils

{

public static bool IsEmpty(this string text)

{

return text.Length == 0;

}

}

Now we can write code like this:

“text”.IsEmpty();

We can go further and create extension methods like IsNull and IsNullOrEmpty:

public static bool IsNullOrEmpty(this string text)

{

return string.IsNullOrEmpty(text);

}

public static bool IsNull(this object obj)

{

return obj == null;

}

You probably think why do we need to extend with IsNullOrEmpty; it’s already part of String class. You don’t but I think it’s more readable. Look at two statements bellow. Which one makes more scenes to you?

string.IsNullOrEmpty(text);

text.IsNullOrEmpty();

One more note that IsNull extension method you can use with any object not just String.

List numbers;

if (numbers.IsNull())

….

Efficient Runtime Analysis of Hibernate

In a recent article claiming to “demystify” the Hibernate session context & cache a rather expensive (@runtime) and somewhat laborious (@analysis-time) approach was presented to show how the impact of certain operations in the Session interface have on the persistence context & cache components as well as database access patterns.

Note: The approach involved journaling (@runtime) each call along with some primitive (string) parameters and then presenting the entries as a sequenced call tree with the important measurements need for this rather small runtime analysis nested and scattered across different call branches.

But getting the answer to such questions as “Which entities are being added to the persistence context?” and “Which software activities trigger entity additions and database queries?” can be so much easier for both the user and the runtime once you have the right measurement model that is inherently extensible, uniform, and flexible – probes, meters and counters.

Lets start with the counters. Below is a table showing some of the counters maintained by our (@load-time) instrumentation extension libraries for Hibernate.

Note: The hibernate.add.count tracks the entities added to the persistence context.

hibernatecounters1

The counters are maintained per thread and can be aggregated at the process, host and cluster levels within the management console. We can also mark the counters to monitor the rate of change during a particular measurement interval.

In addition we can add other extension libraries to the class path to count at a contextual level (the class of the entity) as well.

Note: The class of the entity prefixes the hibernate.*.count counter.

hibernatecounters2

Now that we know what is happening in terms of our data model lets find out why by simply mapping (via configuration) custom meters to some of the above counters and then enabling probes (activities) at the appropriate application level (Seam Bean).

With the following metering table it is very easy to determine which packages, classes and methods result in entities being added.

hibernatecounters3

We can also perform a similar analysis across all meters mapped to counters.

hibernatecounters4

If you want you can even map a meter to an individual entity.* counter and rename it within the metering model. I actually recently did this for a customer that helped resolve a significant issue with an application in production.

This approach can be applied to other persistence frameworks (a similar set of counters are supplied for JPA) as well as data caches such as Oracle’s Coherence.

jxinsight5710coherence2

The only skill required in effectively using our probes technology is in deciding which software execution points become counters (and possibly mapped resource meters) and which become probes (hierarchical cost/metered groups).

5 Tips to be a Good JDBC Programmer

Have you written Java code for your database connections in JDBC that ends up being thrown away? Would using a new database software easily kill your product and set you back months at a time to port? Well, if so, keep reading as the goal of this article is to make you a better JDBC programmer.
Database

Tip #1: ALWAYS close connections

I wrote an entry about closing database connections back in July so I won’t belabor the point. Suffice it to say, one of the most common mistakes JDBC programmers make is failing to close database resources like result sets, statements, and connections. Unfortunately, because of the nature of the problem a developer will often never see the error until it is discovered in a production environment since most developers test with one process at a time. In short, every time you open a connection you should close it sometime later and that close should be nearly bullet proof, as so:
Connection con;
try {
con = …
} finally {
try { if(con!=null) {con.close();}}
catch (Exception e1) {}
}

As mentioned in the post about the subject, you can replace the finally code with a call to a method such as closeConnection() which does the same thing.

Tip #2: Always use PreparedStatements over regular Statements

As you may be aware, PreparedStatements come with many advantages over regular Statements:

* Sanitizes your database inputs: Great Example
* Organizes your statements into set of input/output commands
* Performance boost: The pre-compiled statement can be reused multiple times

The mistake a lot of programmers make is when they say “Well, I have no inputs to the query, so I’m not going to use PreparedStatements”. First off, they may have inputs down the road they needed to ‘tack on’ to the query, and it will save a lot of time rewriting the code if the query is already structured as a PreparedStatement. Second, perhaps there are some hard-coded input values that you can’t imagine changing, but could change down the road. Better to use a PreparedStatement and a static object, than to hard-code it, as shown in this example:
Statement statement = con.createStatement();
statement.executeQuery(“SELECT name FROM widgets WHERE type = ‘WidgetB’”);

versus:
final String widgetType = “WidgetB”;
Statement pStatement = con.prepareStatement(“SELECT name FROM widgets WHERE type = ?”);
pStatement.setString(1,widgetType);
pStatement.executeQuery();

Sure, the first example is shorter, but the second gives you the freedom to easily change the Widget Type down the road as well as supporting additional inputs since the setup work is all ready done.

Tip #3: Be Prepared To Change Databases

It’s not a myth; database platforms do change. You may be working on a project using Oracle and you get a request from your manager for an estimate to port the code to MySQL. It can and does happen, the question is are you going to respond with “a couple of days/weeks” or “12-24 months”. Your answer should shed some light on how good your code really is.

Tip #4: Never Reference Database-Specific Libraries

If you ever find yourself writing a line of code such as this:
OracleCallableStatement cst = (OracleCallableStatement)conn.prepareCall …

Stop! This is an example where a regular Callable Statement is likely called for, but you’re using a database-specific line in your code. The whole purpose of JDBC driver pattern is that you can drag and drop new JDBC driver libraries for MySQL, Oracle, etc into your application and the software will still compile and run just fine. Lines of code like the one above require you have the JDBC library available at compile-time and guarantee you’ll have to rewrite code to port to another language. In other words, writing a line of code like this is a developer admitting to themselves “I will definitely need to rewrite this line of code if I want to port to another database”.

Tip #5: Never use Database Stored Procedures*

Never, ever, write a Java application that relies, in large part, on stored procedures. Not only can they never be ported to a different database, 9 times out of 10, you can’t even recall exactly what they did when you wrote them. They fall into the same category of Perl code, which is WORN (write once, read never), since most of the time reading them is harder than rewriting them, mostly because TSQL/PSQL are not very pretty languages to work with.

* There some cases where stored procedures are allowed, such as reporting statistics or materialized views, but these are few and far between. The bulk of your main application logic, such as adding new users, performing basic transactions, and editing data should not rely on stored procedures in any way. Reporting is allowed here because often times performing metrics on millions of records in JDBC would require too many round trips over the network. In other words, reporting requires the kind of direct network access stored procedures guarantee since they run on the database itself. But if you are stuck using them, you should insulate them so they don’t interact with any of your java code directly, such as an independent nightly build of statistics.

Bonus Tip #6: Never put JDBC code inside JSPs

I started with 5 tips but our reader’s comments reminded me of a 6th tip: Never put JDBC code of any kind inside a JSP! The purpose of a 3-tiered architecture is to get good separation of layers, and putting JDBC code inside the presentation tier skips the middle layer all together. Some developers reduce the impact of this mistake by putting their connection code inside a Java file and only passing the result set to a JSP. This is still really bad! JSPs should have no JDBC code whatsoever since most of the time queries can be reused by multiple modules and JSPs don’t exactly lend themselves to resusability.

Why JDBC + JSP = Bad

Over years of moderating at The JavaRanch, I’ve seen one type of question spring up on a weekly basis: that asked by people who need help with JDBC code inside of Java Server Pages (JSPs). As much as we may want to help this individual fix their particular problem, the overriding thought of “STOP WHAT YOU’RE DOING” often prevents us from doing so. The purpose of this post is to explain why putting JDBC code inside a JSP file is akin to shooting yourself in the foot. With a shotgun. While not wearing shoes.

Don’t use JDBC inside of JSP pages

1. You cannot reuse the code
First and foremost is the issue of code reusability. While importing java classes is quite common, importing code from a JSP is not. While you can write JSP functions, although I never recommend doing so for reasons I won’t get into now, you’re basically writing code that you cannot be used anywhere else, particularly in non-JSP java classes. The most common counter response to this is “Well, I don’t need to use it anywhere else”. Yes, you do. Whether its just reusing code for making the connection to database or the code for performing a query and reading the results, it will be used again at some point in the future in a way you have not thought of yet. Unless you are being paid by the line and prefer this sort of thing, it’s a bad move, and I guarantee your code base will be much larger than someone who put all their JDBC code into normal Java classes. Larger code base means more difficulty to maintain and more headaches for you down the road.

2. You are mixing business logic with the presentation layer
Probably the most overlooked issue for inexperienced developers is the fact that you’re mixing the business/data layers with the presentation layer. I’ll put it another way, if your boss comes in one morning and says we’re throwing out the JSP front end and replacing it with a web service, Java Swing, Flash, or some other interface, there is virtually no way for you to reuse the database code without going through every line of every JSP file by hand. If the database code had been placed in plain java files, then you would have a path for packaging the JDBC code into a single JAR and making it available as a service to a different front-end client such as a web service, Flash, etc.

In enterprise development, the presentation JSP layer and the database are often separated by multiple layers of indirection such as described by the commonly used three-tier architecture pattern. Those who are just starting out programming often do not know why mixing these layers is bad, but I promise you if you stay with software development you’ll understand one day.

3. But it’s just this once!
Often times, JDBC code enters JSPs by developer lying to themselves saying “Well, it’s just this once” or “I just need to test something”. Instead of being removed when the developer is done ‘testing’, the code often persists for a long time afterward. Furthermore, putting your JDBC code inside of reusable Java classes makes testing go faster! Spending 10 minutes setting up a single reusable Java JDBC class will save you hours down the road. Then, if you want to test more than one JSP page with JDBC logic, you already have your Java class file to start with. Proponents of test-driven development tend to understand this better than anyone.

4. It’s really hard to maintain
Code maintenance is another topic that new developers do not fully appreciate since they have not spent years maintaining the same code base. Unless you write the most beautiful JDBC code imaginable, its very difficult to read through huge JSP files looking for bugs and/or making enhancements. It’s a lot easier if all the JDBC access is restricted to a set of files much smaller in size than the JSP code base.

5. It’s a really bad practice
If after reading this article you still do not fully understand why you should not put JDBC code inside of JSPs, let me simplify the issue by saying “Just Don’t Do It”. Whether or not developers understand the reasons against doing so is not as important as stopping them from doing so in the first place. In short, you create code someone else (possibly yourself) will have the misfortune of maintaining down the road.

Java RTS NetBeans Module 1.0 Getting Started Guide

This document provides the minimum information required for installing and using the Sun JavaTM Real-Time System (Java RTS) NetBeansTM module.

Important Note: This a preliminary version of the module.

The document contains the following sections:

Introduction to Sun Java RTS This section presents an overview of Java RTS.
The Java RTS NetBeans Module This section presents the features provided by the Java RTS NetBeans module.
Installation This section explains the installation of the Java RTS NetBeans module.
Usage This section describes how to use the Java RTS NetBeans module.
Known Limitations This section points out the known limitations of this distribution.
Introduction to Sun Java RTS
The Sun Java Real-Time System is the first commercial implementation by Sun Microsystems of JSR-1, the Real-Time Specification for Java (RTSJ), which combines industrial-strength real-time functionality with the usability, abstraction, and standards-based advantages of Java technology. Java RTS supports hard real-time, soft real-time, and non-real-time functionality concurrently within a single Java Virtual Machine (JVMTM).

Java RTS Features and Benefits
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 no-heap real-time thread cannot be interrupted by garbage collection.) These threads offer more precise scheduling than standard Java threads. They have 28 levels of priority and, unlike standard Java threads, 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.

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:

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.
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. However, the process must exit the scope to ensure that the memory is reclaimed.
Immortal memory and scoped memory are not garbage collected, so using them avoids problems of garbage collection (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 maintaining security protections, the RTSJ allows direct access to physical memory. This means that device drivers can be created that are written entirely in the Java language. Previously, Java applications had to link to native code to communicate directly with the hardware.

The Sun Java RTS product is available through Sun OEM Sales. Contact them at: OEM_Technology_telesales@sun.com or by telephone at +1-800-786-0404, Prompt 1, Prompt 3.

The Java RTS NetBeans Module
The Java RTS NetBeans module adds real-time application development support for the NetBeans 5.0 release. The only difference in the development process of an application with the Java RTS NetBeans module compared to a regular NetBeans 5.0 environment is the cross-platform development, namely the remote deployment and remote execution on a target where the Sun Java Real-Time System has been installed.

Unchanged Features in the NetBeans Module
The basic features in the NetBeans integrated development environment (IDE) remain unchanged. For example, the following features remain identical to a standard Java SE application:

Code editing and completion: While editing the code, in the middle of typing a Java RTS API class or method name, the developer can ask the system to provide a list of names to complete the word being typed. The developer can then choose a possible completion from this list, and the corresponding output from the JavadocTM tool is displayed in HTML format.
Build and runtime process: There is no change in this process compared with the standard Java SE application development.
Additional Features in the NetBeans Module
To support the development of a Java RTS application on a remote target, the following features have been added to the environment:

Creation of a new project category called Java Real-Time project in addition to the standard list. The developer chooses this project in order to develop a Java RTS application. This feature is provided in the New Project wizard.
Cross-platform development features. The Java Platform Manager wizard GUI has been enriched with a new platform category called Real Time Java, which allows the developer to specify remote deployment and execution parameters. See the Usage section below for more information.
Application deployment and execution profiles. The user can record, save, import from the filesystem, and export to the filesystem various remote deployment and execution parameters, for example, the Java RTS remote target on which the application should run. See the Usage section below for more information.
Installation
The Java RTS NetBeans module is actually a suite of three modules, each of which supports a dedicated set of features.

LocalRTSJStubs: This is a bridge module that encapsulates the necessary data for code editing, completion, build time (jar and javadoc files), and also for deployment and runtime (script files).
MackinacPlatform: This module contains all the additions and changes to the NetBeans platform application framework to support real-time development (new wizards, new project categories, and so forth).
Projects: This module contains the Java RTS project templates and additional code to support the new wizards.
To install the module suite, download and unzip the modules from this location. Then choose Tools | Update Center, select Install Manually Downloaded Modules, and click Next. Specify the location of the modules and complete the wizard. Important Note: You must install all three modules to get a complete and functional Java RTS NetBeans module installation.

Requirements
The module has been tested on the Solaris 10 Operating System, and on the Windows XP Professional SP2 and Linux platforms. Note that MacOS is not supported at this point. The system requirements to install and run the module are as follows:

NetBeans 5.0
JDK 5.0
8 MB of available space to install the modules
Usage
The development process for a Java RTS application is the same as for a Java SE application. It is performed with the following steps:

Create a Java RTS project using the modified New Project wizard.
Specify remote deployment and execution through the modified Java Platform Manager wizard.
Build and execute.
Stop the application.
Creating a Java RTS Project
The modified New Project wizard has a new Real Time Java Projects folder in the Categories panel. When this is selected, the list of available projects in the right panel provides a Real Time Java Project item. Select this subcategory of project.

When the Real Time Java Project item has been selected, click the Next button and follow the remaining standard procedure for a NetBeans project in order to create the Java RTS project.

Specifying Remote Deployment and Execution
You need to choose Tools | Java Platform Manager, to invoke the Java Platform Manager wizard, which has been enhanced to support remote deployment and execution of a built Java RTS application. The wizard provides a new Real Time Java 1.0 folder in the platform panel that the Java RTS developer selects. The developer specifies the deployment execution process parameters through the profile. Multiple profiles can be created and used at any time. The deployment and execution protocols used are rcp and rsh, respectively.

Below are the items that the user specifies:

Host Name: The remote machine on which Java RTS is installed (or the IP address of your remote target).
User Name: The user login name (configure the correct user rights for the Java RTS installation on the remote target).
Remote JDK Location: The location of the Java RTS installation on the remote target (for example, /opt/SUNWrtjv).
Remote JAR Location: The location on the remote machine where the Java RTS application JAR file is to be copied (for example, /tmp)
JVM Arguments: A text field to specify Java VM arguments to be used at runtime.
When all these parameters have been specified, click the Close button at the bottom right of the wizard.

Profiles: The Java Platform Manager wizard supports the notion of profiles. A profile records a set of deployment and execution parameters for future reuse. The developer can use the Profile combobox and the Add, Remove, Import, and Export buttons to save and manage various deployment and execution profiles.

Building and Executing
Build time: Use the standard contextual menu items named Build Project, Clean and Build Project, and Clean Project. They work in the same way as for a Java SE application.
Run time: Use the standard contextual menu item named Run Project to deploy and run your Java RTS application remotely. Remote deployment is done first, followed by remote execution. The parameters used are those specified through the modified Java Platform Manager wizard.
Stopping the Application
This preliminary release of the module version does not yet integrate a proper way of stopping the application on the remote target. If the application does not terminate by itself, you have to log onto the remote target and stop the application by killing the corresponding VM process. Note that it may then take a few seconds for your NetBeans project to be stopped.

There is however a work-around for stopping the application which may be used when there is only one instance of a Java VM running on the remote target: add the following Ant target to the build.xml file of your Java RTS project and add a target shortcut to your NetBeans environment (use the Create Shortcut contextual menu on this stop Ant target).

Known Limitations
The current version of the Java RTS module has the following known limitations:

The “Java Real Time Class Library” project subcategory in the New Project wizard is not yet supported.
Local deployment and execution is not yet supported.
Debugging or profiling the application is not yet supported.
Support for stopping the application running on a remote target is not yet properly integrated in the IDE.
Deployment and execution protocols are not yet customizable.
On Windows XP, in the argument list passed to the remote Java RTS VM, that is, in the “JVM Arguments” text field of the Java Platform Manager wizard, any ‘=’ character must be prefixed by the string “##”. In other words, “=” string must be specified as “##=”. For example, “-DMyProperty=foo” in the VM argument line would be expressed as “-DMyProperty##=foo”.

SOA principles

The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design:

* Service encapsulation – Many web-services are consolidated to be used under the SOA Architecture. Often such services have not been planned to be under SOA.
* Service loose coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
* Service contract – Services adhere to a communications agreement, as defined collectively by one or more service description documents
* Service abstraction – Beyond what is described in the service contract, services hide logic from the outside world
* Service reusability – Logic is divided into services with the intention of promoting reuse
* Service composability – Collections of services can be coordinated and assembled to form composite services
* Service autonomy – Services have control over the logic they encapsulate
* Service optimization – All else equal, high-quality services are generally considered preferable to low-quality ones
* Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms

SOA principles

The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design:

* Service encapsulation – Many web-services are consolidated to be used under the SOA Architecture. Often such services have not been planned to be under SOA.
* Service loose coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
* Service contract – Services adhere to a communications agreement, as defined collectively by one or more service description documents