ninjudd/drip

Fast JVM launching without the hassle of persistent JVMs.

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 https://raw.githubusercontent.com/ninjudd/drip/master/bin/drip > ~/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/ninjudd/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.

drip's Issues

Drip with leiningen is hanging cats

I noticed that after a few runs of lein with drip, it starts to hang after the command is finished. Terminal title says 'cat', so I guess the cat process is hanging? I can kill it with ctrl+c.

Make 'drip ps' show more information

Would be nice for it to show which JVMs are idle, and which are running and their specific args.

Wrong link on flatland.org

Link on flatland.org points to the 'drip' organization, a node npm ci tool rather than to this repo. (Mentioned in IRC, where amalloy said I should post it here.)

Add a changelog

It'd help immensely in figuring out what's changed from version to version if there were a changelog.

script_name can return an empty string if 'drip' not in '$PATH'

In the script_name function if using drip in some folders, e.g. in a cloned repository, this snippet will store an empty string in script.

    # normalize $0 on certain BSDs
    if [ "$(dirname "$0")" = "." ]; then
        script="$(which $(basename "$0"))"

For example if I'm in path/to/drip-repo/bin, then

"$(dirname "$0")" = "." is true and $(which $(basename "$0")) echoes an empty string. This empty causes problems in find_drip_jar, when dirname of an empty string fails.

As you probably want a portable way to get the actual real path of the drip script, I propose a technique i've found on stackoverflow (http://stackoverflow.com/a/246128/48136) when dealing with similar problems.

