Objectives

Ever wondered how to peer under the hood?

Ever wondered what to do once you did?

Ever wondered if you could...

think out loud! try to stump me! I may not be able to write the code in the time allotted, but I'll bet you it can be done, given enough time (and money!)

Concepts

The JDK is amazingly configurable

at almost every decision point, Sun chose to try and make the JDK configurable/tunable/switchable/etc

most of the time, we (Java devs) don't bother...

oh, let's be honest--most of the time, most Java devs don't even know about many of these configuration points

ironically, some of the various hacks Java devs do on top of the JDK could be avoided

Concepts

The JDK is also now open

meaning, technically, we can do whatever we want with it, so long as we don't call the result "Java"*

this includes the compiler, the libraries, the VM, ...

Terminology

"Hack" has numerous meanings

if you heard "hack" and thought,

"Cool! I'm gonna break somebody's website ..."

... go catch another session... now

if you heard "hack" and thought,

"Cool! I'm gonna learn how to do some strange and esoteric things to the JDK that might help me avoid one of those all-night last-minute coding frenzies ..."

... stick around

To Start...

Helpful tip: Know where your JDK lives

the JRE is self-contained, with little to no "systemwide" settings (Registry, etc) touched

you can xcopy/cp -r another copy of it to have a "standalone" JDK

however, many Java installs assume a "shared" JDK/JRE on the system

varies by system

Windows: Typically C:\Program Files\Java\jdk1.x.0_nn...

MacOSX: /Library/Java/JavaVirtualMachines/jdk1.x.0_nn.jdk/Contents/Home/

Linux: (depends on distribution)

To Start...

Helpful safety tip: wear goggles!

don't practice in a production environment!

even so, the copy-a-new-JRE trick still works

xcopy/cp -r the entire JRE directory over to some other location and work out of that copy

Helpful production tip: do this for production servers, too!

provides isolation from the "globally-installed" JVM

also helps to incrementally upgrade servers

Hacking

Hackpoints in the JDK (all binary)

modifying JVM settings at runtime

call private methods, get/set private fields

load code remotely from an HTTP server or other place

monkey-patch the JVM libraries

modifying bytecode during load

embedding the JDK in your own (native) code

control serialization and replacement behavior

load interface implementations w/o ClassLoaders (or OSGi)

ignore CLASSPATH and –Djava.class.path, set other settings

control the JVM via the debugger interface (JDI)

control the JVM via the native tools interface (JVMTI)

Hacking

Hackpoints in the JDK

"harden" a deployed application from environment changes

spelunk/reverse compiled Java classes

augment/enhance/modify compiled Java classes

modify executing code without reloading

creating a custom Java launcher

modifying the Java launcher

modifying the Java class library

modifying the Java compiler

modifying the JVM

Summary

Hacking on the JDK is:

... fun

... powerful

... dangerous

(Choose all that apply!)

Appendices

Credentials

Who is this guy?

Architect, Engineering Manager/Leader, "force multiplier"

http://www.newardassociates.com

http://blogs.newardassociates.com

Sr Distinguished Engineer, Capital One

Educative (http://educative.io) Author

Performance Management for Engineering Managers

Books

Developer Relations Activity Patterns (w/Woodruff, et al; APress, forthcoming)

Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)

Effective Enterprise Java (Addison-Wesley, 2004)

SSCLI Essentials (w/Stutz, et al; OReilly, 2003)

Server-Based Java Programming (Manning, 2000)