Garden of Applications

What to take away

1. 1. The Backplane is implemented as a Java singleton (Backplane.getInstance()) derived from java.awt.applet, inheriting the applet lifecycle states init, start, stop, and destroy, and chains these state changes to all loaded Standard Applications.
2. 2. Java's late-binding class loading (Class.forName() in AppManager.init()) is elevated from loading individual classes to loading entire applications at runtime, enabling the system to add or replace functionality without recompilation.
3. 3. The Interface Repository—inspired by CORBA's hierarchical namespace—maps unique string keys (typically the interface class name) to live implementation objects, allowing any application to fetch a capability via fetchInterface() without holding a direct reference to the provider.
4. 4. Bootstrap Applications are a special subclass of Standard Applications that are loaded by the Backplane during system initialization, before user-selectable applications are available, and typically have a lifespan equal to the Backplane itself.
5. 5. A mid-project requirement to change how news stories were displayed was accommodated by introducing the Interface Repository and Bootstrap Applications without modifying the Backplane, validating the pattern's core claim that the Backplane can remain stable under evolving requirements.
6. 6. The SwingDesktop implementation defaults to a 640×480 window size when ConfigurationService cannot parse width/height properties from backplane.cfg, demonstrating the Configuration Services pattern's role as a runtime-configurable alternative to compile-time constants.
7. 7. The Standard Application pattern is explicitly compared to Alexander's MAIN ENTRANCE (Pattern 110) in A Pattern Language, arguing that a known entry point (the abstract StandardApp superclass) serves the same orientation function for software maintainers as a building's entrance does for inhabitants.
8. 8. The paper raises the open hypothesis that certain Java idioms—specifically dynamic class loading and explicit lifecycle management—are universal across client-side and server-side contexts, citing the then-recently released Java Server Toolkit as suggestive parallel evidence, but does not empirically test this claim.
9. 9. A researcher replicating this architecture should implement the Backplane as a singleton that reads its list of Bootstrap Applications from a flat configuration file (backplane.cfg) parsed by a Properties object at first instantiation of ConfigurationService, then sequentially calls init() and start() on each loaded StandardApp.
10. 10. The pattern language is explicitly described as incomplete, with the author acknowledging that additional constructs that contributed to the system's success—beyond the 5 documented patterns—remain undocumented and represent unfinished work presented at PLoP-98.

Peer brief — for seminar discussion

Presented at PLoP-98 and shepherded by Kent Beck, this paper documents a pattern language of 5 interlocking patterns—Garden of Applications, Backplane, Standard Applications, Interface Repository, and Bootstrap Applications—extracted from a production Java system that delivered real-time securities prices and news headlines through a Java-enabled browser. The system was built under an explicit requirement that the final architecture was unknown at project outset, which ruled out conventional upfront master planning and motivated a framework designed for piecemeal growth in Christopher Alexander's sense. The Backplane, the paper's load-bearing construct, is implemented as a Java singleton extending java.awt.applet and exposing four lifecycle methods (init, start, stop, destroy) that it chains to every loaded Standard Application; Java's Class.forName() late-binding mechanism is promoted from class-level to application-level dynamic loading, meaning new applications can be added at runtime by updating a configuration file rather than recompiling. The Interface Repository—architecturally inspired by CORBA's naming service—maps string-keyed symbolic names to live interface implementations via registerInterface() and fetchInterface(), so that cross-application dependencies are mediated through a runtime registry rather than compile-time imports. Bootstrap Applications are a restricted subclass of Standard Applications that the Backplane loads automatically during initialization, before user-launched applications appear, and they pre-populate the Interface Repository with system-wide services. The load-bearing empirical claim is that a mid-project demand to change news-display behavior was absorbed entirely through the Interface Repository without touching the Backplane, which the paper treats as validation that the Backplane can function as a stable meta-construct even under evolving requirements. The implied prediction is that this same architecture generalizes from GUI client applications to server-side contexts, with the Java Server Toolkit cited as suggestive but unexamined evidence. An alternative design the paper could have evaluated is a straightforward publish/subscribe (observable/observer) bus—acknowledged in footnote 4 as a MESSAGE BUS pattern—which it defers to rather than replaces, leaving unresolved when the Interface Repository's pull-based lookup is preferable to event-driven notification. The most pointed pushback a critical reader would raise is the single-system evidentiary basis: the entire pattern language is abstracted from one project, and the paper offers no comparative data, no independent replication, and no failure cases, making it impossible to distinguish patterns that are genuinely generative from idioms that happened to work under one team's constraints. The paper explicitly concedes the language is incomplete and that additional constructs from the same project remain undocumented, which further limits the ability to assess whether the 5 published patterns are the causally important ones or simply the most legible ones in retrospect.

