Where does the Java Card "Converter" Tool look for EXP files? - javacard

using the JavaCard Converter tool, I kept getting errors like
error: export file rmi.exp of package java.rmi not found.
and
error: export file framework.exp of package javacard.framework not found.
The errors disappeared gradually after I copied the directories beneath
/usr/local/javacard/java_card_kit-2_2_2/api_export_files
to the local directory. Now, that's clearly a hack. No, calling this a 'hack' would be an insult to just about any other real hack. This is clearly not how things are supposed to work, right?
So, how do I tell the converter tool where it should be looking for the .exp-files?
And, yes, I've set JC_HOME=/usr/local/javacard/java_card_kit-2_2_2, too.

Quote from Java Card 2.1 Development Kit User’s Guide - November 15, 1999 document:
"
You can use the -exportpath command option to specify the locations of export
files. The path consists of a list of root directories in which the Converter looks for
export files. Export files must be named as the last portion of the package name
followed by the extension .exp. Export files are located in a subdirectory called
javacard, following the Java Card directory naming convention.
For example, to load the export file of the package java.lang, if you have specified
-exportpath as c:\myexportfiles, the Converter searches the directory
c:\myexportfiles\java\lang\javacard for the export file lang.exp.
"
I suppose it should apply for 2.2.2 too.
So use appropriate -exportpath option for converter to point to your exp files and be sure the javacard subdir is created under the package dir for holding exp files.

Related

Passing params from the build system to buildbot

I'd like to share how I implemented a solution to a problem I had, to get some feedback and maybe learn some new feature of buildbot.
Scenario:
Create a package of a given software, and upload the package to the buildmaster into a shared folder.
The package name contains some data that are known to the build system (i.e. Makefiles) specifically the sw version. Let's assume the package name is:
myapp-1.2.3-r2435.tar.gz
Question:
How do I send to the buildslave steps the required to build up the very same package name, so that the buildslave can upload the package?
Specifically I need to know the version number (but I guess this could be any param)
Implemented (and working) solution:
The makefile, once the compilation process is completed, writes a file with the required param.
The slave uses the SetProperty() step to read the content of the file into a custom named property
Once I have the value of interest in the property (let's say APP_VERSION) I use it to build the package name with the same pattern used by the build system.
The described solution works, but I do not really like it because:
1) it's complicated, hence, I guess, fragile
2) it is not OS independent (I use "echo $VAR > file" to write the file, and "cat file" to read it and set the buildslave Property)
Is there in your opinion a better way to solve this issue?
Do you have any suggestion to make the solution OS independent? (It will not work for sure on Windows, while my package shoudl be built on Windows OS too)

Android Studio - Include ResourceBundles in Module

