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.(FTPConnection.java:253)
> at gnu.java.net.protocol.ftp.FTPConnection.(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.(Calendar.java:508)
> at java.util.GregorianCalendar.(GregorianCalendar.java:237)
> at java.util.GregorianCalendar.(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 wo
