in our program we have to read a file (around 10MB) and decrypt it, I am using the following class.
it WORKS when I run it from eclipse, but when I generate the JAR file(export) and run it from command line (`java -Xmx1280M -jar app.jar`), it doesn't read the data correct.
The block size(crypt block size) is 4096, so the size of file is dividable by 4096, I really don't know why this happens! it SHOULD read 4096 bytes of data each time(line 33), but it doesn't, and always the data availability is more than 4096(as should be).
please help, what are the possible errors or situations would occur here?!
There is no reason why the code to decrypt a file would work in Eclipse and not work when in a jar assuming you are passing exactly the same file to the application in both cases. There are reasons why an application might work in Eclipse but not from a jar and they are generally to do with classpath and current working directory issues.
I suspect you code is failing but because you are catching exceptions and not printing out an stack traces you aren't seeing what the issues are. Hiding exceptions in this way is very bad practice as you are effectively throwing away a very useful tool in helping you debug your code. I suggest you make sure all your exception handlers in the whole application dump a stack trace at the very least then build the jar and run your application again and cut and paste any exception trace traces here.
Joined: Dec 11, 2013
Many thanks Tony
Well there is no exception, I really don't get any exception.
and I know the classpath and external dependencies are same in both eclipse and jar file, the problem is in this line
in jar file it doesn't read full 4096 bytes of data (4090, 4086, 4093, ...), someone said ( here ) that the read(byte buff) method doesn't guarantee that returns the requested data length,, but javdoc doesn't mention it.
This is really weird! there is no exception, but the only error is that in jar mode, it doesn't read 4096 bytes of data.
Joined: Aug 07, 2007
parsa porahmad wrote:someone said ( here ) that the read(byte buff) method doesn't guarantee that returns the requested data length,, but javdoc doesn't mention it.
Yes they are correct, I hadn't looked in detail at your code and had assumed it was an exception that you were hiding.
BTW the docs do mention that, they say "Reads some number of bytes from the input stream and stores them into the buffer array b. The number of bytes actually read is returned as an integer. "
ie There is no guarantee the buffer will be filled. If you need to handle exact sized chunks you need to read the data into a buffer of your own and then handle the chunk when you have enough in your buffer.
Many Many thanks, if I am being honest I haven't(couldn't) check the solution I've got, but as you mention it again, if I use the DataInputStream#readFully() if will fill up the array?! and one strange thing, why it doesn't fill the array in jar mode? what is the difference between jar and class mode? I mean it works very well without any error or exception when I run it from eclipse, but doesn't work probably in jar mode, and another question is, why doesn't it fill up the array while there is to much data is available.
many thanks dear, many thanks.
Joined: Aug 07, 2007
if I use the DataInputStream#readFully() if will fill up the array?
Yes, that method blocks until the array is full, the end of stream is reached or some other error occurs so you will either get a full array or an Exception. Remember to catch and handle the Exceptions.
I mean it works very well without any error or exception when I run it from eclipse, but doesn't work probably in jar mode, and another question is, why doesn't it fill up the array while there is to much data is available.
I don't know for sure but the contract for read() is to put some bytes into the array and tell you how many bytes have been read in so if I/O blocks for any reason the method will return immediately regardless of how many unread bytes there still are. There are many reasons it could be working in Eclipse but not the Jar such as Eclipse is buffering the file so I/O isn't blocking, the code is running slightly slower in Eclipse than from the jar so it isn't ever waiting for the next byte from the file etc etc.