Java JAR run across platforms, Zip exception
Soterro
I'm trying to get a JAR file working on a VMS and a Windows machine
(Unix shall come later)
So I go and create the JAR file on the OpenVMS machine (JRE 1.4.1-2, VMS
7.3-2), everything works fine. I go and create the JAR file on Windows
(W2000, Eclipse 3.0.1 does that, JRE 1.4.2-03), then when I copy it over
to the VMS and I run the command:
$ java -jar mything.jar
I get:
JavaVM args:
version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 4
option[ 0] = '-Djava.class.path=.'
option[ 1] = '-Djava.class.path=mything.jar'
option[ 2] = '-Dsun.java.command=mything.jar'
1 micro seconds to InitializeJVM
Main-Class is ''
Apps' argc is 0
Exception in thread "main" java.util.zip.ZipException: error in opening
zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java)
at java.util.jar.JarFile.<init>(JarFile.java)
at java.util.jar.JarFile.<init>(JarFile.java)
The file is not corrupted, JAR is otherwise happy with it, it can list
and extract the classes and I can create then a fully working jar out of
the unpacked classes. It's just I can't run on VMS the version I get
from the Win machine. The Main-Class shows nothing, whatever that means
(although Manifest is there). The Win jar works fine on other Win
machines. I don't know anymore where to look, although it looks like
being something very basic (just an unzip...)
So I'm lost... Help?
S
Daniel Gustafsson
news:41766e8c$0$27334$4d4e...@read.news.ch.uu.net...
What does DIR/FULL x.JAR say ?
The file must be Stream_LF.
Run this after you transfer the file to VMS.
SET FILE x.JAR /ATTR=(RFM:STMLF,RAT:CR)
--
Daniel Gustafsson
http://developer.mimer.se
Gorazd Kikelj
Best, Gorazd
Bob Koehler
> I go and create the JAR file on Windows
> (W2000, Eclipse 3.0.1 does that, JRE 1.4.2-03), then when I copy it over
> to the VMS and I run the command:
jar files on VMS must be stream-lf format. Your FTP tool will
not do that. So first transfer it in binary, and then use
$set file/attribute=rfm=stmlf
David J Dachtera
Remember to transfer the .JAR file as *BINARY*!
> SET FILE x.JAR /ATTR=(RFM:STMLF,RAT:CR)
RAT is irrelevant, but harmless.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Soterro
oriented jar files, i was able to decompress the classes out of the jar.
The problem was when I tried to *run* them from the jar.
Bob Koehler wrote:
> jar files on VMS must be stream-lf format. Your FTP tool will
> not do that.
As also the others pointed, binary transfer (which I of course did) got
me nice 512 record files. The Zip classes of JRE chocked on that.
Now this is also a funny situation which is a VMS-only issue, if I
transfer a binary file aka. bit-by-bit copy, shouldn't I get at the FTP
output the same stream-oriented file? Or why is FTP deciding 'now you
want records' and where is it coming with the RMS attributes from? Or is
'binary' not a perfect copy?
S
Bob Koehler
The data copy is correct, that's why changing the file attributes
works (the LF meta-data is in there). FTP clients on VMS don't
really know what you want so they create local text files as
variable-length records and binary files as 512 byte blocks.
Exactly why Java tools have a heartache with this is something you'ld
have to ask the Java team about. The rest of us have always
wondered.
bri...@encompasserve.org
RMS attributes are "out of band" information. The FTP protocol has
no provision for out of band metadata. It just transfers file
contents in a canonical transfer format.
In the case of text files, the transfer format is (roughly):
Convert each line to ASCII
Put a <CR><LF> between lines
Shove it all down a TCP stream. End of stream means end of file.
The sender takes the local text file format and converts to canonical
form. The receiver takes canonical form and converts to local text file
format.
In the case of binary files, the transfer format is simpler yet:
Convert the file to a stream of bytes if neccessary
Shove it down a TCP stream. End of stream means end of file.
The sender ignores file metadata (if any) and shoves file contents down
the wire.
The receiver gets file contents from the wire and applies generic
metadata if needed.
The protocol definition gives no guidance on the conversion process.
In the Unix and Windows world, files are already streams of bytes
without metadata, so it's not an issue. In the VMS world, things
are trickier.
For good or ill, the typical binary file format that VMS file
transfer programs default to when receiving a file is 512 byte fixed
length records with null carriage control. This is the format that
VMS .EXE, .OLB and .TLB files are in and it's what all the other VMS
binary file transfer programs default to, so it is a reasonable choice.
RMS is smart enough to track end of file down to a byte offset within
the last record, so that part is not a problem.
If you use RMS to read a stream format file without using block I/O,
you won't get guaranteed data integrity. (Trailing nulls prior
to the record separator are automatically stripped by RMS when using
record oriented access to read stream format files). So stream_lf
is not an optimal choice for a file transfer program to use by
default.
The C RTL is smart enough to evade the RMS restrictions and provide
guaranteed data integrity when reading stream format files.
John Briggs
Daniel Gustafsson
"David J Dachtera" <djesys...@comcast.net> wrote in message
news:41769FAA...@comcast.net...
If the file had been transferred with FTP ASCII there would have been much
worse errors and the JAR file would have been totally unusuable. ;) In this
case there was a subtle error.
> > SET FILE x.JAR /ATTR=(RFM:STMLF,RAT:CR)
>
> RAT is irrelevant, but harmless.
OK.