http://www.javageeks.com/Papers/index.html Technical papers on Java and related topics en http://www.javageeks.com/Papers/BootClasspath/index.html Many Java programmers don't realize it, but the Java Runtime Environment is an amazingly configurable environment-so much about the Java execution environment can be controlled via options either on the command-line or through the JNI Invocation interface. One such option is the ability to define the location of the Java "bootstrap" classes-java.lang.Object, java.lang.Exception, and so forth-to come from someplace other than the ubiquitous "rt.jar" file in the "jre/lib" directory. In fact, we can use this non-standard JVM option to subvert the Java environment in many powerful ways, giving Java programmers a tremendous amount of power over their environment. But with power comes complexity, and this is no exception: it's powerful, but only if you're willing to accept the risks that go along with it. http://www.javageeks.com/Papers/ClassForName/index.html Dynamic loading of Java classes at runtime provides tremendous flexibility in the development of enterprise systems. It provides for the basis of "application servers", and allows even simpler, lighter-weight systems to accomplish some of the same ends. Within Java, dynamic loading is typically achieved by calling the forName method on the class java.lang.Class; however, when Class.forName is naively called from within an Extension, strange errors can occur. This paper describes why those errors occur, and how Java2 provides two facilities, one a modification to the forName syntax, and the other, called the "Thread context ClassLoader", to avoid them. This paper assumes you are passingly familiar with Java Reflection, and have at least a general idea of what Java ClassLoaders are and how they are used within Java code. http://www.javageeks.com/Papers/DocBookPapers/index.html After having written a number of white papers using my own XML format, transformed to PDF using XSLT to XSL:FO and the Apache FOP engine to turn the FO into a PDF file, I've come to recognize the love and beauty that is DocBook. This paper, intended as a follow-up to my earlier paper entitled "X-Power", describes the setup I'm currently using to write papers in DocBook, including some of the pain and heartache I've wrestled with getting this far. http://www.javageeks.com/Papers/FindingLoadedClasses/index.html Understanding what version of your code is executing in production can be the difference between a solved bug and an embarrassing admission of ignorance. Too many times developers are caught up defending code that isn't properly migrated out to Production or a customer's machine. In some extreme cases, developers (and/or tech support staff) are expected to support code on client machines with no idea of precisely what version of the code is running there. Add to this mess the usual variety of patches, minor version releases and daily builds, and you have a recipe for complete disaster, both from a personal and professional standpoint. One of the common means to address this problem, coming to us from the C/C++ world, is to embed a string in a compiled object file, which then gets loaded into the compiled executable. "In the field", developers and/or tech support staff can run a utility (usually the Unix "strings" command or some variant thereof) to see the exact versions of each .C/.CPP file used to build the code the customer is currently running. Unfortunately, because Java doesn't support static linking, the same approach doesn't work for us; however, we can adapt it (through one of two ways) to provide much the same level of support. http://www.javageeks.com/Papers/JavaPolicy/index.html Java 2's security system is a complex, pluggable architecture that allows for Java programmers to participate in the default process, or to replace the java.policy-based implementation altogether in favor of something else. In fact, Sun favors this latter approach, urging developers to implement a customized Policy implementation more suitable to their business' needs. In this paper, we will examine the details of how a new Policy implementation is built, and provide readers with the knowledge necessary to "roll your own" Java Security Policy implementations. This paper assumes you are familiar, at least in concept, with some of the Java2 Security architecture. http://www.javageeks.com/Papers/JavaStatics/index.html Java programmers, like C++ programmers, expect that static instances (namely, static fields) are unique within the JVM. While true for most Java code, the real story behind the "static" keyword is more complex than that. What's worse, it can rear its head to bite Java programmers in very sensitive areas in complex environments like a servlet container or EJB server. http://www.javageeks.com/Papers/MultipleJavaHomes/index.html With the exponential growth of Java as a server-side development language has come an equivablent exponential growth in Java development tools, environments, frameworks, and extensions. Unfortunately, not all of these tools play nicely together under the same Java VM installation. Some require a Servlet 2.1-compliant environment, some require 2.2. Some only run under JDK 1.2 or above, some under JDK 1.1 (and no higher). Some require the "com.sun.swing" packages from pre-Swing 1.0 days, others require the "javax.swing" package names. Worse yet, this problem can be found even within the corporate enterprise, as systems developed using Java from just six months ago may suddenly "not work" due to the installation of some Java Extension required by a new (seemingly unrelated) application release. This can complicate deployment of Java applications across the corporation, and lead customers to wonder precisely why, five years after the start of the infamous "Installing-this-app-breaks-my-system" woes began with Microsoft's DLL schemes, we still haven't progressed much beyond that. (In fact, the new .NET initiative actually seeks to solve the infamous "DLL-Hell" problem just described.) This paper describes how to configure a Java installation such that a given application receives its own, private, JRE, allowing multiple Java environments to coexist without driving customers (or system administrators) insane. http://www.javageeks.com/Papers/PapersXSLFO/index.html Having authored a number of papers, I've begun to run into the pain and agony of having to write while fighting with my chosen composition environment (that is, MSWord) and how to format things. For example, getting fonts and paragraph settings configured just the way I like them, standardizing on heading titles, and so on. I realize that I probably don't use the tool (again, MSWord) to a fraction of its complete capability, but I face a difficult choice: learn the tool in order to master it, and consume valuable time I could be writing, or simply live with the shortcomings of my ignorance and keep focused on the technologies I care about. Fortunately, another solution presented itself in the form of a tool written by DevelopMentor for use in its internal projects. Conceptually, it's a simple idea--capture all content in XML, then render it into the medium desired (Word, PowerPoint, LaTEX, and so on) via tools. I was fortunate enough to be one of the early adopters, and was so enamored of the system that I immediately set out to see if I could replicate success by adopting something similar for my own use in writing papers. http://www.javageeks.com/Papers/RollYourOwnJava/index.html The Java launcher (known to most programmers by its informal name, "java.exe") is a standard tool used to bootstrap the Java Virtual Machine into a native operating system process and launch the main method of a given class. This launcher is responsible for several features of Java, including the "-jar" option used to execute a .jar file directly, obtain the classpath setting for the VM from the CLASSPATH environment variable, and set several working parameters for the VM such as starting heap size and maximum heap size, among others. http://www.javageeks.com/Papers/SelfModifyingWebsites/index.html Within the vast realm of Computer Science, one truism has held across all languages and environments: "There is no problem that cannot be solved by adding another layer of indirection." Within the dynamic web-page environment, this can be realized by creating dynamic pages that in turn generate other pages, based on user actions, for the user to then view and use. This paper discusses how it can be done in the Java Servlets/JSP environment, and shows code from a working JSP site. http://www.javageeks.com/Papers/SerializableAdapter/index.html With the advent of the 2.2 Servlet Spec, and the new requirement that all objects placed into a Session be Serializable, servlet developers (among others--it's not just a Servlet issue) are staring down a dilemma: certain objects, like JDBC Connections, are natural things to want to store in a container that may be Serialized, but storing a non-Serializable object in a container or object that's about to be Serialized is a recipe for disaster.