Archive for the ‘General’ Category
[DevoxxFR2012] Manipulation of Bytecode: Let’s Democratize the Black Magics!
Lecturer
Frédéric Le Mouël holds the position of associate professor at INSA Lyon within the Telecommunications Department and CITI Lab, while also serving as a member of the INRIA Amazones research team. His academic background includes a PhD from University of Rennes 1 focused on adaptive middleware for mobile computing environments. Frederic’s research spans component-oriented architectures, service-oriented computing, and dynamic adaptation mechanisms, with particular interest in bytecode manipulation as an enabling technology for runtime adaptation. The JooFlux project, which he presents, represents a culmination of these research threads.
Abstract
Frédéric Le Mouël challenges the perception of bytecode manipulation as an esoteric practice reserved for framework authors and programming language implementers, demonstrating its practical utility across the software development spectrum from application development to system instrumentation. The presentation systematically demystifies Java bytecode and the JVM’s execution model before examining multiple manipulation tools including ASM, AspectJ, Byteman, and the innovative JooFlux framework. Through live demonstrations and architectural analyses, Le Mouël illustrates how bytecode transformation enables aspect-oriented programming, runtime monitoring, adaptive systems, and performance optimization without source code modification. The session concludes with philosophical reflections on the power and responsibility accompanying low-level JVM access.
Java Bytecode Fundamentals
Java bytecode serves as the intermediate representation executed by the JVM, compiled from Java source through javac. Le Mouël examines the stack-based execution model:
// Source
public int add(int a, int b) {
return a + b;
}
// Bytecode
0: iload_1
1: iload_2
2: iadd
3: ireturn
Each instruction operates on the operand stack, with local variables accessed through indexed loads and stores. The JVM’s verification process ensures type safety before execution.
ASM: The Foundation of Bytecode Manipulation
ASM provides a low-level API for generating and transforming class files. Le Mouël demonstrates method instrumentation:
public class AddTraceTransformer extends ClassVisitor {
public MethodVisitor visitMethod(int access, String name,
String desc, String signature, String[] exceptions) {
MethodVisitor mv = super.visitMethod(access, name, desc, signature, exceptions);
if ("process".equals(name)) {
return new AddTraceAdapter(mv);
}
return mv;
}
}
class AddTraceAdapter extends MethodVisitor {
public void visitCode() {
mv.visitCode();
mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;");
mv.visitLdcInsn("Entering method");
mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V");
}
}
This transformation inserts tracing without modifying source code.
AspectJ: High-Level AOP Through Weaving
AspectJ compiles aspects into bytecode transformations. Le Mouël shows transaction management:
@Aspect
public class TransactionAspect {
@Around("execution(* com.bank.*.*(..))")
public Object manageTransaction(ProceedingJoinPoint pjp) throws Throwable {
beginTransaction();
try {
Object result = pjp.proceed();
commitTransaction();
return result;
} catch (Throwable t) {
rollbackTransaction();
throw t;
}
}
}
The AspectJ weaver transforms target classes at compile-time or load-time.
Byteman: Runtime Rule Injection
Byteman enables dynamic rule injection into running JVMs:
RULE Trace method entry
CLASS com.example.Service
METHOD process
AT ENTRY
IF true
DO traceln("Entering process")
ENDRULE
Le Mouël demonstrates hot-patching production systems for debugging.
JooFlux: Research Framework for Dynamic Adaptation
JooFlux introduces a registry-based approach to bytecode manipulation:
JooFlux.register(new Interceptor() {
public void intercept(Call call) {
if (call.getMethodName().equals("process")) {
System.out.println("Intercepted: " + call.getArguments());
call.proceed();
}
}
});
The framework maintains original bytecode for potential restoration.
Links:
[DevoxxBE2012] Putting Kotlin to the Test
During DevoxxBE2012, Hadi Hariri, a developer and technical evangelist at JetBrains, presented an in-depth evaluation of Kotlin, a then-emerging programming language designed by his company. Hadi, with his background in software architecture and web development, aimed to assess whether Kotlin could address common pitfalls in existing languages while serving as a versatile tool for various development needs. He began by providing context on Kotlin’s origins, noting its static typing, object-oriented nature, and targets for JVM bytecode and JavaScript compilation. Licensed under Apache 2.0, it was at milestone M3, with expectations for further releases leading to beta.
Hadi explained the motivation behind Kotlin: after years of building IDEs in Java, JetBrains sought a more efficient alternative without the complexities of languages like Scala. He highlighted Kotlin’s focus on practicality, aiming to reduce boilerplate and enhance productivity. Through live coding, Hadi demonstrated building a real-world application, showcasing how Kotlin simplifies syntax and integrates seamlessly with Java.
One key aspect was Kotlin’s concise class definitions, where properties and constructors merge into a single line, eliminating redundant getters and setters. Hadi illustrated this with examples, contrasting it with verbose Java equivalents. He also touched on null safety, where the language enforces checks to prevent null pointer exceptions, a frequent issue in other systems.
As the session progressed, Hadi explored functional programming elements, such as higher-order functions and lambdas, which allow for expressive code without excessive ceremony. He built components of an application, like data models and services, to test interoperability and performance.
Syntax Innovations and Productivity Gains
Hadi delved into Kotlin’s syntax, emphasizing features like extension functions that add methods to existing classes without inheritance. This promotes cleaner code and reusability. He showed how to extend standard library classes, making operations more intuitive.
Data classes were another highlight, automatically providing equals, hashCode, and toString methods, ideal for immutable objects. Hadi used these in his demo app to handle entities efficiently.
Pattern matching via ‘when’ expressions offered a more powerful alternative to switch statements, supporting complex conditions. Hadi integrated this into control flows, demonstrating reduced branching logic.
Smart casts automatically handle type checks, minimizing explicit casts. In his application, this streamlined interactions with mixed-type collections.
Interoperability and Platform Targets
A core strength, as Hadi pointed out, is Kotlin’s full compatibility with Java. Code can call Java libraries directly, and vice versa, facilitating gradual adoption. He compiled mixed projects, showing no performance overhead.
Targeting JavaScript, Kotlin compiles to efficient code for web fronts, sharing logic between server and client. Hadi previewed this, noting potential for unified development stacks.
He addressed modules and versioning, still in progress, but promising better organization than Java packages.
Functional and Advanced Constructs
Hadi introduced traits, similar to interfaces but with implementations, enabling mixin-like behavior. He used them to compose behaviors in his app.
Delegated properties handled lazy initialization and observables, useful for UI bindings or caching.
Coroutines, though nascent, hinted at simplified asynchronous programming.
In Q&A, Hadi clarified comparisons to Ceylon and Scala, noting Kotlin’s balance of comprehensibility and power. He discussed potential .NET targeting, driven by demand.
Real-World Application Demo
Throughout, Hadi built a sample app, testing features in context. He covered error handling, collections, and concurrency, proving Kotlin’s robustness.
He encouraged trying Kotlin via IntelliJ’s community edition, which supports it natively.
Hadi’s presentation positioned Kotlin as a promising contender, fixing expensive language flaws while maintaining industrial applicability.
Links:
Maven: How to use jars in a lib/ folder?
Case
I have to work on an “old-school” project: without Maven (and even without integration within Eclipse). The JARs depended on by the application are located in a lib/ folder. Besides, I cannot add JARs to company repository.
How to integrate Maven with this lib/ folder?
Solution
First of all, you have to enable the support of Maven within IntelliJ IDEA: select the project > right click > add framework support > select Maven.
Create a pom.xml and complete the main information.
Identify the JARs which are relatively common (eg those available in http://repo1.maven.org/maven2/), and add them as dependencies.
Now, you still have to deal with “uncommon” JARs
Quick and (very) dirty
The quickest way is to add the JARs as dependencies, declared with scope system, eg:
[xml]<dependency>
<groupId>unknownGroupId</groupId>
<artifactId>someArtifactId</artifactId>
<version>someVersion</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/foo.jar</systemPath>
</dependency>[/xml]
The main drawback of this dirty solution is that when you generate your archive, the JARs depended on with scope system will not be exported… Quiet a limitation, isn’t it?
(A bit) Slower and (far) cleaner
You have to declare a “remote repository”, of which URL is local, such as:
[xml]<repository>
<id>pseudoRemoteRepo</id>
<releases>
<enabled>true</enabled>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<url>file://${project.basedir}/lib</url>
</repository>[/xml]
Then, declare the dependencies like:
[xml]<dependency>
<groupId>UNKNOWN</groupId>
<artifactId>foo</artifactId>
<version>UNKNOWN</version>
</dependency>[/xml]
Move and/or rename the JARs, for instance from lib/foo.jar folder to the actual one, such as lib/UNKNOWN/foo/foo-UNKNOWN.jar.
Now it should be OK ;-).
In my case I prefered to add Maven Assembly plugin with the goal jar-with-dependencies, to be sure to build a unique JAR with complete exploded dependencies.
[DevoxxFR2012] Nagios checks via NRPE
package “nagios-nrpe-server”
“`
He demonstrates real-time dashboards that correlate application metrics with infrastructure health, enabling rapid incident response and informed scaling decisions.
Economic and Organizational Impact: Beyond Technical Excellence
Bertrand Paquet concludes with a quantitative analysis of the pipeline’s impact: deployment frequency increased from weekly to multiple times daily, mean time to recovery decreased from hours to minutes, and infrastructure costs became predictable and scalable. He argues that these technical achievements enable organizational agility—new features can be tested in production with real users within hours of conception, creating tight feedback loops that drive product excellence.
Links:
[DevoxxFR2012] Update user subscription status
end
end
“`
Roux advocates testing pricing models through A/B experiments on payment pages, measuring conversion rates across different tiers. He discusses freemium approaches where core functionality remains free while premium features drive revenue, using analytics to identify which capabilities users value sufficiently to pay for.
Cultural Implications: Democratizing Innovation Through Methodological Discipline
Camille Roux concludes with a broader reflection on how these practices fundamentally democratize technological innovation. By reducing the barrier to entry from months of development to days of validation and prototyping, the methodology empowers a wider spectrum of creators—solo developers, domain experts without coding expertise, and intrapreneurs within large organizations—to test ideas systematically. He argues that this shift represents not merely a technical evolution but a cultural transformation, where failure becomes inexpensive learning rather than career-ending catastrophe, and where success emerges from disciplined experimentation rather than visionary genius.
Links:
[DevoxxBE2012] First Steps with Scala (Part 1/2)
In an engaging session, Dick Wall and Bill Venners, co-founders of Escalate Software and prominent figures in the Scala community, introduced newcomers to the Scala programming language. Dick, known for his JavaPosse involvement, and Bill, president of Artima and author of key Java texts, adapted their training curriculum to cover foundational elements. Their approach fused object-oriented and functional paradigms, emphasizing Scala’s blend of familiarity and innovation.
They commenced with the Scala REPL, a tool they use daily for experimentation. This interactive shell allows immediate code execution, inferring types and storing results for reuse, making it invaluable even for Java developers exploring libraries.
Dick and Holly—wait, Dick and Bill—highlighted Scala’s strong typing with inference, reducing boilerplate while maintaining safety. They demonstrated basic operations, showing how everything integrates into a unified hierarchy, unlike Java’s primitives and references.
Defining Variables and Immutability
Transitioning to variables, Dick and Bill distinguished between vals (immutable) and vars (mutable), promoting vals for reliability. This design choice encourages constant use without extra syntax, contrasting Java’s final keyword. They illustrated reassignment errors, noting REPL’s scoping allows redefinitions, mimicking nested blocks.
Type specifications, optional due to inference, follow names with colons, inverting Java’s order for natural flow. Examples showed string inferences and explicit declarations, underscoring flexibility.
They addressed mutability choices, advising private volatile vars for necessary changes, or mutable objects within immutable structures, depending on context.
Control Structures and Expressions
Dick and Bill explored control structures, revealing Scala’s expression-oriented nature. If statements return values, enabling concise assignments without ternaries. While loops, though imperative, yield Unit, encouraging functional alternatives.
For comprehensions, powerful for iteration, support guards and yields, transforming collections declaratively. They demonstrated filtering even numbers or yielding transformed lists, highlighting pattern matching integration.
Try-catch blocks, also expressions, handle exceptions functionally, with finally clauses for cleanup. This uniformity simplifies code, treating controls as value producers.
Functions and Closures
Delving into functions, they defined them as objects, enabling higher-order usage. Simple defs showed parameter typing and inference, with return types often omitted.
Function literals, akin to lambdas, capture environments as closures, allowing deferred execution. Examples illustrated anonymous functions for mapping or filtering, emphasizing Scala’s functional leanings.
They introduced by-name parameters for lazy evaluation, useful in custom controls like loops, mimicking built-in syntax without special privileges.
Collections and Functional Programming
Scala collections, immutable by default, support transformations via methods like map and filter. Dick and Bill showcased creating lists, accessing elements, and applying operations, yielding new collections without mutation.
They contrasted mutable variants, advising caution for concurrency. For comprehensions over collections generate new ones, combining iteration with functional purity.
Approaching functional style, they encouraged avoiding side effects, using recursion or folds for aggregations, fostering predictable code.
Advanced Basics and Q&A Insights
In Q&A, they addressed optimizations: Scala uses primitives internally, with @specialized for generics avoiding boxing. Profiling mirrors Java tools, with quirks in coverage.
Dick and Bill wrapped by previewing afternoon labs on Scala Koans, urging practice. Their session laid a solid groundwork, blending theory with practical demos, preparing attendees for Scala’s expressive power.
Links:
[DevoxxFR2012] Proud to Be a Developer?
Lecturer
Pierre Pezziardi has built a career as an entrepreneur and innovator in technology and finance, co-founding OCTO Technology and the Université du SI, as well as launching Octopus Microfinance and NotreBanque. His work promotes “convivial informatics”—systems that break down organizational silos, empower individuals, and support self-organizing teams. In 2005, Pierre initiated Octopus, an open-source platform for microfinance that fosters global collaboration on lean and agile methods to improve financial access for the underprivileged. He contributed to BabyLoan, France’s first peer-to-peer microcredit operator. From 2010, as CIO at Bred Banque Populaire, he applied lean techniques to banking. Since 2011, Pierre has led NotreBanque, developing affordable, transparent community financial tools.
Abstract
Pierre Pezziardi probes the role of developers in contemporary enterprises, questioning whether the profession garners the respect it deserves amid perceptions of high costs and limited value. He traces the historical evolution from artisanal coding to industrialized processes, critiquing how this shift has diminished developer autonomy and innovation. Through analogies to manufacturing and personal anecdotes, Pezziardi advocates for lean principles, self-organization, and cultural shifts to restore pride in development. The presentation analyzes systemic issues like productivity stagnation and organizational silos, proposing methodologies that empower developers as key innovators in business success.
The Developer’s Image: Perceptions and Realities in Enterprise
Pierre Pezziardi opens by addressing the awkwardness developers often feel when describing their profession, noting the common reaction of polite disinterest or skepticism from non-technical interlocutors. He posits that this stems from informatics’ reputation as expensive, delayed, and often unhelpful in real business contexts. Pezziardi argues this image is not unfounded, rooted in double exhaustion: declining productivity in large systems and outdated organizational models ill-suited to modern technology.
He explains productivity stagnation: marginal costs for new features rise due to legacy complexity, while organizational exhaustion manifests in siloed structures that hinder collaboration. Pezziardi draws historical parallels to the industrial revolution, where artisanal crafts gave way to assembly lines, similarly in software where developers became cogs in bureaucratic machines.
Pezziardi’s methodology involves reflective questioning: why do developers hesitate to claim their role? He suggests it’s because enterprises view informatics as a cost center rather than a value creator, leading to undervaluation.
Historical Evolution: From Artisanal to Industrialized Development
Pezziardi traces software’s trajectory from the 1960s, when programmers crafted bespoke solutions on punch cards, to today’s industrialized processes. He critiques the “software factory” model, where specialization fragments work—analysts specify, coders implement, testers verify—mirroring Taylorist principles.
This fragmentation, Pezziardi analyzes, breeds inefficiency: specifications become outdated, leading to rework and delays. He contrasts this with lean manufacturing’s origins in Toyota, where empowered workers halt lines to fix issues, fostering continuous improvement.
Pezziardi’s personal anecdote from banking illustrates: implementing lean reduced delivery times from months to weeks by involving developers in business decisions, eliminating wasteful handoffs.
Implications: traditional models stifle innovation; lean empowers developers as problem-solvers, aligning with agile’s emphasis on cross-functional teams.
Lean Principles: Empowering Developers Through Autonomy and Collaboration
Pezziardi advocates lean as a remedy, rooted in eliminating waste (muda) and respecting people. He details principles like just-in-time production and jidoka (automation with human intelligence), translating to software as iterative development and automated testing.
He analyzes waste types: overproduction (unused features), waiting (delays in reviews), defects (bugs). Pezziardi proposes solutions: small batches, continuous integration, pair programming.
Pezziardi stresses cultural shifts: from hierarchical control to self-organization, where teams pull work and collaborate. He cites Octopus Microfinance as an example, where open-source contributions cultivate global knowledge sharing.
Methodologically, Pezziardi encourages daily practices: developers engaging marketers or accountants to understand needs, fostering empathy and efficiency.
Cultural and Organizational Shifts: Fostering Pride in Development
Pezziardi examines why developers feel undervalued: siloed roles limit impact, bureaucratic processes disconnect from users. He proposes redefining the developer as a cultivator of value, integrating business acumen with technical skill.
He analyzes geek culture’s potential: collaborative, innovative, yet often isolated. Pezziardi urges exemplifying values like humility, continuous learning, and cross-disciplinary dialogue.
Pezziardi’s narrative methodology—using humor, analogies (e.g., assembly lines)—engages to inspire change. Implications: enterprises adopting lean unlock productivity; developers gain fulfillment, transforming informatics from cost to asset.
Conclusion: Reclaiming Pride Through Convivial Informatics
Pezziardi concludes that technology outpaces culture; developers must lead by promoting convivial systems—tools empowering users, breaking silos. By embodying lean values, developers can reclaim pride, positioning themselves as pivotal to organizational success.
Links:
[DevoxxFR2012] Cloud Foundry manifest (manifest.yml)
applications:
– name: sample-java-app
memory: 512M
instances: 2
path: target/sample-java-app.war
services:
mysql-service:
type: mysql
## Reimagining Software Craftsmanship in the Cloud Era
The cloud era reshapes not only infrastructure but the software development lifecycle. Patrick likens modern software to the fashion industry: iPhone apps follow seasonal cycles—Angry Birds Space, Angry Birds Seasons—demanding rapid iteration and monetization within shrinking windows. A/B testing, a data-driven methodology, becomes essential for optimizing user engagement. In enterprises, “situational applications” proliferate—short-lived tools like the Devoxx website or a two-week Cloud Foundry tour prototype—contrasting with decade-long monoliths.
Kent Beck’s “Software G-forces” framework, presented a year prior, adapts agile practices to deployment cadence. Annual releases tolerate heavyweight processes; hourly deployments demand extreme lightness. Cloud’s primary business value, Patrick asserts, lies in liberating developers from infrastructure toil, enabling focus on domain logic and user value. He references Greg Vanback’s domain modeling talk, advocating domain-specific languages (DSLs) to encode business rules over plumbing.
Lock-in remains the cloud’s Achilles’ heel, evocatively termed the “Hotel California syndrome” by VMware CEO Paul Maritz: entry is easy, exit impossible. Cloud Foundry counters this through open-source neutrality, allowing code to run identically on-premises or across providers. Patrick’s transition from Google to VMware was motivated by this philosophy—empowering developers to own their destiny.
// Spring Boot on Cloud Foundry (conceptual)
@SpringBootApplication
public class DemoApplication {
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
}
“`
Forecasting the Developer’s Future: Lessons and Imperatives
Patrick predicts software will increasingly resemble fashion, prioritizing design excellence and tool versatility. Java developers must transcend the “hammer complex”—viewing every problem as a nail for their familiar tool—and embrace polyglot programming to unlock novel solutions. Obsolete concepts like First Normal Form or Waterfall methodologies must be unlearned; agile practices, API design, A/B testing, and framework diversity must be mastered.
The fictional George’s redemption arc offers a blueprint. After months of unemployment in 2010, a Paris JUG meetup rekindles his passion. Surrounded by peers wielding Scala, Node.js, HTML5, and agile since 2007, he invests in an iPad, iPhone, and MacBook Pro. Joining the Cantine coworking space, he codes daily with unit tests, devours Reid Hoffman’s The Start-Up of You and Gerald Weinberg’s The Psychology of Computer Programming, and treats his career as a startup. Contributing to open-source, he pushes code via Git, Jenkins, and VMC. His mobile app scales to 10 million users on cloud infrastructure he never manages, eventually acquired (perhaps by Viadeo in France). Abandoning golf for samba in Brazil, George embodies reinvention.
Conclusion: Authoring the Developer’s Comedy
Technological revolutions, like cinema’s sound era, compel adaptation or obsolescence. Developers must shed complexity worship, embrace platform abstraction, and center users through agile, data-driven practices. Open-source PaaS like Cloud Foundry democratizes innovation, mitigating lock-in and accelerating community contributions. Patrick’s narrative—part memoir, part manifesto—urges developers to engage communities, master emerging paradigms, and view their careers as entrepreneurial ventures. In this American comedy, the developer’s story ends triumphantly, provided they seize authorship of their destiny.
Links:
[DevoxxFR2012] Portrait of the Developer as “The Artist”
Lecturer
Patrick Chanezon serves as a principal advocate for developer ecosystems and cloud innovation. At the time of this presentation, he managed the Client and Cloud Advocacy team at VMware, following a distinguished tenure at Google where he shaped developer relations from 2005 onward. His responsibilities encompassed fostering communities around OpenSocial, Google Checkout, the AdWords API, Google Web Toolkit (GWT), and Google App Engine. Prior to Google, Patrick contributed significantly to Sun Microsystems, AOL, and Netscape, focusing on portals, blogging platforms, and RSS syndication technologies. He co-founded the ROME open-source Java project for feed parsing and established the Open Source Get Together Paris (OSSGTP) group, which laid foundational groundwork for France’s vibrant Java community. His early career included consulting roles at Accenture and Netscape in France, where he maintained legacy COBOL systems before embracing the web’s transformative potential and relocating to California. Patrick’s passion for open standards, community building, and technical evangelism has positioned him as a bridge between enterprise constraints and innovative platforms.
Abstract
In a compelling analogy drawn from Michel Hazanavicius’s Oscar-winning film The Artist, Patrick Chanezon explores the seismic shifts reshaping software development through the lens of three technologies that reached critical mass between 2010 and 2012: mobile computing, HTML5-enabled browsers, and cloud platforms. He traces the developer’s journey from the rigid, complexity-laden enterprise Java environments of the early 2000s to the agile, platform-agnostic, user-focused paradigms of the cloud era. Through personal anecdotes, industry case studies, and technical deep dives, Patrick dissects outdated practices, champions open-source PaaS solutions like Cloud Foundry, and outlines actionable strategies for developers to adapt, innovate, and thrive. The presentation culminates in a vision of the developer as an entrepreneurial protagonist, scripting their own triumphant narrative in a rapidly evolving technological landscape.
The Silent Era of Enterprise Java: A Developer’s Origin Story
Patrick Chanezon opens his narrative in the Hollywood of 1927, as depicted in The Artist, where George Valentin, a silent film star, faces professional obsolescence with the advent of talkies. This cinematic transition serves as a powerful metaphor for the developer’s confrontation with disruptive technologies. Just as Valentin must adapt his craft or fade into irrelevance, developers in 2012 stand at a crossroads defined by mobile, HTML5, and cloud computing—innovations that, having achieved critical mass over the preceding two years, demand profound professional reinvention.
To ground this analogy, Patrick recounts his own professional odyssey, beginning in the early 2000s at Accenture in France. There, he maintained COBOL-based billing systems for France Télécom, a role he humorously notes likely left traces in millions of French phone bills. The web’s explosive growth in the late 1990s prompted his move to Netscape, where he witnessed the internet’s democratization firsthand. A subsequent relocation to California with his wife placed him at the epicenter of technological innovation, first at Sun Microsystems and then at Google, where he spent six years building developer ecosystems around APIs and Google App Engine. His most recent transition, in September 2011, brought him to VMware to lead advocacy for Cloud Foundry—an open-source Platform-as-a-Service (PaaS) launched by former Google engineers.
This personal trajectory mirrors the broader evolution of the developer archetype, embodied in the fictional “George.” In 2002 Paris, George toiled within SSII (Sociétés de Services en Ingénierie Informatique) firms, crafting enterprise Java applications using servlets, Enterprise JavaBeans (EJB), WebLogic clustering, Java Message Service (JMS), Oracle databases, and JavaServer Faces (JSF). Projects like the infamous “Azerti”—a three-year endeavor whose purpose even George couldn’t fully articulate—exemplified the era’s hallmarks: convoluted workflows, unusable interfaces, and code so complex that only its author could navigate it. Despite these flaws, deployment was celebrated by IT directors, and George, reveling in his indispensability, was promoted to project manager. Patrick critiques this “wallowing in complexity,” a phrase echoing Pierre Pezziardi’s earlier Devoxx talk, as a systemic failure to prioritize user experience.
Promotion, however, severed George from coding. Confined to writing specifications in windowed offices, he rarely engaged with users, whom he dismissed as perpetually dissatisfied. By 2004, attending OSSGTP meetings exposed him to agile methodologies and open-source frameworks—Groovy, REST, AspectJ, Hibernate, Spring—but these innovations felt irrelevant to his WebLogic-centric world. Agile coaches courted his budget, yet George prioritized golf and executive schmoozing over technical growth. Within two years, he hadn’t touched code, managing a 30-developer team and launching a misconceived three-year “agile plan” predicated on exhaustive documentation rather than iterative delivery. This stagnation, Patrick argues, parallels Valentin’s refusal to embrace sound, risking professional irrelevance.
The Talkies Arrive: Mobile, HTML5, and Cloud as Disruptive Forces
The presentation shifts to the technological “talkies” upending development. Mobile computing, catalyzed by Apple’s App Store in 2008 and Android’s open ecosystem, has made smartphones ubiquitous, outshipping PCs and enabling constant connectivity. HTML5, maturing as a W3C standard, unifies web development by replacing plugin-dependent rich interfaces (Flash, Silverlight) with native browser capabilities—canvas, WebSockets, local storage, and offline support. Cloud platforms abstract infrastructure, allowing developers to deploy applications without managing servers, storage, or networking.
Patrick illustrates cloud’s transformative potential through a real-world incident: Amazon Web Services’ 2011 outage, which crippled startups like Reddit, Foursquare, and Quora. Rather than indicting cloud reliability, he praises the resilience of survivors who architected distributed systems atop Amazon’s IaaS. These efforts birthed PaaS—a higher abstraction layer managing applications and services rather than virtual machines. Google App Engine, launched in 2008, initially faced ridicule for its platform-centric vision, yet within four years, the industry converged on PaaS as the developer’s future.
Competitive offerings proliferated: Salesforce acquired Heroku for its Ruby focus; CloudBees emphasized continuous integration; Amazon introduced Elastic Beanstalk; Microsoft pushed Azure; and VMware launched Cloud Foundry. Enterprises, wary of vendor lock-in and desiring hybrid cloud capabilities, gravitated toward open-source solutions. Cloud Foundry, Apache-licensed and multilingual (natively supporting Java, Scala, Ruby, Node.js; community extensions adding Python, PHP, .NET), emerged as the “Linux of the cloud.” It ships with MySQL and PostgreSQL, allows arbitrary service binding, and operates multicloud via public providers (vmwarecloudfoundry.com, AppFog) or private deployments. The BOSH tool, open-sourced in 2012, simplifies cluster management across Amazon, OpenStack, or vSphere.
Patrick contrasts proprietary lock-in with open-source empowerment through a striking example. A Google App Engine bug requesting PHP support languished for three years with over 1,000 comments, ultimately rejected. In contrast, two weeks after Cloud Foundry’s 2011 launch, a developer submitted a pull request adding PHP, immediately benefiting the ecosystem. Community contributions further extended support to Smalltalk, Erlang, and Haskell, demonstrating open-source velocity.
“`
[DevoxxBE2012] Building Modular Applications with Enterprise OSGi
At DevoxxBE2012, Tim Ward and Holly Cummins, both seasoned experts in OSGi and enterprise technologies, delivered a comprehensive exploration into leveraging Enterprise OSGi for constructing modular applications. Tim, affiliated with Paremus and a key contributor to Apache Aries, alongside Holly from IBM, who focuses on WebSphere and performance tooling, guided attendees through the intricacies of transforming traditional Java EE setups into dynamic, OSGi-based systems. Their session bridged familiar concepts like WAR files and dependency injection with OSGi’s modularity, addressing common pain points in class path management.
They initiated the discussion by outlining Enterprise OSGi’s origins and relevance. Emerging in 2010, this specification enhances OSGi’s core, which has powered embedded systems and IDEs like Eclipse for over a decade, to better suit server-side enterprise needs. Tim and Holly emphasized how it integrates seamlessly with application servers, enabling features such as web applications, database interactions, and transaction management within an OSGi framework.
A key theme was the modularity crisis in large Java EE projects. They illustrated how sprawling WAR files, often exceeding server sizes like Tomcat’s 7MB core, accumulate unnecessary libraries, leading to class path hell. By contrasting tangled dependency graphs with OSGi’s structured approach, they demonstrated how explicit module definitions simplify maintenance and foster cleaner architectures.
Embracing OSGi Modularity Basics
Delving deeper, Tim and Holly explained OSGi’s bundle model, where each bundle—a JAR with added metadata—declares imports and exports via manifests. This enforces visibility rules, preventing accidental dependencies and promoting intentional design. They highlighted how bundles resolve dynamically, allowing runtime adaptability without redeployments.
The duo addressed common misconceptions, asserting that OSGi simplifies both complex and straightforward tasks. For instance, they showcased how dependency injection via Blueprint or Spring works effortlessly in OSGi, maintaining developer familiarity while adding modularity benefits.
They also touched on third-party library integration, noting challenges with non-OSGi JARs but solutions through tools that convert them into bundles. This ensures compatibility, reducing the bloat from redundant inclusions like JavaMail APIs.
Transitioning from WAR to WAB
A pivotal segment focused on evolving WAR files into Web Application Bundles (WABs). Tim and Holly demonstrated this migration, starting with a standard WAR and incorporating OSGi manifests to define it as a bundle. This shift enables deployment in OSGi containers like Apache Karaf or WebSphere Liberty, preserving servlet functionality while gaining modularity.
They illustrated error handling advantages: OSGi fails fast on missing dependencies, unlike runtime surprises in traditional setups. Through live examples, they showed bundles starting only when requirements are met, enhancing reliability.
Furthermore, they explored dynamism, where services can be added or removed at runtime, updating applications without downtime. This transparency in remoting and service interactions aligns with Java EE goals but executes more fluidly in OSGi.
Handling Dependencies and Repositories
Tim and Holly then examined dependency management, advocating explicit declarations to avoid hidden assumptions. They introduced bundle repositories, akin to Maven but tailored for OSGi, which automatically provision required bundles. This centralizes library control, aiding compliance in regulated environments.
In demonstrations, they deployed applications across servers like Liberty and Karaf, resolving dependencies on-the-fly. For instance, adding Joda Time via a repository revived a stalled bundle, showcasing practical modularity.
They stressed architectural enforcement: OSGi’s rules prevent poor practices, but good design remains essential. Tools like Eclipse plugins aid in visualizing and managing these structures.
Demonstrating Dynamism and Best Practices
The session culminated in hands-on demos, where a simple web app evolved into a dynamic OSGi system. Starting with a basic servlet, they integrated services for runtime changes, like toggling UI elements without restarts.
Tim and Holly concluded by reinforcing OSGi’s power in enforcing scalable, maintainable systems. They recommended resources, including their book “Enterprise OSGi in Action,” for further learning. Their presentation underscored how Enterprise OSGi not only resolves class path issues but elevates enterprise development to new levels of flexibility and efficiency.