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

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