Java interop via inline Java code in Haskell modules.

Version on this page:0.8.4
LTS Haskell 12.26:0.8.4
Stackage Nightly 2018-09-28:0.8.4
Latest on Hackage:0.10.0@rev:1

See all snapshots inline-java appears in

BSD-3-Clause licensed by Tweag I/O
Maintained by [email protected]
This version can be pinned in stack with:inline-java-0.8.4@sha256:9862ba980b40792af5f3e29c52929e35ce3e9733d498a0324049b6b1001509ef,1652

Module documentation for 0.8.4

inline-java: Call any JVM function from Haskell


NOTE 1: you’ll need GHC >= 8.0.2 to compile and use this package.

The Haskell standard includes a native foreign function interface (FFI). Using it can be a bit involved and only C support is implemented in GHC. inline-java lets you call any JVM function directly, from Haskell, without the need to write your own foreign import declarations using the FFI. In the style of inline-c for C and inline-r for calling R, inline-java lets you name any function to call inline in your code. It is implemented on top of the jni and jvm packages using a GHC Core plugin to orchestrate compilation and loading of the inlined Java snippets.


Graphical Hello World using Java Swing:

{-# LANGUAGE DataKinds #-}
{-# LANGUAGE QuasiQuotes #-}
{-# LANGUAGE OverloadedStrings #-}
{-# OPTIONS_GHC -fplugin=Language.Java.Inline.Plugin #-}
module Main where

import Data.Text (Text)
import Language.Java
import Language.Java.Inline

main :: IO ()
main = withJVM [] $ do
    message <- reflect ("Hello World!" :: Text)
    [java| {
      javax.swing.JOptionPane.showMessageDialog(null, $message);
      } |]

Building it


  • the Stack build tool (version 1.2 or above);
  • either, the Nix package manager,
  • or, OpenJDK and Gradle installed from your distro.

On OS X, you’ll need to install the Legacy Java SE 6 runtime when prompted, even when using Nix.

To build:

$ stack build

You can optionally get Stack to download a JDK in a local sandbox (using Nix) for good build results reproducibility. This is the recommended way to build inline-java. Alternatively, you’ll need it installed through your OS distribution’s package manager for the next steps (and you’ll need to tell Stack how to find the JVM header files and shared libraries).

To use Nix, set the following in your ~/.stack/config.yaml (or pass --nix to all Stack commands, see the Stack manual for more):

  enable: true


The generated java output can be dumped to stderr by passing to GHC


If -ddump-to-file is in effect (as when using stack), the java code is dumped to <module>.dump-java instead.


Copyright (c) 2015-2016 EURL Tweag.

All rights reserved.

inline-java is free software, and may be redistributed under the terms specified in the LICENSE file.



inline-java is maintained by Tweag I/O.

Have questions? Need help? Tweet at @tweagio.


Change Log

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog.

[0.8.4] - 2018-07-11


  • Dependency bounds and import declarations to build with ghc 8.4.1.

[0.8.3] - 2018-07-04


  • Rename all BUILD files to BUILD.bazel.
  • Workaround Gradle sometimes trashing output in recent versions.

[0.8.2] - 2018-02-27


  • Fix check for settings.gradle file in cabal hooks. Prevents the file from growing a few bytes each time a project using gradle hooks is rebuilt.

[0.8.1] - 2018-02-27


  • Relaxed upper bound of jni to admit jni-0.6.0.

[0.8.0] - 2018-02-27


  • addJarsToClasspath: a function to add a list of jar paths to the CLASSPATH in cabal hooks.


  • gradleHooks now extends the CLASSPATH even if the CLASSPATH is set.
  • Renamed setGradleClasspath to prependClasspathWithGradle.

[0.7.2] - 2017-12-27


  • CLASSPATH is now set in Cabal hooks before running haddock.

[0.7.1] - 2017-12-05


  • A hello-java example project.
  • Upper bounds to jni and jvm.


  • Normalize type families before inspecting the return type of quasiquotations.

[0.7.0] - 2017-08-31


  • Plugin option to dump the generated Java to the console or a file.
  • Partial support for inner classes. Antiquoted variables and quasiquotation results can refer to inner classes now.


  • Use a compiler plugin to build the bytecode table and to generate Java code. We no longer need static pointers to find the bytecode at runtime, and we can check at build-time that values are marshaled between matching types in Java and Haskell when using antiquated variables or the result of quasiquotations. Also, now java quasiquotes work inside Template Haskell brackets ([| … |]).
  • Use only the lexer in language-java. This defers most parsing errors to the javac compiler which produces better error messages and might support newer syntactic constructs like anonymous functions.
  • Java checked exceptions are now allowed in java quasiquotes.


  • Gradle hooks now produce a correct build-time classpath.

[0.6.5] - 2017-04-13


  • Exposed loadJavaWrappers.

[0.6.4] - 2017-04-09


  • Fixed handling of repeated antiquotation variables, which in some cases was causing a compilation error.

[0.6.3] - 2017-03-12


  • Setting the CLASSPATH using Gradle is now fully supported. It was previously unusable due to a bug (see #42).

[0.6.2] - 2017-02-21

  • Avoid producing warnings about unused inlinejava_bytecode0 bindings.
  • Support type synonyms in variable antiquotation.
  • Update lower bounds of jni to 0.3 and jvm to 0.2.

[0.6.1] - 2016-12-27

  • Support passing array objects as arguments / return values.
  • More robust mangling of inline class name.

[0.6.0] - 2016-12-13


  • Can set a custom CLASSPATH in Setup.hs from Gradle build configurations to use when compiling inline expressions.
  • GHC 8 compatibility
  • Support inline expressions that compile to multiple .class files (e.g for anonymous classes and anonymous function literals).


  • The return type of inline expressions no longer needs Reify/Reflect instances.


  • Fix antiquotation: in [java| $ |], obj is now recognized as an antiquotation variable.
  • Passing multiple options to the JVM using withJVM.

[0.5.0] - 2016-12-13


  • First release with support for inline Java expressions.


  • Split lower-level and mid-level bindings into separate packages: jni and jvm.