Depending of a non-free Java VM would impede the freedom of Inkscape as a whole - http://www.gnu.org/philosophy/java-trap.html
There has been (evidently) some work trying to at least get batik (the svg->pdf/png rasterizer/transcoder) to work with gcj; at the moment its jpeg handling evidently depends on a single chunk of non-standardized (i.e. not supported by gcj/gnu-classpath) java. I can't find anything more contemporary than that.
That said, there appear to be three opinions on what should be done:
1. wait for cairo, with native pdf-backend support 2. keep the existing system, generating ps natively, even though this results in some svg features (transparency being the one that keeps me up at night) not working 2a. Try and add / use a better external dependency, like batik, either rewritten or repackaged. 3. Add in native PDF support by performing a bit of modification on inkscape's internal ps generation routines.
I'm sorry, but as a user I really like option #3. This would let you use cool new PDF features for output, including: 1. transparency 2. layers 3. automatic metadata propagation
Again, these features seem like they'd be a pretty easy extension of our existing ps code... ...Eric