function script_name { # inspired by http://stackoverflow.com/a/246128/48136
    local SOURCE="${BASH_SOURCE[0]}"
    local DIR="$( dirname "$SOURCE" )"

    while [ -h "$SOURCE" ]
    do 
      SOURCE="$(readlink "$SOURCE")"
      [[ $SOURCE != /* ]] && SOURCE="$DIR/$SOURCE"
      DIR="$( cd -P "$( dirname "$SOURCE"  )" && pwd )"
    done
    DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"

    echo $DIR'/'$(basename $BASH_SOURCE)
}

How does that sound ?

Support `upgrade` option like Leiningen does

Downloading a new version of drip every time is a chore. Feature request: Consider supporting upgrade option like Leiningen.

Error on OSX Lion, Java 1.7.0_04

I did this:

curl -L http://drip.flatland.org > ~/bin/drip
chmod 755 ~/bin/drip

And drip shows me its default output when I use it:

$ drip
Usage: drip [command | same args as java]

drip supports the following commands:
    version          print drip version and exit
    upgrade          upgrade drip to the latest version
    kill [-signal]   kill all idle drip JVMs (with signal)
    ps               print a list of all drip processes

Then I did drip upgrade:

$ drip upgrade
Downloading https://raw.github.com/flatland/drip/master/bin/drip...
######################################################################## 100.0%

Then I put this in ~/.lein/leinrc:

LEIN_JAVA_CMD=${LEIN_JAVA_CMD-drip}

Now, in a lein2-preview10 project, when I run lein check:

$ lein check
/Users/robert/bin/drip: line 161: /Users/robert/.drip/0.1.2/drip_daemon: No such file or directory
Compiling namespace ....

Here's what /Users/robert/.drip looks like after the attempt:

$ tree ~/.drip
/Users/robert/.drip
└── 0.1.2
    └── d72a9760a72ced4d3483f19aee800a1922944eda
        ├── 3944-1
        │   ├── control
        │   └── status
        └── opts

And the output of drip ps is always empty.

Help, please!

Use make for C compilation when not standalone

This would make drip work better with Homebrew.

JRuby with rbenv or rvm and drip seriously messes up my terminal (on os x 10.8)

It's not that drip doesn't work... it kind of does but since my terminal gets completely messed up, drip is unusable.

What happens is, with either rbenv or rvm, that setting export JAVACMD=$HOME/Local/bin/drip and then executing jruby makes my terminal not accepting keyboard input... or does it extremely sluggishly - like having to press the key l 6 times to get an l and having to press s 10 times to get an s (as in ls). This continues until I close that terminal window.
If I just don't set JAVACMD this never happens - so it's definitely something to do with drip.

Interestingly, if I turn off rbenv or rvm, I can get drip to work reasonably with a simple downloaded copy of jruby.

Use full command line for sha

This will protect us from sharing the wrong JVM accidentally and make it easier to print better info in drip ps.

Switchable impls are not thread-safe

I realized I messed that up on the way home. I'm going to just stop trying to make them synchronized, since we use them only from one thread.

NoClassDefFoundError with Scala but script still runs

echo 'println("hi")' > somescript.scala
scala somescript.scala

Exception in thread "main" java.lang.NoClassDefFoundError: org/flatland/drip/Main
Caused by: java.lang.ClassNotFoundException: org.flatland.drip.Main
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
Could not find the main class: org.flatland.drip.Main. Program will exit.
hi

Drip fails on Debian

The first launch of drip works fine, but the second time:

> drip -cp clojure-1.4.0.jar clojure.main                   ~/code/play-master/lib
Exception in thread "main" java.lang.NoClassDefFoundError: sun/reflect/UnsafeIntegerFieldAccessorImpl
        at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:97)
        at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:140)
        at java.lang.reflect.Field.acquireFieldAccessor(Field.java:936)
        at java.lang.reflect.Field.getFieldAccessor(Field.java:917)
        at java.lang.reflect.Field.get(Field.java:376)
        at org.flatland.drip.Main.replaceFileDescriptor(Main.java:158)
        at org.flatland.drip.Main.switchStreams(Main.java:187)
        at org.flatland.drip.Main.start(Main.java:86)
        at org.flatland.drip.Main.main(Main.java:64)

> java -cp clojure-1.4.0.jar clojure.main                     ~/code/play-master/lib
Clojure 1.4.0
user=> 

> java -version                                                  ~/code/play-master/lib  
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.13) (6b18-1.8.13-0+squeeze2)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

Bug multiple JVM with leiningen 2

I'm having the same problem like those discussing here:
https://groups.google.com/forum/?fromgroups=#!topic/clojure/FWIM-akbEL8

NoClassDefFoundError

xumingmingv:drip(git:master)$ drip -cp /usr/share/java/clojure-1.4.0.jar clojure.main
Exception in thread "main" java.lang.NoClassDefFoundError: org/flatland/drip/Main
Caused by: java.lang.ClassNotFoundException: org.flatland.drip.Main
    at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Clojure 1.4.0
user=> 

JRuby won't run on the second invocation

I tried drip with JRuby, this is what happens:

% drip -cp $MY_RUBY_HOME/lib/jruby.jar org.jruby.Main -v
jruby 1.6.7 (ruby-1.8.7-p357) (2012-02-22 3e82bc8) (Java HotSpot(TM) 64-Bit Server VM 1.7.0_04) [darwin-x86_64-java]
% drip -cp $MY_RUBY_HOME/lib/jruby.jar org.jruby.Main -v
Exception in thread "main" java.lang.ClassNotFoundException: org/jruby/Main
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Class.java:186)
  at org.flatland.drip.Main.mainMethod(Main.java:38)
  at org.flatland.drip.Main.main(Main.java:19)

The second time it just hangs after printing the stack trace. It also leaves a java process running after I ctrl-C it. I've killed all drip and java processes and tried again a few times, with the same results.

I assume this isn't JRuby-specific, but that's what I tried with.

A way to know current drip version

I am not sure how to find the version of the currently installed drip. There should be a command-line switch to determine that.

decaf.flatland.org doesn't point to the BASH script

I downloaded it from here: https://raw.github.com/flatland/drip/master/bin/drip

The README should be updated.

Make drip work with -jar option

Currently, it doesn't.

Drip does not seem to make startup faster

I'm trying to speed up leiningen for the simplest commands, like lein help, etc.

Everything seems to work as expected (the jvm seems to be re-used), however I'm getting no speed-up.

Should drip speed up such things, or I'm mistaken? If that's the case, where can I expect a speed-up? Or maybe I've misconfigured something?

Thank you, by the way, drip seems really awesome.

% /Users/va1en0k/.leindrip/drip kill


% /Users/va1en0k/.leindrip/drip ps  


% time lein test 

lein test user

Testing user

Ran 0 tests containing 0 assertions.
0 failures, 0 errors.
lein test  17.77s user 0.82s system 275% cpu 6.752 total


% time lein test

lein test user

Testing user

Ran 0 tests containing 0 assertions.
0 failures, 0 errors.
lein test  0.10s user 0.10s system 3% cpu 6.159 total


% time lein test

lein test user

Testing user

Ran 0 tests containing 0 assertions.
0 failures, 0 errors.
lein test  0.09s user 0.10s system 2% cpu 6.484 total


% /Users/va1en0k/.leindrip/drip ps  
18119 org.flatland.drip.Main clojure.main /Users/va1en0k/.drip/0.2.3/9d4770502bd965e8930beaa651c7e0a428a98e2a/18097-1 -XX:+TieredCompilation -Xbootclasspath/a:/Users/va1en0k/.lein/self-installs/leiningen-2.0.0-standalone.jar -Dfile.encoding=UTF-8 -Dmaven.wagon.http.ssl.easy=false -Dleiningen.original.pwd=/Users/va1en0k/Mine/shegon -Dleiningen.script=/usr/local/bin/../Cellar/leiningen/2.0.0/bin/lein -Djava.awt.headless=true

Lein repl is echoing the input

I think this has to do with readline support in reply.

user=> :foo
:foo
:foo
user=> :bar
:bar
:bar
user=> (+ 1 2 3)
(+ 1 2 3)
6

drip doesn't work with maven

Hi,

I'm trying to force maven to work with drip. Exporting JAVACMD to drip path will instruct maven to use drip; however, on each 'mvn' call new java instance will be started but not reused existing one.

Use separate FIFOs for args

We could use a separate FIFO for each arg we need to pass at runtime instead of placing the args at the beginning of the in FIFO. This way we wouldn't have to use netstrings. @amalloy, what do you think of this?

Liscense?

I'd like to integrate Drip into one of my open source software projects. What's the license?

lein drip isn't' creating jvm processes

Iv added

LEIN_JAVA_CMD=${LEIN_JAVA_CMD-drip} 

to ~/.lein/leinrc yet running lein test/compile/uberjar isn't creating pre-spinned up VM's, changing it to:

LEIN_JAVA_CMD=${drip} 

Spins up a vm for each task.

Im using Ubuntu 12.04 with lein2 preview-10 and sun jdk 1.6_026

Running drip on:

 drip -cp ./repository/org/clojure/clojure/1.4.0/clojure-1.4.0.jar clojure.main -e "(reduce + (range 100))"

Does seem to work as expected
Thanks
Ronen

Use from_jvm FIFO to pass exit code

This is a continution of #20.

make an archive available

I created a Homebrew formula pullrequest. But the homebrew guys would like a tarball (or zip) for a specific version.
This could be located in the project's download section.

thx

Error on Java path with whitespaces

My Java executable lives under a directory with a whitespace in its name (Internet Plug-Ins), and that seems to confuse drip. Here is a screenshot:

On Ubuntu 10.04: "Exception in thread "main"" on second call of "drip -cp bin/jars/clojure-1.4.0.jar clojure.main"

First call is ok, with the usual slowness of java startup,
then I exited it with "Ctrl-D", and called it again (command - see title "drip -cp ...").

If I can generate some additional help/debug info, I would like to know how.

Thanks

compilation error

Following up after #52. I followed the standalone instructions for installing Drip easily. Then I followed Artem's commands as described in #52. I got the below error, which looks like a c or c++ compilation error. Note that I get this error regardless of what arguments I pass to Drip. E.g.:

$ drip
/Users/aaroncrow/.drip/0.2.0/src/drip_daemon.c: In function ‘main’:
/Users/aaroncrow/.drip/0.2.0/src/drip_daemon.c:55: error: ‘for’ loop initial declaration used outside C99 mode

Artem says this may be dependent on GCC version.

$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)

drip doesn't work with lein 2.0.0

I followed the instructions in the wiki to set up drip with newly released lein 2.0.0. Unfortunately it seems to spawn a new vm for every request and drip ps doesn't show any of them. drip kill doesn't kill any of them either.

This happens both in projects and outside projects.

Is there a drip log somewhere?

For example if I put a 'puts' in my dripmain.rb, will it be output anywhere?

Is there a setting to enable logging, perhaps?

Thanks,
Chris

Drip doesn't work with Drake

artem:~/drake$ drip version
drip version "0.1.8" package 
artem:~/drake$ time drip -cp drake.jar clojure.main -e '(println "Hai!")'
Hai!

real    0m2.062s
user    0m2.462s
sys 0m0.177s
artem:~/drake$ time drip -cp drake.jar clojure.main -e '(println "Hai!")'
Hai!

real    0m0.189s
user    0m0.064s
sys 0m0.067s
artem:~/drake$ time drip -cp drake.jar drake.core
Cannot find file or directory: ./workflow.d (use --help for documentation)

real    0m6.542s
user    0m10.698s
sys 0m0.473s
artem:~/drake$ time drip -cp drake.jar drake.core
Cannot find file or directory: ./workflow.d (use --help for documentation)

real    0m7.216s
user    0m10.790s
sys 0m0.446s
artem:~/drake$

On FreeBSD drip does not work as a drop-in replacement for java.

Drip does not seem to pass parameters along to java correctly on FreeBSD

See following shell sessions:

 [1510][jostein@invalid:~/.m2/repository/org/clojure/clojure/1.4.0]$ ls -l
 total 3372
 -rw-r--r--  1 jostein  users      180 Oct 15 14:24 _maven.repositories
 -rw-r--r--  1 jostein  users  3421683 Oct 15 14:24 clojure-1.4.0.jar
 -rw-r--r--  1 jostein  users       40 Oct 15 14:24 clojure-1.4.0.jar.sha1
 -rw-r--r--  1 jostein  users     5420 Oct 12 20:15 clojure-1.4.0.pom
 -rw-r--r--  1 jostein  users       40 Oct 12 20:15 clojure-1.4.0.pom.sha1
 [1510][jostein@invalid:~/.m2/repository/org/clojure/clojure/1.4.0]$ drip -cp clojure-1.4.0.jar clojure.main
 expr: illegal option -- c
 usage: expr [-e] expression
 Unknown command: -cp
 [1510][jostein@invalid:~/.m2/repository/org/clojure/clojure/1.4.0]$ java -cp clojure-1.4.0.jar clojure.main
 Clojure 1.4.0
 user=>

Propagate signals to JVM

We need to trap all signals in bin/drip and propagate them to the JVM process using kill.

Example with jar file other than clojure.jar?

I'd like to try running drip with Clojure programs more complicated than '(* 3 3)' or a stand-alone REPL; e.g., say I have done 'lein uberjar' and made a standalone jar file. I imagine it would be possible to use drip'ped JVM to run that as well, but was unable to figure out the incantation for that (drip -cp blah-standalone.jar X fails where X is, well, any of a dozen things I tried).

I figured others would be interested in this too, perhaps in the README? Hence this ticket. Thanks!

Build with a simple shell script instead of requiring lein

The build process for drip is really simple. I think we can just create the pom.xml by hand and write a simple shell script to compile and build the jar. This way, it will be easier for users of other JVM languages to run from a checkout.

Command output is printed twice

shantanu:~$ drip -version
java version "1.7.0_06"
Java(TM) SE Runtime Environment (build 1.7.0_06-b24)
Java HotSpot(TM) Server VM (build 23.2-b09, mixed mode)
java version "1.7.0_06"
Java(TM) SE Runtime Environment (build 1.7.0_06-b24)
Java HotSpot(TM) Server VM (build 23.2-b09, mixed mode)

vs

shantanu:~$ java -version
java version "1.7.0_06"
Java(TM) SE Runtime Environment (build 1.7.0_06-b24)
Java HotSpot(TM) Server VM (build 23.2-b09, mixed mode)

Navigating through JLine history breaks

When navigating through my JLine history with the arrow keys, sometimes the line is not redrawn correctly, causing the line I am editing to slowly "migrate" up the screen as I move through my history. This is intermittent, but pretty easy to reproduce with longer lines.

Drip is leaving cats everywhere

83866 ttys001    0:00.00 cat /Users/justin/.decaf/2f12d7ba431590accb1832e1805097ca5a591724/83777-1/err
83902 ttys001    0:00.00 cat /Users/justin/.decaf/2f12d7ba431590accb1832e1805097ca5a591724/83843-1/err
83950 ttys001    0:00.00 cat /Users/justin/.decaf/2f12d7ba431590accb1832e1805097ca5a591724/83879-1/err
95682 ttys001    0:00.00 cat /Users/justin/.decaf/7d56443d4ddb62bcfc0efda0fd15c4b6d1bf97c0/95619-1/err
95750 ttys001    0:00.00 cat /Users/justin/.decaf/7d56443d4ddb62bcfc0efda0fd15c4b6d1bf97c0/95659-1/err
96623 ttys001    0:00.00 cat /Users/justin/.decaf/f2d0d6d88a744b21387a4a8b180e71939dcb8104/96542-1/err
99190 ttys001    0:00.00 cat /Users/justin/.drip/84243cd00e54924014eb8fe928db48c2ae7f3bd5/99132-1/err
99326 ttys001    0:00.00 cat /Users/justin/.drip/4fc6bbb6e2f107bce0f519fb6928d59796fa729a/99223-1/err
99429 ttys001    0:00.00 cat /Users/justin/.drip/4fc6bbb6e2f107bce0f519fb6928d59796fa729a/99303-1/err
99496 ttys001    0:00.00 cat /Users/justin/.drip/4fc6bbb6e2f107bce0f519fb6928d59796fa729a/99406-1/err
99563 ttys001    0:00.00 cat /Users/justin/.drip/4fc6bbb6e2f107bce0f519fb6928d59796fa729a/99473-1/err
99622 ttys001    0:00.00 cat /Users/justin/.drip/4fc6bbb6e2f107bce0f519fb6928d59796fa729a/99540-1/err
99686 ttys001    0:00.00 cat /Users/justin/.drip/4fc6bbb6e2f107bce0f519fb6928d59796fa729a/99599-1/err
99808 ttys001    0:00.00 cat /Users/justin/.drip/4fc6bbb6e2f107bce0f519fb6928d59796fa729a/99728-1/err
99865 ttys001    0:00.00 cat /Users/justin/.drip/4fc6bbb6e2f107bce0f519fb6928d59796fa729a/99784-1/err
  108 ttys002    0:00.00 cat /Users/justin/.drip/88f928aa2e8d1a77c828cfb08dcfbf668c7d7921/99930-1/err
  185 ttys002    0:00.00 cat /Users/justin/.drip/88f928aa2e8d1a77c828cfb08dcfbf668c7d7921/99984-1/err
  443 ttys002    0:00.00 cat /Users/justin/.drip/88f928aa2e8d1a77c828cfb08dcfbf668c7d7921/329-1/err
  510 ttys002    0:00.00 cat /Users/justin/.drip/88f928aa2e8d1a77c828cfb08dcfbf668c7d7921/420-1/err
  580 ttys002    0:00.00 cat /Users/justin/.drip/88f928aa2e8d1a77c828cfb08dcfbf668c7d7921/486-1/err

Use netstrings instead of newline delimited strings for passing options

This will allow us to include literal newlines in environment variables in #1.

Create separate classes/ dir for compiled .class files

Having them in src/ is a pain for a number of reasons. It messes up tab completion, for example. This change should be confined to just the Makefile, so it's a nice isolated thing if someone wants to get their feet wet on contributing.

Spin down the spare JVM after a specific period of time

Something between 1 hour and 4 hours seems like a good default to me.

Set environment variables before executing main

The second answer below may be a way to do this.

http://stackoverflow.com/questions/318239/how-do-i-set-environment-variables-from-java

Spawning multiple processes using drip with jruby 1.7.1. Never reusing existing processes

My expectation is that the processes it spawns should be re-used. While it is spawning multiple processes there is no benefit to using drip. In fact it causes more issues because of the orphaned processes eating up resources.

Add drip kill command

This should shutdown all spare drip JVMs. I think it is safe for drip to claim all calls that meet the following criteria for internal commands:

1. there is only single argument
2. that argument has no . in it and is all lowercase

drip 0.2.2 got this error (java version "1.7.0_07")

$ cat error.log
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.flatland.drip.Main.invoke(Main.java:117)
at org.flatland.drip.Main.start(Main.java:74)
at org.flatland.drip.Main.main(Main.java:64)
Caused by: java.io.FileNotFoundException: -e\nnil (そのようなファイルやディレクトリはありません)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:138)
at java.io.FileInputStream.(FileInputStream.java:97)
at clojure.lang.Compiler.loadFile(Compiler.java:6909)
at clojure.main$load_script.invoke(main.clj:283)
at clojure.main$script_opt.invoke(main.clj:343)
at clojure.main$main.doInvoke(main.clj:427)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.lang.Var.invoke(Var.java:415)
at clojure.lang.AFn.applyToHelper(AFn.java:161)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.main.main(main.java:37)
... 7 more

Fails to output when input is redirected

First, mke sure the daemon is running:

$ drip -cp clojure.jar clojure.main -e nil

From then on, when stdin is redirected, nothing is output.

$ drip -cp clojure.jar clojure.main -e 1 </dev/null
$ drip -cp clojure.jar clojure.main -e 1
1

Add a drip upgrade

Will curl the latest script or run git pull depending on whether you are running in a checkout or standalone.

Allow setting Java properties at runtime

Users should be able to set system properties on a pre-spun JVM by passing arguments to drip of the form -Dproperty=value after a --.