Frameworks (5)

• BACKPLANE (2)
• Design Patterns
  Gang of Four patterns book referenced for the Memento pattern used in view creation.
• GARDEN OF APPLICATIONS (1)
• INTERFACE REPOSITORY (4)
• Message Bus
  Pattern enabling backplane to alert applications of state changes via decoupled messaging rather than direct calls.

Claims (15)

• Create a backplane component in the system. This component should be primarily concerned with providing facilities which address the runtime architecture of the system. These include initialization and termination of applications and high level window management. The backplane is also an ideal place to put the interface repository. Avoid placing application or domain-specific functionality into the backplane and instead use an interface repository to support this activity.

  Prescriptive claim for the BACKPLANE pattern's responsibilities and boundaries.

• Make the components with which the user interacts standard applications which provide standard facilities and interfaces. These applications have a standard interface by which the backplane can manage their lifecycle methods. These applications can be dynamically loaded to help reduce the overall footprint of the system. Avoid having applications communicate directly with one another – use the interface repository for this purpose.

  Prescriptive claim for the STANDARD APPLICATIONS pattern.

• Create a framework onto which the application level functions can easily be deployed. This is done by splitting the entire application into two broad categories, the backplane and standard applications. Make sure to provide facilities, such as an interface repository, to reduce coupling between applications.

  Prescriptive claim summarizing the GARDEN OF APPLICATIONS pattern.

• Standard applications help a new developer to come up to speed more quickly because other developers on the project can simply say, 'Oh, yeah. Extend STANDARD APPLICATION, update this configuration file and you'll be all set to run and test your application.'

  Claim about the onboarding benefit of the Standard Application construct.

• Create an interface repository for the system and let the backplane serve as the central access point to this list of publicly accessible interfaces which is indexed by a unique name.

  Prescriptive claim for the INTERFACE REPOSITORY pattern.

• By making lifecycle management an explicit and necessary construct, we encourage developers to provide application-specific semantics for lifecycle state changes.

  Assertion that explicit lifecycle improves developer behavior and application robustness.

• Late binding increases the significance of temporal forces on the system's functionality and its corresponding ability to change its functionality at runtime.

  Claim linking late-binding to enhanced runtime adaptability.

• Systems do not necessarily require master plans in order for development to begin; with proper meta-constructs, development can proceed in organic fashion.

  Core thesis that architectural flexibility through meta-constructs enables incremental development without complete upfront design.

• Runtime architecture must be explicitly represented in code through lifecycle constructs, not just static class relationships.

  Assertion that temporal aspects of system behavior are as important as structural aspects and require first-class treatment.

• Runtime architecture matters more than static compile-time structure for systems supporting change.

Questions (2)

• How can we build systems that are easily changeable when requirements are unclear at project start?

  Central problem driving the pattern language, arising from user requirement that system design be fluid.

• How can systems accommodate change without abandoning them mid-development?

Related work— refs + corpus + external arXiv

Cited / in-corpus / arXiv badges show which signals surfaced each row. Multi-source rows weighted higher.

• Genuinely Functional User Interfaces

  in corpus
  ≈ 78%
• Theory Under Construction: Orchestrating Language Models for Research Software Where the Specification Evolves

  Nikolaj Bj\"orner Halley Young

  2026
  ≈ 77%
• A Pattern Language for Resilient Visual Agents

  Alexander Lenz, Alois Knoll Habtom Kahsay Gidey

  2026
  ≈ 76%
