#3862 jEdit 5.1.0 on Mac OS X with Java 7

minor bug

This is jEdit as Mac OS X application bundle, based on current Java 7
from Oracle, instead of the dead an buried Java 6 from Apple. Current
7u40 even supports Retina displays.

The main application launcher is http://java.net/projects/appbundler
from Oracle, see its appbundler-1.0.jar (it contains an ant task to do
the bundling on some running Mac OS X system, but the directory layout
and Info.plist file can be created by other means as well, on any

The resulting directory layout of jEdit.app is as follows, based on
existing jEdit-5.1.0 for Mac OS X:

Contents/MacOS/JavaAppLauncher # main launcher from appbundler-1.0.jar
Contents/Info.plist # handwritten version based on ant output
Contents/Java/ # jedit.jar and all the rest (formerly Resources/Java/)
Contents/PlugIns/jdk/ # full jdk, or trimmed version produced by appbundler ant task
Contents/Resources/icon.icns # regular jEdit icon as before
Contents/Resources/file.icns # presently unused, no file types yet

The appbundler ant task takes a locally installed jdk as a starting
point to bundle a subset of it into the application. This is now the
official policy of Oracle and Apple. Note that plain jre does not
work here at the moment -- reasons unknown. For demonstration
purposes I've made Contents/PlugIns/jdk a symlink to some jdk found
locally on the system, but an official version should include a
self-contained copy of it.

Moreover, note that appbundler-1.0 does not handle file types yet.
There is a fork of the Oracle project here
https://bitbucket.org/infinitekind/appbundler that does that, apart
from other improvements, but I did not manage to make this work yet.

Further required changes on the jEdit side:

* Debug.ALTERNATIVE_DISPATCHER = false (always). Maybe even remove
that alternative key event dispatcher altogether. It is not
required in Java 6, and breaks Java 7.

* Brushing up the MacOSX plugin, maybe dismantling some old
workarounds. In fact, it would be preferable to get Mac OS X
application support directly into jedit.jar -- this works by
dynamic method invocation via "reflection", so jEdit will be
compilable and runnable on all platforms.


  • Makarius

  • Alan Ezust
    Alan Ezust

    I tested your bundle, after symlinking "jdk" to a jdk 1.7.0_40 directory, and it worked great.
    But why does it need to be a symlink to the JDK and not the JRE?
    And is there another location to symlink to that will always be the latest? Because the "Latest" in the other macos folder always thinks it is JDK 1.6.
    Anyway, when I installed jdk7u45, this bundle kept using the 7u40 and I had to manually redo the symlink.
    So even if the build file built the bundler correctly and installed it correctly, and was able to find the current jdk, I think it would keep breaking after each update of java.

  • Makarius

    These questions of JDK vs. JRE and use of "the latest Java version" that happens to be on the machine, touch general policies of Oracle and the relatively new appbundler approach. Oracle seems to prefer application providers to include an appropriate version of JDK, as produced by their ant task that is included in the appbundler. The task takes an existing JDK installation on the machine (presumably "the latest") and prunes it slightly to make a bundled version for the app.

    I did not really do it like that, since I don't understand ant. I merely looked closely at the result of the ant task for a minimal example app and derived my handwritten Info.plist from it. In Isabelle/jEdit the JDK bundling is done differently --- this is where the symlinks to jdk where coming from, to imitate the directory layout where Oracle puts an actual copy of (pruned) JDK.

    IIRC, the guys from https://bitbucket.org/infinitekind/appbundler have occasionally wondered about the "slim JDK" approach instead of plain JRE. Maybe we can ask them for further advice -- they maintain a fork of the original appbundler 1.0 from Oracle, one that looks a bit more advanced.

    The following blog could also help to figure out the best way to deliver jEdit on Mac OS X, according to the present state of affairs: http://intransitione.com/blog/take-java-to-app-store/

  • Alan Ezust
    Alan Ezust

    I withdraw my complaint about how it is necessary to package a JRE with the .dmg installer. I see this is simply how it is done on the Mac, so that the installer works regardless of whether java is already installed somewhere else.
    This means the JRE we package should be used by jEdit as well, and it should have the unlimited JCE security policy already installed so SFTP works correctly. Which means it must not include java 8 until the auth cancel issue is resolved.

    • Makarius

      So lets go for it. Note that I am available the next 2 weeks for testing any dmg/app distributions you can produce. During the month of June I am mostly offline, though.

  • Björn Kautler
    Björn Kautler

    Ticket moved from /p/jedit/patches/510/

  • Björn Kautler
    Björn Kautler

    • labels: --> MacOSX specific
    • status: open --> closed-fixed
    • assigned_to: Björn Kautler
    • Group: --> minor bug
  • Björn Kautler
    Björn Kautler

    This is fixed with 5.2pre1. The OS X AppBundle now works correctly with an installed Oracle Java 7.