HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
flatland
drip
Shell2012–2015
flatland / drip

drip

Fast JVM launching without the hassle of persistent JVMs.

11Distinct people
11Mentions
0Explicit recommenders
268GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Fast JVM launching without the hassle of persistent JVMs.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year11 dated mentions

Observed mentions: 2012-09-11 09:41:37 UTC to 2015-08-07 20:49:58 UTC.

02462012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2015

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC615
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC404
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC000
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC110

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Drip is a launcher for the Java Virtual Machine that provides much faster startup times than the java command. The drip script is intended to be a drop-in replacement for the java command, only faster. Drip is a single bash script and a little bit of C and Java code. It is intended to work with any JVM-based language and anywhere bash is available. How does it work? Unlike other tools intended to solve the JVM startup problem (e.g. Nailgun, Cake), Drip does not use a persistent JVM. There are many pitfalls to using a persistent JVM, which we discovered while working on the Cake build tool for Clojure. The main problem is that the state of the persistent JVM gets dirty over time, producing strange errors and requiring liberal use of cake kill whenever any error is encountered, just in case dirty state is the cause. Instead of going down this road, Drip uses a different strategy. It keeps a fresh JVM spun up in reserve with the correct classpath and other JVM options so you can quickly connect and use it when needed, then throw it away. Drip hashes the JVM options and stores information about how to connect to the JVM in a directory with the hash value as its name. Installation The following instructions assume that ~/bin is on your $PATH. If that is not the case, you can substitute your favorite location. Standalone — We recommend this to get started quickly. curl -L http://drip.flatland.org > ~/bin/drip chmod 755 ~/bin/drip Checkout — If you want to hack on Drip or follow the latest development, this is the way to go. git clone https://github.com/flatland/drip.git cd drip && make prefix=~/bin install Homebrew — This is a convenient way to brew drip on OS X. brew install drip Note: Installing brew requires gcc. Here are instructions for how to install it on OS X Mountain Lion. Usage You can call drip with the same arguments as java. Try it. The first time you execute drip with new arguments, it will take as long as a plain java command, because it has to spin up a JVM from scratch, but after that it will be fast. For example, to start a Clojure repl with drip: drip -cp clojure.jar clojure.main The Drip JVM will eventually shut itself down if you never connect to it. The time limit defaults to four hours, but you can change this by setting the DRIP_SHUTDOWN environment variable before calling drip to set a timeout, in minutes: DRIP_SHUTDOWN=30 drip -cp clojure.jar clojure.main This creates a Clojure repl as usual, either by starting up a new one or connecting to a waiting JVM. But the JVM that is spun up to serve future requests with the same classpath will have a 30-minute timeout to deactivation. JVM Language Integration For more information about how to integrate Drip with your favorite JVM language, check out the wiki. Advanced settings Drip supports the following advanced settings. Pre-Initialization By default, Drip only loads your main class at startup, but you can tell Drip to run additional code at startup. This can be used to load classes or execute any initialization code you like. For a language like Clojure, which compiles code on-the-fly, this can be used to precompile commonly used code by requiring it. To tell Drip how to initialize a new JVM, use the DRIP_INIT and DRIP_INIT_CLASS environment variables. DRIP_INIT should be a newline-separated list of args to be passed to the main() function of DRIP_INIT_CLASS. DRIP_INIT_CLASS defaults to the main class the JVM was started with. System Properties Sometimes, you need to set Java system properties, but you don't want them to be included in the JVM options used for hashing. In this case, use two dashes instead of one, and the options won't be passed to the JVM at startup, instead they will be passed at runtime. Keep in mind that any system properties passed this way will not be set during initialization. Environment Variables Drip passes all environment variables exported at runtime to the JVM and merges them into the map returned by System.getenv. Keep in mind that the environment isn't modified until we connect to the JVM; during initialization, the environment will be derived from the previous process that launched the spare JVM.  License Drip is licensed under the EPL Eclipse Public License. See LICENSE for details.
Read the full README on GitHub

What Hacker News says

11 sources
So obvious, trade-off space for time, yet I wouldn't have thought of it... I mean, I've thought about this problem, written a persistent JVM solution, and didn't think of it. Memory is cheaper than my intuition realises. I wonder how many other "obvious" solutions I'm missing like this? EDIT for the code I tried, user time is almost 3 times faster, but real time is only around 10% better... I don't understand linux well enough to know why - anyone care to explain please? EDIT Yes, drip had already run. (I picked typical times from about 10 runs each). $ time java... real 0m1.466s user 0m1.216s sys 0m0.180s $ time drip... real 0m1.378s user 0m0.412s sys 0m0.260s BTW: For server-like workloads, an advantage of a persistent JVM is that it gets dramatically faster over repeated runs of the same code, as it improves its ho
Read the rest
tspot-style adaptive optimisations. I really like his quickstart "standalone" installation. WARNING "drip kill" crashed my system. The kill functions are kill_jvms and kill_jvm (https://github.com/flatland/drip/blob/develop/bin/drip). I'm using an older ubuntu 10.04 LTS.
In Fast JVM launching without the hassle of persistent JVMs

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.