Blackberry JDE generating bad .jad file (does not match compiled .cod file) - java

I Have a BB application that gets compiled into 3 siblings cod file. ( actualy one cod fil contaning 3 sub cod files).
app.cod
|--app.cod
|--app-1.cod
|--app-2.cod
which is normal.
the jad refers to those 3 inner .cod files.
Now I have add some feature to my app, it is getting a little bit bigger.
the jad now refers to 4 inner .cod files.
but there is still 3 inside the app.cod that is generated.
so I now still have
app.cod
|--app.cod
|--app-1.cod
|--app-2.cod
but with the jad referring to app.cod, app-1.cod, app-2.cod, AND app-3.cod.
this is causing OTA download to fail with the following error:
907 invalid COD HTTP Error 404 : not
found
what is wrong the my compiled program? is it a bug from the JDE?
I am using JDE 4.5

My assumption is that somehow the jad builder got confused, and maybe it gained a little more space in compression than it expected? either add another image to you application to make it a little larger or you can use
updateJad.exe app.jad
this will update the sizing of the jad file to match everything.
the file is located in the /bin folder with javaloader and other files of your JDE install.

Related

Trouble Understanding/Locating a Jar file (JIDT package) needed for Octave to Java Array Conversion

In this previous question, I was trying to rework some Matlab code and figure out a package called javaplex to be compatible with Octave; it uses Java, but is tooled for Matlab, hence that issue. Now in an interval of time, I was busy/running simulations, and hadn't gotten around to a final step - actually using the package, with most all of the difficulties worked out. It turns out that another step exists: I need to convert an Octave array to a Java array (although I'm not sure why this issue didn't come up in Matlab).
To do so, I have turned to this script, in which the comments indicate that when using it, it
Assumes the JIDT [Java Information Dynamics Toolkit] jar is already on the java classpath - you will get a java classpath error if this is not the case.
So I go to the JIDT GitHub page and download this package. Now I am not a very avid user of java, so I believe I am failing to see something fairly straightforward: I am not sure where the "JIDT jar" is that is referenced in the above block quote! I can't find such a particular jar file to put in Octave's java classpath. In this tutorial for JIDT, they say you need the "infodynamics.jar" file in the classpath (page 9). I'm not sure what jar file I should be looking for, and where. Any help understanding the nature, name and location of this jar file (within the infodynamics toolkit folder) would be appreciated!
As an inevitable follow-up question, because this will come up upon resolving this issue, I would like to clarify the following procedure is how to add a jar file to the Octave (static) java classpath (following this answer here, I wasn't sure if I was implementing correctly):
I create a file called "javaclasspath.txt" inside of the directory I use in Octave.
I enter the name of files as follows: "./path/to/your-file.jar"
I suppose my main issue here is where do I start the path (all the way back with "C:/..."?), and do I put this "javaclasspath.txt" file in the directory folder I will be using most of the time in Octave?
Edit: I cannot find "infodynamics.jar" as shown here:
The JIDT jar is named infodynamics.jar and it is located in the root of the downloads infodynamics-dist-1.4.zip file.

Problems running Java from Atom

I currently don't have a working way to edit and run Java on my computer, so I'm trying to get Atom working with Java (I realize it's not a Java IDE and I'm not trying to make it one, I just want to be able to do some light Java work on my laptop). I've installed the script and instant-build packages for Atom and wrote the following test code in a file called "main.java' in my project folder:
class Main{
public static void main(String[] args) {
System.out.println("please");
}
}
When I try to run the code with cmd+i (I'm on a 2012 MacBook Pro) and get the following error message:Error: Could not find or load main class main.
I'd be happy to provide any further information; thanks for helping!
The huge problem of learning Java is that you need to launch the projects in a very strict way, and setting the classpath is always problematic. The solution lays in the following (pretty enigmatic) line of the "Script" documentation:
Project directory should be the source directory; subfolders imply packaging.
So, instead of opening a plain file, open the project (folder) with .java classes or define inside the file, the package to which your .java belong.
It's due to the fact that JDE needs to create a virtual target in form of .classess and single .java file definitely can't be launched as standalone file. I suppose that "Script" is not able to locate the source folder when you try to execute seperate .java file.
Before launching your .java files always "Add Project Folder..."
Please remember that it's not possible to have several folders opened if they don't belong to the same project. Such situation cause problems of locating the right classpath and in the end javac prompts the error.
You have to name your file with the first letter in upper case Main.java, since it must match the name of your class
I replicated the issue quite easily. If I created a new directory in Atom itself and then tried to run the code it didn't work as your error message came up for me as well. Error: Could not find or load main class main.
I used an existing directory and then created a file inside that folder in Atom and ran the same code it worked. I then copied and pasted that same file into the directory of my choice and it worked.

HP Fortify 4.3 - Line Numbers in Findings Not Synchronized with Code

A colleague of mine recently ran a scan of a code base using HP Fortify 4.3 using an HP Fortify 4.3 installation on his computer.
When I opened the .fpr file in my HP Fortify 4.3 installation, the line numbers in the issues do not always match the lines in the code window when I double-click on the issue.
For example if an issue is reported in line 214 of a particular Java class, when I double-click the issue to view it in a code window, the highlighted line 214 doesn't contain the reported issue. It might instead be on line 205.
This doesn't happen with every source file.
What might be the cause? I assume the .fpr file contains a snapshot of the code that was audited. If that's true, then why would the line numbers not be in sync when I open the file in my Fortify installation?
Thanks in advance!
Yes the .fpr file does contain a snapshot of the code that was audited. But that is not its first choice Fortify uses when displaying code. (The source code is zipped up, so that is not used for performance reasons [I think]). If you have a copy of the source code on your machine that is in the same location as the code your colleague scan, Fortify will use that. And it may be that the source code has changed since the scan.
When Fortify goes to display source code and cannot find code at the external path of the scan, it will then display a message:
The current source path is invalid, but the project contains a copy of
the scanned source code. Would you like to extract the source code to
a location on disk, or update the path to an existing location?
With three options:
Use Source Included in FPR
Cancel
Update Path
If you want exactly what was scan then choose the first option
If you want it to point Fortify to the location of the source code on your system use the third option.
If you want it to use the internal source then do the following
Open the FPR
Do Tool -> Extract Source Code
Pick a location
When you do this, Fortify will automatically start using that location to pull the source code for display.

Unable to extract ZIP file created with Python using zipfile.ZIP_DEFLATED compression method

I have two programs (one in Java and one in Python) that ZIP a folder, upload it to a WebServer and trigger a UNZIP method on them.
The Java version of the program works without issues and the file is extracted on the server without problems.
Here I'm using the ArchiveStreamFactory class i.e. new ArchiveStreamFactory().createArchiveOutputStream(ArchiveStreamFactory.ZIP, this.currentOutputStream);
The Python version only works if I use zipfile.ZIP_STORED method (which does not compress the file). If I use the zipfile.ZIP_DEFLATED method I get internal server error.
I don't have access to the server so for this I can only rely on what I'm able to figure out on my side.
The Java program does seem to use the ZIP_DEFLATED method also as the archive is compressed (smaller) and not just stored.
I've also run zipinfo on the both archives (the one created with Java and the one with Python with DEFLATE - which doesn't work) too see what's different.
Here's the output:
# Java
-rw---- 2.0 fat 14398 bl defN 4-Jun-15 13:55 somefile.txt
# Python
-rw-r--r-- 2.0 unx 183 b- defN 28-Jun-15 21:39 someotherfile.txt
Both seem to be compressed with DEFLATE (defN) method so why does the archive generated by Java works while the one generated by Python doesn't?
So after a lot of debugging and trial and error looks like I found the issue in case anyone else is interested or will have the same problem.
I was also adding the folder to the zip and looks like it didn't liked the folders being compressed with ZIP_DEFLATED. What I did was to manually set the compression to ZIP_STORED for folders and to ZIP_DEFLATED for files and after this it worked. Interesting how Java knew to do this automatically behind the scenes, or at least I guess it does as the Java version is kind of the same (iterate over folders/files and add them to the ZIP) except I just use the default values (so I never explicitly set the compression type for anything).
So basically my code (the version that didn't worked) was something like this:
for dir_path, dir_names, file_names in os.walk(absolute_folder_path, compression=zipfile.ZIP_DEFLATED):
...
# Add folder to ZIP
f_zip.write(absolute_dir_path, arcname=relative_dir_path)
for file_name in file_names:
...
# Add file to ZIP
f_zip.write(absolute_file_path, arcname=relative_file_path)
and the fix was this one:
for dir_path, dir_names, file_names in os.walk(absolute_folder_path):
...
# Add folder to ZIP
f_zip.write(absolute_dir_path, arcname=relative_dir_path, compress_type=zipfile.ZIP_STORED)
for file_name in file_names:
...
# Add file to ZIP
f_zip.write(absolute_file_path, arcname=relative_file_path, compress_type=zipfile.ZIP_DEFLATED)

rJava Cannot add to classpath [duplicate]

I'm trying to use R to hook the Java code from the GSRad project. The GSRad Java code is available online and comes as a One-Jar project jar (I was not familiar with One-Jar until today). I can run the One-Jar file just dandy using the following command (after unzipping the file from the above link):
java -jar gsrad_sample.jar
When I pop open the gsrad_sample.jar file I see a jar titled clima_GSRAD-1.0.0.jar in the /lib/ directory which contains the class files I want to hook with R. I've pulled out the jar of my affection and tried the following, to no avail:
library(rJava)
.jinit()
.jaddClassPath( "/home/jal/Documents/DSSAT/gsrad/clima_GSRAD-1.0.0.jar" )
.jnew( "cra/clima/gsrad/GSRBristowCampbellStrategy" )
Any tips on how I might hook the classes inside the clima_GSRAD-1.0.0.jar? I'm flummoxed.
EDIT
The GSRad site requires registration which is annoying. The full zip file which contains the Doxygen documentation for the Java package as well as the One-Jar jar file is available here and if you pop that open the jar that has the classes I want to hook is this one.
Let me preface my answer by saying that I'm no expert in Java / rJava, so apologies if this isn't 100% correct. I hope it's a step in the right direction though.
Start by unzipping gsrad_sample.jar to C:/gsrad (or adjust your paths based on where you unzip it). Then add all the contents of C:/gsrad/lib to your class path:
library(rJava)
.jinit()
.jaddClassPath(dir( "C:/gsrad/lib", full.names=TRUE ))
.jclassPath()
.jnew( "cra/clima/gsrad/GSRBristowCampbellStrategy" )

Categories

Resources