Prior to DFS, the primary solution-building, business logic-focused EMC Documentum platform API was Documentum Foundation Classes (DFC).
When I joined Documentum (now EMC) over ten years ago, DFC was under development as part of the significant 4i release (aka “Project Piper”). Back then Microsoft shipped a leading JVM and had one of the best IDEs for Java in Visual J++, according some of my then hardcore Java programming friends. The MSJVM intrinsically supported–among other “features” like delegates that led to the Java cold war (lawsuit) between Sun and Microsoft–interoperability with Microsoft’s major runtime play at that time called COM.
The aforementioned cold war led to Microsoft dropping development and support of MSJVM (and led to .NET, J# and JLCA), ending its Java support with the then-outdated 1.1.4 release from Sun. This meant that in order to support COM-based interop from Java you had to either build or buy. And a build-versus-buy decision was especially relevant to Documentum at the time given that the most widely used client/application was Desktop (aka Desktop Client, or just DTC–later called Desktop Development Kit), not to mention the MFC-based Developer Studio (later called Documentum Application Builder (DAB), which is now replaced by Composer). We opted for build, since there was no buy option available then that met our requirements, and the Documentum Java-COM Bridge (DJCB) was born and was first released with DFC 5.0.
DJCB enabled us to project DFC Java types as DFC COM types via COM type libraries and IDL. It also enabled Documentum to adopt newer JVM technology (e.g. Java 2 collections, Sun Hotspot JVM performance improvements, etc.). Furthermore, in the strong Documentum tradition of supporting existing IT infrastructure such as operating systems, relational databases and application servers, whose JVM was running became less of an issue (e.g. Sun, IBM, BEA (now Oracle), etc.).
Here is perhaps an interesting portion of the original DJCB function specification dated 9/5/2001, which I authored with Victor Spivak, describing why DJCB was pursued:
Why does Documentum need any bridge?
Documentum Foundation Classes, or DFC as it is more commonly referenced, is Documentum’s platform-independent business logic layer. A key benefit of the Java language is platform independence, or “Write Once, Run Anywhere” (i.e. anywhere that supports the Java platform); therefore, DFC is implemented in Java.
Documentum is a platform provider, and as a platform company it supports the two dominant platforms of today: Windows and Java. A significant amount of Windows development is COM-based, and from a developer’s point of view, Documentum APIs on Windows are COM interface methods, etc.
When the DFC first decided to use Java as its implementation language, the Java platform was alive and well on Windows. In fact, Microsoft provided a fairly transparent bridge between COM and Java through its Java Virtual Machine (JVM) very soon after Java’s formal introduction to the general software development community. This bridge benefited Documentum a great deal; through a single implementation with minimal wrapping, Documentum could provide a business logic layer (DFC) that was consumable on both Windows and Java environments. …
Why does Documentum need a new bridge?
The settlement of the lawsuit between Sun and Microsoft has effectively frozen Microsoft’s use of Java in Windows at version 1.1.4. For its own use, Sun has already completed its end-of-life (EOL) of 1.1.4–only 1.1.8 remains available and supported in the Java 1.1 platform. Since Microsoft’s Java-COM bridge is built into its JVM, this bridge is also frozen at version 1.1.4. However, Java hasn’t stopped growing or maturing.
The Java platform tripled in size between Java 1.1 and Java 1.2, and the Java 2 platform has continued to grow beyond version 1.2. The current release is 1.3 and version 1.4 is available today as a beta product. …
Clearly the Java platform of today is significantly different than version 1.1.4 of the Java platform.
Developers of a platform adopt the models of that platform. Java 2 offers models that are unsupported by DFC today because DFC is constrained by obsolete bridge technology. That is, Java developers using DFC may be forced to use proprietary workarounds to standard solutions that Java 2 provides (e.g. Java Collection Framework).
Java developers expect to leverage and interact with the facilities of the Java 2 platform (i.e. version 1.2 or later). Their encounter with the current DFC programming model may less than desirable as long as DFC is constrained to a much older Java platform and development model. Critical aspects of the Java platform such as security, extensibility, collections, serialization, multithreading, have undergone significant change. DFC will benefit from these changes but it must first be able to depend on more current Java environments–something it cannot do under the current Microsoft–provided bridge.
It’s not necessary to maintain a lowest common denominator approach any longer in DFC. A new bridge can and should be developed that enables DFC to leverage the Java 2 platform for its own benefit and for the benefit of all Java developers who rely on Documentum as part of their business solutions. Providing more mature facilities in DFC to Java developers should not come at the expense of COM developers [i.e. C++/”Classic VB” developers that use COM to achieve binary compatibility]. Existing DFC APIs continue to appear as COM objects with DJCB as they have with the Microsoft bridge. …
Looking at the need for a new bridge another way, Documentum’s customers as well as Documentum itself suffers from the Sun-Microsoft lawsuit and settlement. Documentum cannot afford to drop its support of COM in the business logic layer. Documentum can also not afford to hand-tie Java business logic to an obsolete version of Java. Developers approaching the Documentum platform from a Java perspective expect our Java APIs to be Java 2-like. DJCB is about healing the wounds caused by Sun and Microsoft to our developer base… DJCB maintains a COM developer’s expectations of DFC leverage, while enabling DFC to meet the expectations of Java developers leverage Documentum’s business logic layer implemented in Java.
Next: DFC PIA…