[LEDE-DEV] [OpenWrt-Devel] Adding host Java support to the buildbots
ralph.sennhauser at gmail.com
Mon Jan 2 00:22:08 PST 2017
On Fri, 30 Dec 2016 06:52:32 -0800
Dana Myers <k6jq at comcast.net> wrote:
> On 12/29/2016 11:50 PM, Ralph Sennhauser wrote:
> > Hi Dana
> > On Thu, 29 Dec 2016 12:30:37 -0800
> > Dana Myers <k6jq at comcast.net> wrote:
> >> In reference to https://github.com/openwrt/packages/pull/3686
> >> We've added OpenWRT support for:
> >> * JamVM 2.0: Java JVM
> >> * GNU Classpath 2.0: Java class library
> > There is no classpath 2.0
> Right you are - serves me right for spewing version numbers off the
> top of my head from something I initially did two years :-) It's
> classpath 0.99
> >> * RXTX Java serial communications library
> >> However, the build bots won't build these packages yet because
> >> a host Java compiler is required. To build these packages, I
> >> install:
> > The main reason to use jamvm with gnu classpath is you can
> > bootstrap it without a jdk, right? If you already require a host
> > jdk why not go for jamvm with the openjdk classpath to get full
> > java support?
> I don't understand the question about bootstrapping and host vs
> target JDK. Host JDK is used specifically for javac to compile Java
> to bytecodes; target has no dependency on JDK otherwise.
Well, if you require openjdk-7-jdk on the build host you sidestep
bootstrapping java all together (c compiler & source code -> build) in
which case jamvm with openjdk classpath is as easy to get as with gnu
classpath but the latter only supports part of 1.5 & 1.6.
The question boils down to why you settle for something inferior when
you can have something much better.
> Classpath was, for many years, the only library supported by JamVM,
> is much smaller than OpenJDK (valuable on resource-constrained
> systems) and remains the default library supported by JamVM. For the
> purposes of my project from which I contributed, Classpath is
> adequate and appears to avoid concerns about encumbrance of the
> target builds/devices with OpenJDK. Most specifically, however, was
> the apparent lack of support for MIPS32 which is a show-stopper for
> the AR71xx architecture I'm using.
Another alternative to hotspot on mips would be cacao, again with
openjdk classpath. Though jamvm certainly is a vaild pick.
What encumbrance concerns do you have in mind? Debian also ships the
binaries as in openjdk-7-jdk.
I don't object to jamvm with gnu classpath, just that I was wondering
why you'd pick it over the alternatives. Basically it's adding java
support that is hardly usable this days apart of a few specialized
More information about the Lede-dev