Remote procedure call (RPC) systems, including Java RMI, are synchronous — the caller must block and wait until the called method completes execution, and thus offer no potential for developing loosely coupled enterprise applications without the use of multiple threads. In other words, RPC systems require the client and the server to be available at the same time. However, such tight coupling may not be possible or desired in some applications. Message-Oriented Middleware (MOM) systems provide solutions to such problems. They are based on the asynchronous interaction model, and provide the abstraction of a message queue that can be accessed across a network. Note, however, that messaging here refers to asynchronous requests or events that are consumed by enterprise applications and not humans as in electronic mail (email). These messages contain formatted data that describe specific business actions.

The Java Message Service (JMS), which is designed by Sun Microsystems and several other companies under the Java Community Process as JSR 914, is the first enterprise messaging API that has received wide industry support. The Java Message Service (JMS) was designed to make it easy to develop business applications that asynchronously send and receive business data and events. It defines a common enterprise messaging API that is designed to be easily and efficiently supported by a wide range of enterprise messaging products. JMS supports both messaging models: point-to-point (queuing) and publish-subscribe.

JMS was defined to allow Java application to use enterprise messaging systems. More importantly, it provides a common way for Java applications to access such enterprise messaging systems. JMS falls under middleware, and specifically Message-Oriented Middleware (MOM), which is a relatively low-level of abstraction that runs underneath complementary layers such as database and application adapters, event processing, and business process automation. MOM is becoming an essential component for integrating intra-company operations as it allows separate business components to be combined into a reliable, yet flexible, system.

JMS defines a set of interfaces and semantics that allow Java applications to communicate with other messaging implementations. A JMS implementation is known as a JMS provider. JMS makes the learning curve easy by minimizing the set of concepts a Java developer must learn to use enterprise messaging products, and at the same time it maximizes the portability of messaging applications.

for more information please click on the link below

http://java.sun.com/developer/technicalArticles/Ecommerce/jms/index.html

Sun is releasing weekly early access snapshots of the complete source, binaries and documentation for JDK 7. These raw snapshot releases let you review and contribute to the Java SE platform as it is being developed.

Some possible language changes being considered for Dolphin include:

• property support (for getFoo()/setFoo() pattern)
• method references (a quick way to write an event notification pattern)
• block closures (collection of statements within a statement)
• native XML support

Java 7.0 New Features

• Closures

  Closures are something like C callbacks, a pointer to a function that you can pass as a parameter. In addition to the method, some context around that method is snapshotted to go along with it in the closure.

  Another way of putting it is a closure is an anonymous function body, that can be declared and passed around as a first-class object, and which can refer to variables from its enclosing scope. The anonymous classes in JDK 1.1 provide closure-like facilities, albeit with tacky syntax. Smalltalk “blocks” are closures.

• JSR 277 Java Module System

  

• JSR 294 Improved Modularity Support

• JSR 295 Beans Binding

• JSR 303 Beans Validation

• JSR 296 Swing Application Framework

• JSR 203 NIO2JSR 220 Java Persistence APIs

• JSR 255 JMX 2.0

• JSR 262 Web Services Connector for JMX

• JSR 260 Javadoc Technology Update

• JSR 275 Units and Quantities

• JSR 310 Date and Time API

• JSR 308 Annotations on Java Types

You don’t need to debug Java™ applications on just your local desktop. Learn how to spread around your debugging using different connection types that make up remote debugging. This article explains the features and examples that show how to set up remote application debugging.

Remote debugging can be useful for application development, such as developing a program for a low-end machine that cannot host the development platform, or debugging programs on dedicated machines like Web servers, whose services cannot be shut down. Other examples include Java applications running with limited memory or CPU power, such as mobile devices, or developers wanting to separate the application and development environments, etc.

please check this link to know more

http://www.ibm.com/developerworks/java/library/os-eclipse-javadebug/index.html?S_TACT=105AGX02&S_CMP=EDU