|
|
|
(With JBuilder) Install the Sun COMM API |
Note: change these paths to refer to your version of JBuilder such as d:\JBuilder7\jdk1.3.1\bin or whatever your actual path is. The version of JBuilder is largely irrelevent. We use JBuilder4, 5, 6, and 7 without problems. JBuilder is "just" a fancy user environment wrapped around the underlying Java JDK (this is located in a folder such as \JBuilder7\JDK1.3.1). The JDK is what actually does the work of creating class files, javadocs, etc, using standardized tools such as "javadoc", "javac", "jar", and so forth. IDE vendors such as Borland add value by wrapping their own editor, graphical screen layout tools, debugger, etc on top of the Sun JDK. You already downloaded the COMM API file, now extract the archive into a folder. I have enough Java libraries now that I started a folder on our server called "javalib" with subfolders such as "commapi", "onewire", "tini", "util", etc, so that we have one central repository for all these libraries. This way the library files are more easily maintained regardless of which JDK and/or IDE is in use on a given PC on the network. I copy the same "javalib" folder to our notebook PCs too, so that all our systems are set up in a similar fashion. Now in that folder (J:\java_lib\commapi for me) open the file PlatformSpecific.html, it has instructions for installing the commapi files. Here's the short version, edited for my case.
The javax.comm.properties must be in the correct directory. Failure to do this will result in JavaKit's inability to enumerate your PC serial ports - instead of COM1, COM2 etc, you will see 'serial0' which are just the name placeholders, not real serial ports. You can't actually access 'serial0' on the PC. |
(With JBuilder) Create a javakit.bat batch file |
You already downloaded the COMM API file, extracted, and
installed it, so now we can use it.
I prefer to not rely on my PC command shell environment to set the proper classpaths, executable paths, and so on. It's too much bother. And I detest typing long command line argument lists over and over. I'm just too lazy, and too sloppy a typist. Plus if you have multiple JVMs or JREs installed (and it's hard not to), you wind up with all kinds of potential conflicts. Besides, don't we have computers to eliminate all this drudgery? I create batch files to control all this. True, it's a bit of work to write the batch file the first time, but then every time you use it, you save time and keystrokes. Here's my javakit.bat file. Some browsers may add word wrap to the text below, so it's best to download the actual file. You can also download the batch file. It's printed below in color text. This batch file will probably not work on your PC - you must modify it for your system drives, JBuilder version and paths, TINI bin path, etc. In the following batch file, the last line is somewhat redundant, since we already added comm.jar and tini.jar to the system classpath variable. If you have also added the JBuilder bin folder to your system environment variables, then you don't need to provide an explicit path for it. Assuming all this, the third line could be simply "java JavaKit". set JB=d:\JBuilder7\jdk1.3.1\ |
(With Sun JDK) Install the Sun COMM API |
Note: change these paths to refer to your version of Sun's JDK such as D:\j2sdk14 or whatever your actual path is. The version of JDK is largely irrelevent. We use JDK 1.3.X and 1.4.1_01 without problems. Don't use JDK 1.4 prior to 1.4.1 and do use the 'target 1.1' option with javac when using JDK1.4 You already downloaded the COMM API file, now extract the archive into a folder. I have enough Java libraries now that I started a folder on our server called "javalib" with subfolders such as "commapi", "onewire", "tini", "util", etc, so that we have one central repository for all these libraries. This way the library files are more easily maintained regardless of which JDK and/or IDE is in use on a given PC on the network. I copy the same "javalib" folder to our notebook PCs too, so that all our systems are set up in a similar fashion. Now in that folder (J:\java_lib\commapi for me) open the file PlatformSpecific.html, it has instructions for installing the commapi files. Here's the short version, edited for my case.
The javax.comm.properties must be in the correct directory. Failure to do this will result in JavaKit's inability to enumerate your PC serial ports - instead of COM1, COM2 etc, you will see 'serial0' which are just the name placeholders, not real serial ports. You can't actually access 'serial0' on the PC. |
(With Sun JDK) Create a javakit.bat batch file |
You already downloaded the COMM API file,
extracted, and installed it, so now we can use it.
I have started using my PC environment more to manage the tangle of classpaths and tools I use - such as JDK 1.4.1, Eclipse, Ant 1.5.1, TINIAnt, Servlet classfiles, TINI and aJile runtime files, etc. I set PC-specific environment variables such as JAVA_HOME, TINI_HOME, and ANT_HOME. Here's (I've deleted what isn't germain to this discussion) what I get at a command prompt when I type "SET": ANT_HOME=D:\jakarta-ant-1.5.1 The idea is that on the various PCs I use, all the hard-coded paths are in these variables and nowhere else. Then I create batch files which refer only to these symbolic labels and have no hard-coded paths. This way the same batch file works on any PC on our office network, or my notebook at home or my notebook when used on the office network. This batch file will probably not work on your PC - you must modify it for your system drives, JDK version and paths, TINI bin path, etc. Then in your batch files, or within system variables, you can refer
to other system variables like this, either in a batch file, on a
command line, or in a Windows Control Panel System Environment Variable
value line. In the following batch file, the last line is somewhat redundant, since we already added comm.jar and tini.jar to the system classpath variable, but I wanted to be explicit here. If you have also added the JDSK bin folder to your system environment variables, then you don't need to provide an explicit path for it. Assuming all this, the third line could be simply "java JavaKit". rem The environment variable JAVA_HOME must
be set to the JSDK root such as D:\j2sdk14 |