Another one several of you have asked about...JRuby running on Java ME: http://gist.github.com/71393 This is using Sun's reference implementation "cvm" with the CDC (Connected Device Configuration) and the PBP (Personal Basis Profile) set of classes. It's basically the same as what you'd have on a Java ME-enabled phone or embedded device supporting the same level of APIs. PBP is available here, for Linux only. I'm not sure whether it's been open-sourced yet or not, but I thought it was planned: http://java.sun.com/javame/downloads/index.jsp The project is hosted here: http://github.com/headius/jruby-cdc/tree/master It's essentially JRuby 1.2 forked and stripped of libraries and code that aren't supported in CDC. My intention with this is to get it running with a base set of Ruby classes but with Java integration still functional. That will allow most basic Ruby scripts to work while providing access to the rest of the Java APIs for bits I had to rip out. It's only running interpreted right now, just like the Android version of JRuby, but as in that case I expect most people would want to precompile Ruby code and ship it all as one unit. I think there are many other possible ways we could repurpose JRuby like this; it really only took me a couple days of trimming to get this far. Android will take far less time, and other "mini ruby" profiles might be possible for other platforms as well. Questions, comments, patches welcome :) - Charlie
on 2009-02-27 11:25
on 2009-02-27 12:01
Hi Charlie, That's great news! I was wondering about this again since I saw the post about JRuby on Android. I've been trying to figure out the best way to get Ruby on my Windows mobile phone so I could do some quick scripting without needing to go through the compile process for either J2ME or WinMobile/.NET CF, because I don't have those set up at the moment. Looks like this may be just the thing I need to test a couple of things. Cheers, ast
on 2009-02-27 22:12
Charles Oliver Nutter wrote: > open-sourced yet or not, but I thought it was planned: > still functional. That will allow most basic Ruby scripts to work > profiles might be possible for other platforms as well. > > Questions, comments, patches welcome :) > > - Charlie > This would be awesome!
on 2009-03-05 23:39
From: "Charles Oliver Nutter" <email@example.com> > > I think there are many other possible ways we could repurpose JRuby like > this; it really only took me a couple days of trimming to get this far. > Android will take far less time, and other "mini ruby" profiles might be > possible for other platforms as well. This idea of a stripped-down JRuby running precompiled Ruby code, still able to access Java APIs sounds ideal for applets. Do you think it would be a lot of work to target one of these "mini rubys" for applets? This gentleman currently has an OpenGL / JRuby applet proof of concept -- but has he points out, the complete JRuby jar is large and implies a lengthy download: http://sikanrong.com/blog/jruby_applet__opengl_run... I think it would be awesome to have a compact JRuby runtime for use in applets. I don't see requiring the ruby code to be precompiled to be a problem at all. (Perhaps even a benefit.) Regards, Bill
on 2009-03-06 01:11
Bill Kelly wrote: > This idea of a stripped-down JRuby running precompiled Ruby code, > still able to access Java APIs sounds ideal for applets. > > Do you think it would be a lot of work to target one of these "mini rubys" > for applets? Yes, and I have applets firmly in mind as I start thinking about modularizing/stripping/shrinking JRuby. Applets are a little less restrictive than either JavaME or Android, since we'll have a "full" Java impl, but we still need to make things more modular and make it easier to ship only what you need. I suspect the same logic will apply equally to applet and Android deployments (jruby-cdc is a separate fork for JavaME that will live a life of its own). - Charlie
on 2009-03-06 03:21
Bill, What would be the "sweet spot" for applets? I acknowledge my prejudice, reluctantly accepting that memories of ancient rants about "craplets" are not just a bad dream. Peter Booth (917) 445 5663 firstname.lastname@example.org
on 2009-03-06 05:25
on 2009-03-06 06:52
On Thu, Mar 5, 2009 at 9:23 PM, Bill Kelly <email@example.com> wrote: > Simple 3D example (gears demo) > https://jogl-demos.dev.java.net/applettest.html > glxgears in an applet! It's all bugged out though, at least in Firefox/Mac. When I switch tabs the gears are still there... and even though it claims the applet doesn't need to be signed I get a warning saying the signing certificate is invalid and asking if I want to make an exception.
on 2009-03-06 08:56
From: "Tony Arcieri" <firstname.lastname@example.org> > gears are still there... and even though it claims the applet doesn't need > to be signed I get a warning saying the signing certificate is invalid and > asking if I want to make an exception. Hmm... I'm seeing the same thing on Firefox/Mac. :( It works fine for me on Firefox/Windows and (surprisingly) IE6/Windows. It works OK for me on Safari/Mac (it does ask if I want to trust the applet, but it says the cert is valid.) No tab problems on Safari/Mac or Firefox/Windows... but, I get the tab switching issue you described on Firefox/Mac. Sigh... always something. <grin> (I tried submitting a bug to Sun, but they only accept Java bugs for Windows/Linux/Solaris. Submitted to Apple instead.) Regards, Bill
on 2009-03-06 09:38
Bill Kelly wrote: > (I tried submitting a bug to Sun, but they only accept > Java bugs for Windows/Linux/Solaris. Submitted to Apple > instead.) FWIW, the JavaFX guys sound hopeful that Apple will release Java updates including the many improvements Sun's made for JavaFX. This will obviously help JavaFX, but also could greatly improve graphics performance and startup speed of applets in general. I hope they're right. People keep telling me JavaFX and/or applets are superfast on recent Windows Java 6 releases. - Charlie
on 2009-03-07 09:55
Bill Kelly wrote: > But -- of course -- I'd much rather code an app like > this in Ruby, than Java... :) Consider Clojure.