I currently switched from eclipse to android studio. In eclipse I had 2 projects, one android application project and one java project which I included in the android project as library. This java project uses ResourceBundles to create internationalized error messages for it's own errors. This has been my project structure:
/MyApp
/src
/res
...
/MyLibrary
/src
/res (added as source folder to build path)
/loc
Bundle_en.properties
This worked when loading the RessourceBundles as following:
ResourceBundle.getBundle("loc.Bundle", Locale.ENGLISH);
Now I switched to android studio and my new project structure looks like this (added the java library as module):
/MyProject
/MyApp
...
/MyLibrary
/src
/main
/java
...
/res
/loc
Bundle_en.properties
But I'm not able to load the ResourceBundles anymore, it's just throwing a java.util.MissingResourceException. I tried a lot of different locations for the ResourceBundles and different paths but I'm going to get crazy because nothing seems to work. Could anybody explain where to put those bundles and how to load them?
Thank you!
Faced exactly the same problem. To make it work I finally had to create a resorces folder in my project module's main folder.
here multiple files starting with the same name (as messages in this picture) gets bundled as a resource bundle.
Finally had to call it using
ResourceBundle.getBundle("org.eclipse.paho.client.mqttv3.internal.nls.logcat")
or
ResourceBundle.getBundle("org.eclipse.paho.client.mqttv3.internal.nls.messages")
to get the required resource.
If you include the second project as a library, you might not want to create a new resource folder as suggested in a previous answer (which does work). Instead, you can simply add the library's resource folder to your resource directories in your module's build.gradle: to the android section add
sourceSets {
main.resources.srcDirs += 'path/to/your/libs/res'
}
If now the added res folder contains org/mypackage/Bundle.properties you can refer to it using
ResourceBundle.getBundle("org.mypackage.Bundle")
Actually adding a new resource folder does nothing more then adding it as a resource directory in build.gradle.
I never tried but Intellij comes with very good integration of Resource Bundles.
Refer this link
http://www.jetbrains.com/idea/webhelp/resource-bundle.html
From the link above
Resource bundle is a set of properties files that have same base name
with different language-specific suffixes. A resource bundle contains
at least two properties files with similar base name, for example
file_en.properties and file_de.properties.
IntelliJ IDEA recognizes properties files, and if two or more
properties files with the names that differ only in suffix, are
encountered, joins them into a resource bundle. The new node Resource
Bundle '(base name)' appears in the Project Tool Window:
You can have these files inside your module or on root as well.
First please ensure your resource folder (where the property file is localted) is in the classpath and you can easily find that by calling the following.
URLClassLoader ldr = (URLClassLoader)ClassLoader.getSystemClassLoader();
URL[] urls = ldr.getURLs();
for(URL url : urls)
{
System.out.println(url.getPath());
}
Now if you find your resources folder in the classpath then you can simply call the bundle base name, in your case ResourceBundle.getBundle("Bundle"), no need for a fully qualified path. Assuming you are using English locale, it should find it. You can further add en_US, en_NZ, en_GB etc if needed.
If you do not find your property folder then make sure it is in the classpath and if you need to add it dynamically follow this thread.
How do you change the CLASSPATH within Java?
Remember the only addition for loading property files dynamically is that you MUST call findResource or findResources API on the class loader to load the property file. Hope this helps.

Using Bouncy Castle library causes massive increase in output .jar file size

I'm working on a Java ME/J2ME project which makes use of the Bouncy Castle J2ME library. When adding it to my project, however, I've noticed the resulting .jar file size increases 40 times (50kB vs. 2000kB). Other than setting ProGuard's obfuscator settings to level 9 (max), is there any other way I can minimize this increase in file size?
I'm only using a few of the libraries actual classes, namely:
import org.bouncycastle.util.encoders.Hex;
import org.bouncycastle.crypto.Digest;
import org.bouncycastle.crypto.macs.HMac;
import org.bouncycastle.crypto.params.*;
import org.bouncycastle.crypto.digests.SHA256Digest;
Thanks in advance.
Now this is a very tricky one!
Before anything else please can you unzip your jar file and see if the Proguard has obfuscated the class files of BouncyCastle? Since you have included bouncycastle jar file as a library and there are class files in it so I am assuming the Proguard hasn't obfuscated these class files which are taking much of the space.
Anyways I have just downloaded the bouncy castle jar file and can see it is purely made up of class files, so there are no extra files which we might be able to delete and get rid of to reduce the resultant jar file.
Now If you really want to reduce then read on I am going to produce two solutions, both of them are risky:
Solution 1 (Not Recommended):
This is easy but I wouldn't recommend, It may cause runtime exceptions or errors:
Unzip the bouncycastle jar file. Then navigate to the directory src\org\bouncycastle
As you have mentioned you are only using these below packages
org.bouncycastle.util.*
org.bouncycastle.crypto.*
Now here I will be assuming that the source code inside these two packages is not dependant on the source code/class files inside other packages.
Now delete the other directories namely "asn1", "bcpg". At this stage I will not become a butcher and delete everything but will go by deleting a couple and then come back and delete others if it worked.
Now we will regenerate the jar file. After you have deleted the directories now go back to the root of the directory where you will see other directories like
META-INF
org
utils
This is an important step you need to this correctly otherwise jar file will not work. Select all the directories in the root directory and
then right click-> send to zip
Once the zip file is created then rename it to having *.jar instead of *.zip
The size of the jar file would have reduced and now include this jar file in your project. See if it compiles and executes. Then check
your functionality if it is working correctly at Runtime. If all goes fine, then you are done.
Now you can repeat from above steps to delete further directories to reduce the jar file size.
Solution 2:
Download the source code of the bouncycastle jar file that you are using.
You will have to remove the jar file from the project.
Include the source code into the project. Build the project and see if you dont get any compilation error. You have to be sure at this stage
that you are not using the original jar file, and only using the code.
Now start deleting the packages containing code that you dont need. Keep rebuilding the project that it doesn't come up compilation error,
and if it does then you dont want to delte that package and move on deleting others.
Once this butchring is done then Build the project and generate the jar file.
By this way the Proguard will obfuscate code of bouncy castle and because of deleting most of the code not needed you should get a substantial
decrease in the resultant jar file.

