Recently, working on an important customer project, I assumed that because all latitude and longitude data was entered in degrees, our projection routine expected degrees as well. Not true! The problem didn't manifest itself until late in the project life cycle, when we discovered that screen positions were way off base. A thorough review revealed that half our code dealt with radians and the other half with degrees. As co-spec lead of JSR 275: Measures and Units, I couldn't help but smile. I knew that this kind of problem would soon be a thing of the past. |
The J2EE (Java 2 Platform, Enterprise Edition) specification should ease enterprise computing; we should be able to simply develop enterprise applications and deploy them into a J2EE-compliant product. But the reality is different because the J2EE specification does not go far enough. Many application server features are vendor specific, and, to avoid vendor lock-in, we need further standardization. One particular aspect of standardization is J2EE server management, an aspect covered by the J2EE Management Specification, Java Specification Request (JSR) 77. The J2EE Management Specification abstracts the manageable parts of the J2EE architecture and defines an interface for accessing management information. This helps system administrators integrate J2EE servers into a system management environment and also helps application developers create their own management tools. |
I'll stop short of saying JSR-286 is dead on arrival and instead simply say that while it is a welcome step forward for those currently doing JSR-186, I believe JSR-286 will not be able to reverse the negative momentum, and portal architecture will continue its well-established decline toward (and eventually over the edge of) irrelevance. |
The new Java Scripting API integrates scripting languages into the Java environment. JSR-223-aware applications can execute scripts and, if the scripting language supports this feature, exchange data objects with them. My article "Scripting for the Java Platform" shows you how to query available languages and how to communicate with them. But what does it take to make existing scripting languages JSR-223-aware? This article is based on my work on Java-AppleScript-Connector, a bridge between AppleScript and Java. I will explain important classes and interfaces you need to provide and offer sample implementations as well as best practices. |
JSR 166, charged with creating a set of standardized concurrency utilities for JDK 1.5, has recently emerged from public review. Over the course of the last two years, the JSR 166 Expert Group has worked on reformulating Doug Lea's popular util.concurrent library and packaging it as a standard part of the 1.5 Java Class Library, to become the java.util.concurrent package. The result is a scalable, robust, high-performance set of standardized concurrency utilities, intended to greatly simplify the development of concurrent applications. |
All the domain-specific APIs under the OSS technologies section on jcp.org inherit from the implementation of the design guidelines defined by JSR 144. JSR 144 also provides the definition and implementation of all the components (also called Core Business Entities (CBE)) that are shared, manipulated, extended and managed between all the interfaces. These ready-made implementations are available to users to extend as they need. Generic objects can be used or shared between specific implementations, and these objects can be assembled by the containment relations, which are also defined by JSR 144, to create application models. |
Have a question or opinion about the Design-Time API described in this article? Discuss this article in the Articles Forum topic, Java Rockets Closer to VB-like Ease with JSR 273. |
|
A metadata facility for the JavaTM Programming Language would allow classes, interfaces, fields, and methods to be marked as having particular attributes. |
The schema compiler will be a command-line tool rather than an extension to the platform itself, though it may also be exposed in a public but non-platform API for direct use by development tools. As such, the most important part of the proposed specification with regard to the schema compiler will be the description of the mapping of XML schemas into Java classes. |
1. JSR 175 for Java Language Metadata 2. WSDL 1.1 3. SOAP 1.1 4. Schema 1.0 5. JSR-109 6. JSR-101 7. Existing J2EE specifications. 8. JSR-088 9. Apache AXIS "JWS" drop-in deployment of web services 10. BEA WebLogic Workshop "JWS" annotated java web services |
Original Summary: The JAX-RPC 2.0 specification extends the existing JAX-RPC 1.0 specification with new features, including some or all of the following: direct support for JAXB 2.0-based data binding, support for the latest W3C and WS-I standards (e.g. SOAP 1.2, WSDL 1.2), standardized metadata for Java<->WSDL mapping, ease-of-development features, support for easier evolution of Web services, an improved handler framework, support for asynchronous RPC and non-HTTP transports. |
Have an opinion about scripting languages in Java and the BeanShell? Discuss this article in the Articles Forum topic, Scripting Java: The BeanShell JSR. |
It is therefore with considerable trepidation that we propose adding a third RPC system to the Java platform. However, it has been a consistent goal of the Java Platform to allow Java programmers to conveniently use common industry infrastructure and common industry protocols. So it is in that spirit that we propose support for XML based RPC standards. It is important to allow Java developers convenient access to merging web standards. We hope that in developing these new APIs and mappings we will be able to benefit from the existing experience in the Java community, and from the lessons learned in projects like RMI-IIOP. |
This JSR extends the JavaBeans specification and APIs to improve design-time functionality for component authors to leverage within the visual design environments in IDEs. |
JAXB 2.0 is a follow-on to JSR 31 JavaTM XML Data Binding Specification building upon the architecture introduced in JAXB 1.0 JAXB 1.0 lowered the barrier for developers manipulating XML content from Java TM applications. This was achieved by specifying a binding of a XML document to JavaBean objects based on the XML document's XSD schema. The binding was easy to use and natural to a Java programmer. To date, these API's have been used to successfuly process some large, well known schemas. JAXB 2.0 will add new functionality in several important areas. The proposed functionality will enable the development and deployment of JAXB applications in an even wider range of environments. JAXB 2.0 will be backward compatible with JAXB 1.0. |
The vast majority of the package will be implemented on top of lower-level Java constructs. However, there are a few critical JVM/language enhancements surrounding atomicity and monitors necessary to obtain efficient and correct semantics. |
This specification defines the programming model and architecture for implementing web services in Java. The specification will build on the work of JSRs 67, 93 and 101. The specification will also build on the JSRs for J2EE technologies, including J2EE itself, Servlets and JSPs. The intent of this JSR is not to subsume J2EE JSR's role nor to define a platform. We also do not pre-suppose that this JSR's output will become part of J2EE. Selecting this JSR's output, in whole or in part, for inclusion in J2EE will be decided within the J2EE JSR process. |
The Bluetooth protocol stack lets you use several methods, including RFCOMM and Object Exchange (OBEX), to send and receive files between devices. RFCOMM is better when you want to send and receive stream data (and when you'd like to take a traditional serial port application and Bluetooth-enable it). On the other hand, OBEX is great when you want to send object data, context, and metadata about the payload. In this article, you become familiar with the Java language library used to control a Bluetooth device and learn how JSR-82 API and OBEX can be used to transfer files between the client and server. |