I seem to be doing enough things and there are more things going on with Java 9 of interest for me to give it a page with my stuff.
For example I recently noticed a post that JShell [1] is ready to go. This gives java it's own REPL interface. Something I had started once for my HalfPipe application but have yet to finish.
Finding that my understanding of things project related as far as openjdk goes is severely lacking. I looked at the jigsaw project page [2] to see if that would fill in any of the gaps in my knowledge. It did have a link [3] to a page with videos of presentations from a couple recent conferences. Although just looking at the readme for the jdk download was a pretty good suggestion to figure out what was going on.
I noticed another reference in passing to code to develop api's that will integrate the legacy Apple api's into the java awt Desktop api's, JEP 272. If your OS X code uses these api's this would be one to be aware of and maybe to watch. These api's were for some reason classified as 'internal' ones. Although, they were originally provided by Apple to provide extra OS specific features to java developers, definitely a public api. 'Internal' means they should be fated to end up inaccessible in Java 9. So for a straight up migration to 9 for anyone using these api's, this project should be the route. It will make them supported jdk api.
I did update my java 9 from the latest mainline forest. And updated the test halfpipe 9 application I have for that purpose. It appears this can still be done by simply splicing a jdk build into the javapackager application. Download the HalfPipe9 application and look at the contents should show you how this is done. For now leaving the information on that on the Whats New? page. I intend to move the java 9 content from there to here, and of course add more over time.
[1] JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)
[2] Project Jigsaw
[3] Project Jigsaw: Talks
[4] JEP 272: Platform-Specific Desktop Features
Update 12/06/15I did see a post go through that the Apple api's will be deprecated and not 'internal' and inaccessible in the java 9 release. If I remember correctly set to go away with java 10. Again, JEP 272 is to my understanding intended to be the ongoing supported continuation of the Apple api's. Your application will still launch at java 9 if you don't do anything with any com.apple.eawt or com.apple.eio but you would probably still want to plan on addressing them sometime. I am sort of looking forward to what JEP 272 has to offer.
When I went to change the Info.plist for my HalfPipe java 9 application it did stop launching for what seemed to be breaking the application signature. However, since then I have been unable to use javapackager to create a good working Java 8 or Java 9 application. I notice javapackager is included in the jigsaw build bin directory but that seems to an 8 version yet? I was going to try and create an application bundle on my own but then thought I have the halfpipe9.sh launch working so for now why not go with that. At some point though I have to figure how to create valid application bundles again. I had some notes on javapackager on the Whats new? page, but that doesn't seem to work anymore.
I had intended to do most of my java 9 testing using my HalfPipe application. As a Java shell it is convenient to try things out on. An embedded JRE was an idea to arrive sort of late to OS X. Immediately it didn't seem a really good idea since it made for very large applications. It did seem inevitable with the increasing OS emphasis on more secure, sandboxed, applications. The first OS X application bundler, appbundler, didn't even make embedded the default. javapackager[1] is the current tool that I would look to for handling application creation on OS X. It supports application signing and other issues related to having a valid OS X application ready for the app store. There is a little more on my use of javapackager on my 'what's new' page[2], that should eventually be included here. We were told that jigsaw and modular modular jvm's would be the long term solution for large applications. Now jigsaw is arriving.
In order to get full modular functionality, at this point in time, you need to get the jigsaw project ea[3] jvm. From what I remember of the java presentation videos you need to get into the jlink command to actually start modifying and potentially reducing the size of the jvm.
Once I started using this build though I ran into the situation where the app would not
launch because of the legacy Apple api's being made 'internal'.
Exception in thread "main" java.lang.IllegalAccessError: class us.hall.osx.OSXApplication (in module: Unnamed Module) cannot access class com.apple.eio.FileManager (in module: java.desktop), com.apple.eio is not exported to Unnamed Module
A commandline solution for this is indicated in JEP 261[4], addExports.
Correct usage for the OS X case was indicated to me on the jigsaw dev mailing list, I needed
both api packages so mine ended up looking like...
-XaddExports:java.desktop/com.apple.eawt=ALL-UNNAMED,java.desktop/com.apple.eio=ALL-UNNAMED
This allowed the application to be more or less command line from a script [5]
If you application isn't too complex to do this it can be handy to have something like this to launch it. You can often see
more meaningful error messages than a normal java application bundle will get written to the console logs.
Unfortunately, when I went to apply these same changes,addExports, to the application bundle it started failing on an application signature error. I have been manually modifying the same javapackager app bundle for a while, just copying in different versions of the jvm. I think there is no supported version of javapackager for java 9 yet. Now I might have to figure out how to use javapackager again to create an application from scratch with the -XaddExports options included. And then copy in the jigsaw ea jvm.
There is a long-term change to the Apple api's planned for. That is JEP 272[6]. This project will make the Apple api's a permanent part of the AWT Desktop api's. It is indicated initially to be largely based on the Apple api's. I assume this will be ready to go when Java 9 is generally available so for migrating OS X applications using these api's your choice will be change them to use JEP 272 api's or use the quick and dirty command line 'hack'. The 'hack' might not be available permanently.
More or less where I stand on the modular HalfPipe 9 application at this point. I have ended up doing more commandline with java 9 jvm's than I originally planned and have simple scripts for switching between those. I will maybe add something on that when I have time.
[1] javapackager
[2] What's new?
[3] jigsaw ea downloads
[4] JEP 261
[5] halfpipe9.sh
[6] JEP 272
12/06/15I did a simple splice of JShell into the java 9 HalfPipe application. I use, for now,
a simple system property, 'repl', to indicate what REPL is in use.
'hp', the default, is what I had previously began along the lines.
To get to jshell you can just do...
set repl jshell
jshell should be JShell. If the parser doesn't determine something else to do with entered
text it will try and pass it on to the appropriate REPL implementation. Simple stuff seems to work
with JShell now, except for assignments. Not sure why they don't
To get this to work I compile JShell with java9, jar it. And then include it in the classpath of the halfpipe9.sh script. The org.cmdline.CommandParser changes are still of course included in the multi-project Eclipse components that end up exported to halfpipe.jar. I am not including any of these yet. When there is a little more to them.
JShell's use of $ for temporary variables could be a little problematic. Needs looking at.
I am thinking about trying to add more repl implementations based on what I've done previously. The Rhino javascript shell is REPL like (Nashorn I've still not really looked at). As is JRuby's jirb. Groovy seemed a popular scripting choice for the Weka implementors. I've been thinking about adding it as another scripting possibility. It could be an REPL possibility as well. Of course I've been wanting a working 'R' interface for a while and that's still not there...
12/13/15 For what's new related to REPL's there is actually something on What's new?
12/06//15 For something new with 9 this week there are a couple updates to what I've already done. More on these again is on What's new ? Which should be merged/moved to here sometime. Locator it seems won't work modular for java runtime classes with a empty array URLClassLoader. You have to have the 'jrt' protocol prefix. jrt:/java.base for example. I changed JRTLister to give it a '-m' option to list modules. I then hardcoded that module list into Locator to have a complete module URL array. I thought I saw somewhere that the Locator getResource method shouldn't work at all on 'named modules', like the java runtime ones? Maybe I read that wrong.
I still want to get into having modules to call my very own. That will probably go along with converting HalfPipe and I have done along the lines of accomplishing that yet.
11/29/15 Again, for something new actually done with java 9 functionality I started a little jshell api related code, JShellReplImpl.java. This takes the command line argument and passes it through the JShell api's. Sort of verifies it works this way. It does. I would like to have an avialable default REPL for the HalfPipe application. Still, might work on my own sometime, maybe allow switching between the two. For new though, although, I've seen changes related to JShell going through the jigsaw project it doesn't appear to be available. Since I would still prefer to look into the modular aspects for now I'll probably not do much more with JShell.
By way of actually adding a little bit new. I am still sort of interested in the choice of
dot for the jdeps file format. So using the antlr DOT grammar[1].
I figured out how to generate the lexer/parser and came up with dot.zip
Used something like...
cat ~/dotfiles/halfpipe.jar.dot | java -cp .:antlr-runtime-4.5.1.jar Test
Resulting first in a print of the antlr parse tree like the usual test does...
(graph digraph (id "halfpipe.jar") { (stmt_list (stmt...
Then a little modular jdk/jdeps customized printing...
AudioTester -> module {java.desktop}
AudioTester -> module {java.base}
AudioTester -> utillib.sound.SampledAudioClip
TerminalMonitor -> module {java.base}
TerminalMonitor -> module {java.sql}
alias -> module {java.base}
alias -> utillib.psuedoGestalt.GestaltEnv
asp -> module {java.base}
asp -> org.cmdline.exec.ExecutableInterface
asp -> org.cmdline.exec.RuntimeExecutable
This includes a little code from my earlier JRTLister to do module lookups. It seems to me jdeps has all the information you would need to automate creation of your module-info classes. This has probably occurred to others or maybe reasons it's not such a good idea have occurred to them.
Anyhow, it for now