Does there exist similar thing as #'asdf:system-relative-pathname in CL?

In Common Lisp, we can use
(namestring (asdf:system-relative-pathname 'money "money.dat"))
to get the absolute path of money.dat. It is VERY convenient as this data file is position independent.
Suppose there is a Money.hs module which manipulates a data file money.dat in the same directory DIR-1. Because it is using relative path, i have to cd DIR-1 to make money.dat visible to this module. Now if I ghc-pkg register this module, can I make money.dat visible to Money.hs no matter where the current directory is ?
As per hammar's comment, we can set up a data-dir in our .cabal file which contains data files that get deployed when a package is cabal install'd. Then, using the instructions in the Cabal manual we can programmatically access those files from our installed libraries.

On GNU/Linux systems, Where should I load application data from?

In this instance I'm using c with autoconf, but the question applies elsewhere.
I have a glade xml file that is needed at runtime, and I have to tell the application where it is. I'm using autoconf to define a variable in my code that points to the "specified prefix directory"/app-name/glade. But that only begins to work once the application is installed. What if I want to run the program before that point? Is there a standard way to determine what paths should be checked for application data?
Thanks
Thanks for the responses. To clarify, I don't need to know where the app data is installed (eg by searching in /usr,usr/local,etc etc), the configure script does that. The problem was more determining whether the app has been installed yet. I guess I'll just check in install location first, and if not then in "./src/foo.glade".
I dont think there's any standard way on how to locate such data.
I'd personally do it in a way that i'd have a list of paths and i'd locate if i can find the file from anyone of those and the list should containt the DATADIR+APPNAME defined from autoconf and CURRENTDIRECTORY+POSSIBLE_PREFIX where prefix might be some folder from your build root.
But in any case, dont forget to use those defines from autoconf for your data files, those make your software easier to package (like deb/rpm)
There is no prescription how this should be done in general, but Debian packagers usually installs the application data somewhere in /usr/share, /usr/lib, et cetera. They may also patch the software to make it read from appropriate locations. You can see the Debian policy for more information.
I can however say a few words how I do it. First, I don't expect to find the file in a single directory; I first create a list of directories that I iterate through in my wrapper around fopen(). This is the order in which I believe the file reading should be done:
current directory (obviously)
~/.program-name
$(datadir)/program-name
$(datadir) is a variable you can use in Makefile.am. Example:
AM_CPPFLAGS = $(ASSERT_FLAGS) $(DEBUG_FLAGS) $(SDLGFX_FLAGS) $(OPENGL_FLAGS) -DDESTDIRS=\"$(prefix):$(datadir)/:$(datadir)/program-name/\"
This of course depends on your output from configure and how your configure.ac looks like.
So, just make a wrapper that will iterate through the locations and get the data from those dirs. Something like a PATH variable, except you implement the iteration.
After writing this post, I noticed I need to clean up our implementation in this project, but it can serve as a nice start. Take a look at our Makefile.am for using $(datadir) and our util.cpp and util.h for a simple wrapper (yatc_fopen()). We also have yatc_find_file() in case some third-party library is doing the fopen()ing, such as SDL_image or libxml2.
If the program is installed globally:
/usr/share/app-name/glade.xml
If you want the program to work without being installed (i.e. just extract a tarball), put it in the program's directory.
I don't think there is a standard way of placing files. I build it into the program, and I don't limit it to one location.
It depends on how much customising of the config file is going to be required.
I start by constructing a list of default directories and work through them until I find an instance of glade.xml and stop looking, or not find it and exit with an error. Good candidates for the default list are /etc, /usr/share/app-name, /usr/local/etc.
If the file is designed to be customizable, before I look through the default directories, I have a list of user files and paths and work through them. If it doesn't find one of the user versions, then I look in the list of default directories. Good candidates for the user config files are ~/.glade.xml or ~/.app-name/glade.xml or ~/.app-name/.glade.xml.

Resources