Re: [Jamvm-general] More problems (Resources this time)

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

 



Hi,

On Fri, Aug 15, 2008 at 10:20 AM, Jon Senior <jon@xxxxxxxxxxxxxxxxxxx> 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
> Jamvm-general@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/jamvm-general
>


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

  Powered by Linux