Re: J2SE compliant RE for Arm Linux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Andrew,

Thank you very much for your reply.

On Sun, 2007-06-24 at 22:18 +0100, Andrew John Hughes wrote:
> > As part of my switch to a new job, I've been trying to convince my
> > employers to switch from C++ to java on an embedded ARM based platform.
> >
> > However, in order for the switch to be reasonably painless, we will need
> > a J2SE compliant (although we don't need any GUI components) runtime
> > environment for the embedded platform. I've been looking at various
> > alternatives based on GNU classpath (as well as a few others). They
> > include jamvm, mika, PERC, kaffe, gcj and a few more. So far, none of
> > the the platforms I've been looking at (except PERC, which is
> > prohibitively priced) support J2SE 5.0. Thus, my question is, can you
> > provide me with a pointer to a J2SE 5.0 JRE (GNU classpath based or
> > otherwise) which will run on an ARM Linux platform?
> 
> Hi Søren,
> 
> It really depends what you mean by a 'J2SE 5.0 JRE' -- what particular 
> features have you found lacking in the solutions you've tried?  GNU Classpath 
> itself should support 95%+ of the 1.5 API, and, as of the 0.95 release, is 
> only buildable with a 1.5 supporting compiler.  Personally, I've been using 
> JamVM with 1.5 stuff for about the last three years.
>
> If there is something missing, please file a bug with the respective project 
> and let them know (GNU Classpath for library classes, the appropriate VM 
> otherwise).  Which version of gcj and kaffe did you try?  These projects 
> differ quite significantly between their current release versions and the 
> version in their source repositories, and don't (as yet) directly use GNU 
> Classpath, so there is some delay between code being written there and being 
> imported into their own local tree.
> 
> Hope that helps,

Thanks for your input.

JamVM and CACAO currently look to be the most promising candidates. I am
however having trouble with GNU classpath. Specifically, the
LinkedBlockingQueue and NetworkInterface classes. Hmm, I just now
realised that upgrading to Classpath 0.95 fixes the
NetworkInterface.getNetworkInterface() method.

Anyway, let me just run the error I am seeing by you, and if it's
genuine (and not due to a screw up on my part) I will file an
appropriate bug:

Running a simple program like this:

import java.util.concurrent.LinkedBlockingQueue;

public class LinkedBlockingQueueTest {
	public static void main(String[] args) {
		LinkedBlockingQueue<String> q = new LinkedBlockingQueue<String>();
		try {
			q.take();
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}
}

Results in the following error:

boll@mephisto:~/classes$ /usr/local/cacao/bin/cacao
LinkedBlockingQueueTest
Exception in thread "main" java.lang.IllegalMonitorStateException
   at java.util.concurrent.locks.ReentrantLock
$Sync.tryRelease(ReentrantLock.java:126)
   at
java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1139)
   at
java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:430)
   at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:368)
   at LinkedBlockingQueueTest.main(LinkedBlockingQueueTest.java:9)
boll@mephisto:~/classes$ 

I am using classpath 0.95 and cacao with the following options:

Configure/Build options:

  ./configure:
'--with-classpath-classes=/usr/local/share/classpath/glibj.zip'
'--with-classpath-includedir=/usr/local/include/'
'--with-classpath-libdir=/usr/local/lib/' '--disable-disassembler'
  CC         :  (4.1.2 (Ubuntu 4.1.2-0ubuntu4))
  CFLAGS     : -O2 -g3 -D__I386__ -D__LINUX__ -ansi -pedantic -Wall
-Wno-long-long -D_POSIX_C_SOURCE=199506L -D_XOPEN_SOURCE=500
-D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE

Default variables:

  maximum heap size              : 134217728
  initial heap size              : 2097152
  stack size                     : 65536

java.boot.class.path           : /usr/local/cacao/share/cacao/vm.zip:/usr/local/share/classpath/glibj.zip
  gnu.classpath.boot.library.path: /usr/local/lib//classpath

Runtime variables:

  maximum heap size              : 134217728
  initial heap size              : 2097152
  stack size                     : 65536
  libjvm.so                      : /usr/local/cacao/lib/libjvm

java.boot.class.path           : /usr/local/cacao/share/cacao/vm.zip:/usr/local/share/classpath/glibj.zip
  gnu.classpath.boot.library.path: /usr/local/lib//classpath
  java.class.path                : .

Again, thanks for your input.

-- 
Søren O.

"Oh, bother" said the Borg, "we've assimilated Pooh".




[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux