ted@tedneward.com | Blog: http://blogs.tedneward.com | Twitter: tedneward | Github: tedneward | LinkedIn: tedneward
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!)
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
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, ...
"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
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)
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
Helpful hacking tip: src.zip
included as part of normal JDK install* found in root of JDK install directory
contains 93% of Java runtime libraries* java., javax., com.*, ...
useful in a variety of ways
Hackpoints in the JDK (all binary)
modifying JVM settings at runtime
changing the JDK security policy at runtime
use custom security policy implementation
establishing (and preserving) security access context
call private methods, get/set private fields
load code remotely from an HTTP server or other place
Hackpoints in the JDK (all binary)
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)
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
Hacking on the JDK is:
... fun
... powerful
... dangerous
(Choose all that apply!)
Who is this guy?
Architect, Engineering Manager/Leader, "force multiplier"
Co-founder, Solidify US
http://www.solidify.dev
Principal -- Neward & Associates
Author
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)
See http://www.newardassociates.com