With J2SE Version 1.4, Java finally has a scalable I/O API. Not that the old API was an absolute failure (Java's tremendous success in the application server market refutes this), but some of the old API's properties led to drastic restrictions. The worst one was the blocking I/O.

By necessity, the operating system loads each VM into its own separate process slot. Consequently, each VM is forced to duplicate the other's initialization efforts and resource allocations. Specifically, each VM is required to load the JDK core classes into their respective heap spaces.

These paradigm changes have greatly increased my power to express program logic, such that my programs have gotten smaller, simpler, and much easier to understand, while supporting ever-increasing user capabilities. When I started programming, I worked with simple command-line interfaces and text-based “green screens.” Next I produced “fat-client” graphical user interfaces, and now I work on Web-enabled user interfaces. Again, each paradigm switch has greatly increased user power, flexibility, and ease of use while the code required to produce the interfaces has decreased and is much simpler to understand.

An enterprise platform has to provide ways to integrate with existing systems and applications. The fact is, most companies have applications and they don’t exist in isolation. New applications developed on the J2EE platform need to be integrated with other applications. Although this might sound relatively simple, we must be aware that companies need fully integrated information systems. This means that all applications, no matter which technology they’re developed in, function as a large integrated system. The total integration of applications within a company is referred to as Enterprise Application Integration (EAI).

Whether you’re an IT manager or a J2EE architect, if you’re interested in EIS connectivity you’ll be excited about the promises of JCA. What is JCA? What are its most appealing features? What are its shortcomings? Who are the vendors that support it? Are there any other choices so I can do some comparison shopping? What path should I take from here? This article sheds some light on these questions.

The technology to automatically generate a parser from this syntax specification has existed for around 20 years and is now mature enough to use in a product setting. A parser generator is a software program that accepts a syntax specification as input and generates a parser for that syntax as output.

Of course, TAPI still has a niche and is indeed embedded into many PC modems, but its track record against its original goals is, shall we say, modest. Some would say that it never saw the Internet coming. Of course, technology development is almost Darwinian in the way it casts off also-rans. VRML promised us the world and is much cooler than HTML; Microsoft’s Blackbird would give us our information superhighway; JSDT would revolutionize application collaboration; Network PCs, BeOS, BetaMax…

The most basic way to capture these elements of interest is through application logs. Most Java-based production systems have them in some form, and most of them probably implement a custom API or use one of a handful of third-party packages that may or may not be cross-compatible. Out comes java.util.logging in the new Java 2 Platform, Standard Edition (J2SE) v1.4. Developed collaboratively with input from several key contributors (see “JSRs: Java Specification Requests” at http:/ /jcp.org/jsr/detail/47.js p for details), this package can be used as is, extended for additional functionality, and in conjunction with enterprise application services.

Mac OS X sports a new look, not just on the outside with its great look and feel but also on the inside. OS X is proudly built on top of a BSD Unix-based core foundation. An exciting aspect of the new operating system is that the latest version of the Java 2 platform (J2SE v1.3) is preinstalled in every Macintosh notebook and desktop preloaded with OS X. (The current release is 10.1, however, in this article I’m referring to the latest version of OS X, v10.1.1.)

In an age of spin and counterspin, where no one calls a spade a spade if there's a chance of calling it an HDK instead (“hole development kit”), JDJ Industry Newsletter decided to canvass Internet technology experts of every stripe and ask them to anticipate the future – in just two words. Brevity, we felt, might increase the pressure on them to be incisive and insightful, and we weren't disappointed.

As part of building the infrastructures for a large J2EE project, we've spent the last few months designing and implementing a JDO-based O/R persistency framework. This framework provides our business logic programmers with the following features: an interface-based abstract view of the data-layer with full OO semantics, zero-need knowledge of the object-to-database mapping details, 'delta' support, and more. This article presents the persistency framework that we've built on top of JDO, and offers a commentary on the current advantages and shortcomings based on our experience with the JDO specification.

Design patterns exploded onto the scene when the seminal work, Design Patterns: Elements of Reusable Object-Oriented Software, was published in 1994. Since that time, numerous books on patterns have been written, conferences devoted solely to the patterns movement have emerged, and entire Web sites are dedicated to discussions on patterns. Compound patterns that represent a combination of patterns have even been discovered.

Java's new assertion mechanism, a welcome addition to the language now available in version 1.4, allows programmers to increase the robustness of their code by sprinkling it liberally with assert statements. The new assertion feature is easy to use, but any language feature, no matter how simple, can be used well or poorly. Here I'll explain how to use Java's assertion facility, and how not to misuse it.

Single sign-on is becoming an important issue for corporations and Java developers. Corporations require applications to be secure. Users demand applications to be easy to use. Usually, the more secure an application is, the more difficult it is to use. For example, users are inundated with remembering multiple logins to different systems.

The JavaBean Component Architecture provides a means to reuse software and, when combined with tool support, can dramatically increase developer productivity. This model has been realized primarily in graphical display applications with AWT and Java Swing components. Recent advances in J2ME and the release of the Real-Time Specification for Java (RTSJ) allow similar productivity gains to be achieved with real-time and embedded-hardware driver components.

The Java development and runtime environment, with its 'write once, run anywhere' paradigm, brings enormous advantages to the embedded industry. Java code is highly reliable, easily ported, and includes features such as Internet readiness, security, and the ability to download code at runtime to upgrade or extend applications.

As Java technology has matured over the last few years so have we. We've learned that building complex enterprise applications that respond to change requires more than standardized APIs and virtual machines. Fortunately, we're now starting to see the widespread adoption of best practices, patterns, and even frameworks with templates and prebuilt components. This article looks at the MVC design pattern and reviews its implementation in Struts, a presentation-tier application framework, as well as recognizing analogies of MVC to a well-formed, EJB-tier framework that Struts can be integrated with.

The J2EE platform architecture provides for the secure deployment of application components. It emphasizes the declarative approach wherein the application components' security structure, roles, access control, authentication and authorization requirements - as well as the other characteristics pertaining to transactions, persistence, and more - are expressed and managed outside the application code.

In recent months, there have been significant writings and discussions surrounding J2EE frameworks and the key benefits one provides. I will not spend time reiterating those here. The bottom line is most professionals in this space agree on one thing: application-level reuse is a good thing and the right J2EE framework can deliver just that. This article concerns itself with identifying what specific features to look for in a J2EE application framework.

E-business sites are increasingly utilizing dynamic Web pages since they enable a much wider range of interaction than static HTML pages can provide. Dynamic page generation, also known as dynamic scripting, allows a Web site to generate pages at runtime, based on various parameters.

JDJ:For the benefit of our readers, could you briefly describe your role in BEA? Dietzen: I'm the chief technology officer for the BEA e-commerce server division. As CTO I look after the technical strategy for BEA's application server products, including the WebLogic Server, WebLogic Enterprise, and Tuxedo. So I get to spend a lot of time on newer technology initiatives, such as Web Services, wireless, and J2EE-based integration. Also, I represent BEA on the Java Executive Council, which helps shape the future of Java via the Java Community Process. Finally, I drive relationships with BEA's high-level partners, OEMs, and blue-chip customers.

Dealing with dates and times is probably the most confusing aspect of Java for newbies. There are three reasons for this:

Have you ever needed to write a simple graphical user interface (GUI) but didn't have the right kind of layout manager? Do you hate to use a layout manager that takes you longer to understand than to make your GUI? If this is the case, you're probably not a big fan of the GridBagLayout manager and its complexities.

What is a facade? In software engineering it's a design pattern. One possible definition of a facade is: 'A higher-level interface that provides a unified way of accessing a subsystem and as a result makes the subsystem easier to use.'

This article presents a design approach for multitier applications implemented with Enterprise JavaBeans. These entity EJBs inherit bulk set-and-get methods from a single parent class that takes advantage of the java.lang.reflect package. This approach reduces the number of network round-trips, simplifies application maintenance, and significantly reduces the lines of code in an EJB application.

Remember the old axiom, Be careful what you ask for, you just might get it? That's what happened with the Abstract Windowing Toolkit (AWT), GUI controls, and threading. Developers were tired of always worrying about multithreaded access to GUI elements, so it sounded like a good idea to create an application framework that was always thread-safe.

Telephone access to the Web is the latest craze sweeping the dot-com landscape. Voice portals with names like BeVocal, Quack.com, Tellme, and AudioPoint are promising all callers easy access to news, traffic reports, stock quotes, and driving directions. Some of these services may flash and burn as quickly as a California brushfire, but they represent the leading edge of a much larger trend that began several decades ago and has accelerated with advances in audio- and speech-processing technologies: the convergence of voice and data networks.

JavaSoft defined the Enterprise JavaBeans specification to give Java developers a foundation for building distributed business components. EJBs are Java components that implement business logic and follow a contract designated in the EJB specification. Enterprise JavaBeans live inside an EJB container that provides a set of standard services, including transactions, persistence, security, and concurrency. This means that the application programmer is freed from developing these services from scratch.

During the past five years, application servers have emerged as a vital piece of the Web infrastructure. By providing a set of services common to all Web applications (e.g., state management, database connectivity) as well as a productive set of APIs or scripting languages, application servers have made building applications for the Web dramatically easier, not to mention more scalable and reliable.

Have you ever wondered why you should use interfaces instead of abstract classes, or vice versa? More specifically, when dealing with generalization, have you struggled with using one or the other? I'll shed some light on what can be a very confusing issue.

Benchmarking any distributed computing middleware product is a complex task. Knowing how well a distributed infrastructure will perform under heavy load with a large number of concurrently connected users is a key factor in planning a development and deployment strategy.

The Java Platform Debugger Architecture (JPDA) provides a standard set of protocols and APIs at three levels that facilitate the development of a new breed of debugging and profiling tools. The inclusion of JPDA in the Java 2 SDK enables individual developers as well as commercial vendors to find novel ways of analyzing Java applications as they run even remotely across a network.

Essential to the development of complex systems are tools that help the developer locate, analyze, and fix problems. Debuggers provide support for this by letting a developer inspect the internal state of a program at runtime, as well as suspend and resume execution statement by statement.

Over the past decade the Internet has evolved from a research project living in the realms of academia and government to a global infrastructure for electronic commerce and digital communication that has sent the stock market on a roller-coaster ride to new highs (and lows).

Conditional compilation is not available in Java - and Java's platform independence is the cited (and largely justified) reason. Nevertheless, one valuable use of conditional compilation, which is to cleanly insert debug code into applications, is thereby lost.

The J2EE architecture is a great advance for developers. Its standardized framework defines and supports a multitiered programming model, freeing application developers to concentrate on solutions.

Last month in JDJ (Vol. 6, issue 1) we looked at the advantages of downloading servlets and JavaServer Pages (JSP) from a repository, for example, the same way a browser downloads applets. We described a simple implementation of this concept based on a service servlet and a custom class loader. This tool, named JSPservlet, handled servlets and JSP packaged in JAR archives to minimize the number of connections and transfers required.

In May and July of 2000, Java Developer's Journal (Vol. 5, issues 5 and 7) ran a two-part article on how business rules can be implemented in Java. To recap, business rules are a formalized representation of the policies, practices, and procedures of an organization, describing how business should be conducted under any particular set of conditions. Business rules aren't a programming concept but rather a business concept. The business rules of an organization may be contained in policy manuals, memos to employees, unwritten 'tips and tricks' passed from employee to employee, or lines of program code spread among various applications serving different business needs.

When Sun released J2EE to capture the growing e-business market, it changed Java from a language to an enterprise platform.

Smart card, Java workstation, and cryptography: these are all growing areas of interest in the computing world. There are programmers - from novice to expert - who know each of these technologies. But as the technology world becomes more intertwined, so too do these seemingly disparate technologies. With the introduction of the Java Card it's becoming necessary for smart card developers to know Java and Java developers to know smart cards. And as more transactions are done electronically, everyone will try to find ways of applying cryptography to electronic security. The purpose of this article is to provide a sample solution that brings all three of these technologies together.