• Finger Exercises in Formal Concept Analysis

  in corpus

  2006
  ≈ 76%
• Bootstrap Off-policy with World Model

  Likun Wang, Xiangteng Zhang, Jiaxin Gao, Masayoshi Tomizuka, Shengbo Eben Li Guojian Zhan

  2026
  ≈ 76%
• The Root Theorem of Context Engineering

  Borja Odriozola Schick

  2026
  ≈ 76%
• Linda in context

  in corpus

  1989
  ≈ 76%
• FOLIAGE: Towards Physical Intelligence World Models Via Unbounded Surface Evolution

  Xiaoyi Liu and Hao Tang

  2025
  ≈ 76%
• Robust, Observable, and Evolvable Agentic Systems Engineering: A Principled Framework Validated via the Fairy GUI Agent

  Ruimeng Yang, Xu Han, Jiayang Niu, Mingxuan Li, Te Yang, Yongyong Lu, Xin Peng Jiazheng Sun

  2025
  ≈ 76%
• Opening the Hood of a Word Processor

  in corpus

  1984
  ≈ 76%
• SciTextures: Collecting and Connecting Visual Patterns, Models, and Code Across Science and Art

  Alona Strugatski Sagi Eppel

  2026
  ≈ 76%
• Evolutionary Ensemble of Agents

  Liu Yang Zongmin Yu

  2026
  ≈ 76%
• Improving Coherence and Persistence in Agentic AI for System Optimization

  Kimia Noorbakhsh, Mohammad Alizadeh, Hari Balakrishnan Pantea Karimi

  2026
  ≈ 75%
• An Encoding of Abstract Dialectical Frameworks into Higher-Order Logic

  Alexander Steen Antoine Martina

  2026
  ≈ 75%
• Album: executable building blocks for scientific imaging routines, from sharing to LLM-assisted orchestration

  Deborah Schmidt, Lucas Rieckert, Maximilian Otto, Kyle Harrington Jan Philipp Albrecht

  2026
  ≈ 75%
• Context Engineering: From Prompts to Corporate Multi-Agent Architecture

  Vera V. Vishnyakova

  2026
  ≈ 75%
• Sustainability and Morphogenesis: The Birth of a Living World

  in corpus

  2004
  ≈ 75%
• Control Plane as a Tool: A Scalable Design Pattern for Agentic AI Systems

  Sivasathivel Kandasamy

  2025
  ≈ 75%
• Verify Before You Fix: Agentic Execution Grounding for Trustworthy Cross-Language Code Analysis

  Jugal Gajjar

  2026
  ≈ 75%
• From Goals to Aspects, Revisited: An NFR Pattern Language for Agentic AI Systems

  Yijun Yu

  2026
  ≈ 75%
• Technological Approach to Mind Everywhere: An Experimentally-Grounded Framework for Understanding Diverse Bodies and Minds

  in corpus

  2022
  ≈ 75%
• Living Things Are Not (20th Century) Machines: Updating Mechanism Metaphors in Light of the Modern Science of Machine Behavior

  in corpus

  2021
  ≈ 74%
• Denotational Design: from meanings to programs

  in corpus

  2015
  ≈ 74%
• Cybernetic Diagrams: Design Strategies for an Open Game

  in corpus

  2014
  ≈ 74%
• Denotational design with type class morphisms (extended version)

  in corpus

  2015
  ≈ 74%
• AI: a Bridge toward Diverse Intelligence and Humanity’s Future

  in corpus

  2024
  ≈ 74%
• Technical Dimensions of Programming Systems

  in corpus

  2023
  ≈ 74%
• Topological constraints on self-organization in locally interacting systems

  in corpus

  2026
  ≈ 74%
• Harmony-Seeking Computations: a Science of Non-Classical Dynamics based on the Progressive Evolution of the Larger Whole

  in corpus

  2022
  ≈ 73%
• Generalizing frameworks for sentience beyond natural species

  in corpus
  ≈ 73%

Similar preprints — Semantic Scholar