Hi, On Fri, Aug 15, 2008 at 10:20 AM, Jon Senior <[EMAIL PROTECTED]> wrote: >>-----Original Message----- >>Jon, I'm sorry that I can't be very helpful, but I ran into very >>similar problems. >>I think if you search for my name in the JamVM or Classpath mailing lists, >>you'll find some messages from me about this problem. >> >>If I remember correctly, to get JamVM working, I had to unpack the >>resources and put the top-level resource directory in the bootclasspath. >> >>I seem to recall that someone (a JamVM or Classpath developer, >>I don't remember which) said that they would look into it. >>I don't know if anything ever came of it. Sure seems like a bug to me. >> >>Let me know if you think I could supply any info to help you. > > OK. The list of things that I have tried is as follows: > > - Using -Xbootclasspath/a:glibj-sm.zip > > This results in a failure to find the resource. > > - Using -Xbootclasspath/a:.:glibj-sm.zip with the resource directory unzipped > into the current directory. > > This results in the stack trace at the end of this email. > > - Using -Xbootclasspath/a:./full with the entire (complete) Classpath > unzipped into the directory full. > > This results in the stack trace at the end of this email. > > - Using -Xbootclasspath/a:glibj.zip > > This fails immediately with a ClassNotFoundException for java.lang.thread. > It's as if it's unable to find or open the full Classpath! > > This does seem somewhat buggy, but I can't see why. I've looked through the > GNU Classpath source in an attempt to work out what's going on and I can't > see why it's trying to use FTP to open the resource. Neither can I work out > why JamVM won't work with the "correct" classpath when it's zipped, but will > work with my minimal version. I'm guessing there's some weird memory problems > there. > > Any hints that you or anyone could offer would be greatly appreciated. >
I notice that you're using -Xbootclasspath/a:... This appends the entries to the end of the default bootclasspath; it does not replace it. The existing entries in the bootclasspath will be searched before the appended entries. Is it possible that classes/resources are being picked up from different places? To be sure of what is going on, it is probably better to replace the bootclasspath using -Xbootclasspath:... Alternatively you can use -Xbootclasspath/c:.. or -Xbootclasspath/v:... By default, the bootclasspath is made up of two things. Where to find JamVMs VM classes (normally in classes.zip) and where to find GNU Classpath's classes (normally in glibj.zip), e.g: /usr/local/jamvm/share/jamvm/classes.zip:/usr/local/classpath/share/classpath/glibj.zip -Xbootclasspath:... replaces everything. -Xbootclasspath/v replaces the VM classes location, leaving the default location of the GNU Classpath classes, while -Xbootclasspath/c does the opposite ('v' for VM classes, 'c' for Classpath or core classes!). As to the general problem I'm afraid I'm not much use. I don't actually run a huge amount of Java programs myself! I'm CC-ing this to the GNU Classpath list in case somebody on there can help. Rob. > java.nio.channels.UnresolvedAddressException > at gnu.java.nio.SocketChannelImpl.connect(SocketChannelImpl.java:160) > at gnu.java.net.PlainSocketImpl.connect(PlainSocketImpl.java:281) > at java.net.Socket.connect(Socket.java:454) > at java.net.Socket.connect(Socket.java:414) > at gnu.java.net.protocol.ftp.FTPConnection.<init>(FTPConnection.java:253) > at gnu.java.net.protocol.ftp.FTPConnection.<init>(FTPConnection.java:221) > at > gnu.java.net.protocol.ftp.FTPURLConnection.connect(FTPURLConnection.java:121) > at > gnu.java.net.protocol.ftp.FTPURLConnection.getInputStream(FTPURLConnection.java:165) > at java.net.URL.openStream(URL.java:737) > at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:733) > at java.util.ResourceBundle.tryBundle(ResourceBundle.java:481) > at java.util.ResourceBundle.tryBundle(ResourceBundle.java:550) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:400) > at java.util.Calendar.getBundle(Calendar.java:483) > at java.util.Calendar.<init>(Calendar.java:508) > at java.util.GregorianCalendar.<init>(GregorianCalendar.java:237) > at java.util.GregorianCalendar.<init>(GregorianCalendar.java:224) > at java.util.Calendar.getInstance(Calendar.java:612) > at java.util.Calendar.getInstance(Calendar.java:538) > at java.util.zip.ZipEntry.getCalendar(ZipEntry.java:225) > at java.util.zip.ZipEntry.setTime(ZipEntry.java:172) > at java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:222) > at com.gulfstreamsoftware.tdrouter.Controller.main(Controller.java:65) > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jamvm-general mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jamvm-general >