Board index » jbuilder » How to deal with JRE upgrades and installed files

How to deal with JRE upgrades and installed files


2006-02-01 10:23:51 AM
jbuilder14
Hi,
I have an application that communicates over the serial port to an
external instrument. The serial port communication requires some files
to be placed in JRE/lib, JRE/bin etc.
A guy just called and told me he lost the communication and after some
looking around it turned out that he had upgraded JRE from 1.5.0.4 to
1.5.0.6 and because of that was missing the needed communication files.
Is there a way to have the JRE upgrade to "know" about these files or
any other trick to prevent this from happening with anyone else? The
only thing I can think of is to create a special setup.exe that installs
the files in its directories (today this is part of the application
install.exe file) and tell all customers to run that after any java
upgrades.
TIA.
 
 

Re:How to deal with JRE upgrades and installed files

Magnus wrote:
Quote
I have an application that communicates over the serial port to an
external instrument. The serial port communication requires some files to
be placed in JRE/lib, JRE/bin etc.

A guy just called and told me he lost the communication and after some
looking around it turned out that he had upgraded JRE from 1.5.0.4 to
1.5.0.6 and because of that was missing the needed communication files.

Is there a way to have the JRE upgrade to "know" about these files or any
other trick to prevent this from happening with anyone else? The only
thing I can think of is to create a special setup.exe that installs the
files in its directories (today this is part of the application
install.exe file) and tell all customers to run that after any java
upgrades.
It would be better if you put the DLL and the required supporting JAR
files in a separate application directory. I personally never install
anything in JRE/lib or JRE/bin for the reason you mentioned: I have no
control over the client machine and can't guarantee that no one will mess
up the JRE installation.
The JAR files can be found with the -classpath directive. The supporting
DLL's can be found by explicitly setting the library path as
"-Djava.library.path=...". Alternately, you can explicitly load the DLL
yourself. There's a good writeup here:
www.inonit.com/cygwin/jni/helloWorld/load.html
--
Kevin Dean [TeamB]
Dolphin Data Development Ltd.
www.datadevelopment.com/
NEW WHITEPAPERS
Team Development with JBuilder and Borland Enterprise Server
Securing Borland Enterprise Server
www.datadevelopment.com/papers/index.html
Please see Borland's newsgroup guidelines at
info.borland.com/newsgroups/guide.html
 

Re:How to deal with JRE upgrades and installed files

Kevin Dean [TeamB] wrote:
Quote
Magnus wrote:
>
It would be better if you put the DLL and the required supporting JAR
files in a separate application directory. I personally never install
anything in JRE/lib or JRE/bin for the reason you mentioned: I have no
control over the client machine and can't guarantee that no one will
mess up the JRE installation.

The JAR files can be found with the -classpath directive. The
supporting DLL's can be found by explicitly setting the library path as
"-Djava.library.path=...". Alternately, you can explicitly load the DLL
yourself. There's a good writeup here:

www.inonit.com/cygwin/jni/helloWorld/load.html


Thanks Kevin,
Below you can find what article I got the placement from and where I
ended up to put the files after some testing. I can't say I tested every
possible combination where to put the files but I tried to minimize it
as you can see below.
My bat file:
javaw -classpath
".\classes\jdatastore.license;.\classes\jdsserver.jar;.\classes\comm.jar;.\classes\kl.jar;.\MYAPP.jar"
myapp.MYAPP
I'm not sure how to do this so that the comm.jar finds the files it
needs or how to change the bat-file. If you have additional input it
would be much appreciated.
Again, thanks for your input.
--- I put the files according to the following article ---
bdn.borland.com/article/0,1410,31915,00.html
There are some tricks involved in getting the Java Communications API to
correctly interact with the Windows system. Among the items that you
download from Sun are three very important files:
* comm.jar
* win32com.dll
* javax.comm.properties
For the JVM to recognize the serial ports, proper placement of these
files is important. I’ve read lot’s of messages on the boards, tried
various ways of placing these files in a Windows system, and have found
the following installation methods to be effective:
comm.jar should be placed in:
%JAVA_HOME%/lib
%JAVA_HOME%/jre/lib/ext
win32com.dll should be placed in:
%JAVA_HOME%/bin
%JAVA_HOME%/jre/bin
%windir%System32
javax.comm.properties should be placed in:
%JAVA_HOME%/lib
%JAVA_HOME%/jre/lib
Once you’ve done this, compile and execute one of the sample programs
provided by Sun to ensure that you’ve properly installed everything.
--- end article ---
After some testing it works with the following (what I place where today):
Source: "win32com.dll"; DestDir: "{code:getJavaHome}\bin"
Source: "win32com.dll"; DestDir: "{sys}"
Source: "comm.jar"; DestDir: "{code:getJavaHome}\lib"
Source: "comm.jar"; DestDir: "{code:getJavaHome}\lib\ext"
Source: "javax.comm.properties"; DestDir: "{code:getJavaHome}\lib"
where code:getJavaHome pick up "HKLM, 'SOFTWARE\JavaSoft\Java Runtime
Environment'" from the registry.
 

{smallsort}

Re:How to deal with JRE upgrades and installed files

Magnus wrote:
Quote
Kevin Dean [TeamB] wrote:
>Magnus wrote:
>>
>It would be better if you put the DLL and the required supporting JAR
>files in a separate application directory. I personally never install
>anything in JRE/lib or JRE/bin for the reason you mentioned: I have no
>control over the client machine and can't guarantee that no one will
>mess up the JRE installation.
>
>The JAR files can be found with the -classpath directive. The
>supporting DLL's can be found by explicitly setting the library path as
>"-Djava.library.path=...". Alternately, you can explicitly load the DLL
>yourself. There's a good writeup here:
>
>www.inonit.com/cygwin/jni/helloWorld/load.html
>
>
Thanks Kevin,

Below you can find what article I got the placement from and where I
ended up to put the files after some testing. I can't say I tested every
possible combination where to put the files but I tried to minimize it
as you can see below.

My bat file:
javaw -classpath
".\classes\jdatastore.license;.\classes\jdsserver.jar;.\classes\comm.jar;
\classes\kl.jar;.\MYAPP.jar"
myapp.MYAPP

I'm not sure how to do this so that the comm.jar finds the files it
needs or how to change the bat-file. If you have additional input it
would be much appreciated.

Again, thanks for your input.

--- I put the files according to the following article ---

bdn.borland.com/article/0,1410,31915,00.html

There are some tricks involved in getting the Java Communications API to
correctly interact with the Windows system. Among the items that you
download from Sun are three very important files:

* comm.jar
* win32com.dll
* javax.comm.properties

For the JVM to recognize the serial ports, proper placement of these
files is important. I’ve read lot’s of messages on the boards, tried
various ways of placing these files in a Windows system, and have found
the following installation methods to be effective:

comm.jar should be placed in:

%JAVA_HOME%/lib
%JAVA_HOME%/jre/lib/ext

win32com.dll should be placed in:

%JAVA_HOME%/bin
%JAVA_HOME%/jre/bin
%windir%System32

javax.comm.properties should be placed in:


%JAVA_HOME%/lib
%JAVA_HOME%/jre/lib

Once you’ve done this, compile and execute one of the sample programs
provided by Sun to ensure that you’ve properly installed everything.

--- end article ---

After some testing it works with the following (what I place where today):

Source: "win32com.dll"; DestDir: "{code:getJavaHome}\bin"
Source: "win32com.dll"; DestDir: "{sys}"
Source: "comm.jar"; DestDir: "{code:getJavaHome}\lib"
Source: "comm.jar"; DestDir: "{code:getJavaHome}\lib\ext"
Source: "javax.comm.properties"; DestDir: "{code:getJavaHome}\lib"

where code:getJavaHome pick up "HKLM, 'SOFTWARE\JavaSoft\Java Runtime
Environment'" from the registry.
Just add the jar files to your classpath statement in the batch file. Dlls
can go in the Windows/System or /Windows/system32 directory.
Of course you could build a jar file to include all resources and
dependencies as well (in most cases).
 

Re:How to deal with JRE upgrades and installed files

Magnus wrote:
Quote
Paul Nichols (TeamB) wrote:
>Magnus wrote:
>
>
>>Kevin Dean [TeamB] wrote:
>>
>>>Magnus wrote:
Thanks Paul,

The comm.jar file is already in the classpath
The dll is placed in SYSTEM32

What about the properties file? Can that be included in the path somehow?
The best thing to do with a properties file is to reference it by the class
path
Example:
public class SomeClass{
public SomeClass{
readPropertiesFile(this.getClass().getResource("MyPropertiesFile");
}
}
Quote

>Of course you could build a jar file to include all resources and
>dependencies as well (in most cases).

I tried to include every jar file but if my memory is correct it did not
work for this comm.jar file.
May be true. I am not sure about this one.
Most of the time it will work just fine. But if you have other resources you
are depending upon (graphics, dlls, so libs,etc), then it may not work.
Many times when I have seen it not work, it is a dependency problem with
other jars or resources it is using that is not in the OS path, or java
classpath.
Since I work on Unix/Linux, most of the time, I have little need for COM
object integration.
 

Re:How to deal with JRE upgrades and installed files

Paul Nichols (TeamB) wrote:
Quote
Magnus wrote:


>Kevin Dean [TeamB] wrote:
>
>>Magnus wrote:
>>
>
>My bat file:
>javaw -classpath
>".\classes\jdatastore.license;.\classes\jdsserver.jar;.\classes\comm.jar;\classes\kl.jar;.\MYAPP.jar" myapp.MYAPP
>
>I'm not sure how to do this so that the comm.jar finds the files it
>needs or how to change the bat-file. If you have additional input it
>would be much appreciated.
>
>Again, thanks for your input.

Just add the jar files to your classpath statement in the batch file. Dlls
can go in the Windows/System or /Windows/system32 directory.
Thanks Paul,
The comm.jar file is already in the classpath
The dll is placed in SYSTEM32
What about the properties file? Can that be included in the path somehow?
Quote
Of course you could build a jar file to include all resources and
dependencies as well (in most cases).
I tried to include every jar file but if my memory is correct it did not
work for this comm.jar file.
 

Re:How to deal with JRE upgrades and installed files

Paul Nichols (TeamB) wrote:
Quote
Magnus wrote:

>Paul Nichols (TeamB) wrote:
>>Magnus wrote:
>>
>>
>>>Kevin Dean [TeamB] wrote:
>>>
>>>>Magnus wrote:

>Thanks Paul,
>
>The comm.jar file is already in the classpath
>The dll is placed in SYSTEM32
>
>What about the properties file? Can that be included in the path somehow?

The best thing to do with a properties file is to reference it by the class
path

Example:
public class SomeClass{

public SomeClass{
readPropertiesFile(this.getClass().getResource("MyPropertiesFile");
}
}
>>Of course you could build a jar file to include all resources and
>>dependencies as well (in most cases).
>I tried to include every jar file but if my memory is correct it did not
>work for this comm.jar file.

May be true. I am not sure about this one.

Most of the time it will work just fine. But if you have other resources you
are depending upon (graphics, dlls, so libs,etc), then it may not work.

Many times when I have seen it not work, it is a dependency problem with
other jars or resources it is using that is not in the OS path, or java
classpath.


Since I work on Unix/Linux, most of the time, I have little need for COM
object integration.



Here is the best resource I found for evaluating javacomm issues:
practicalembeddedjava.com/tools/javaxcomm.html
The real problem here is that most people don't realize that the
javacomm library presents two special problems to those who want to
deploy it.
First, it is uses JNI. Second, it is a "Java Standard Extension" (it
uses the javax namespace). Each of these complicates deployment in
awkward ways. Combined, they are much, much worse.
Aside from the advice in the link above, the only other option I can
offer is to try using the -Xbootclasspath/a:
--
Regards,
Lori Olson [TeamB]
------------
Save yourself, and everyone else, some time and search the
newsgroups and the FAQ-O-Matic before posting your next
question.
Google Advanced Newsgroup Search
www.google.ca/advanced_group_search
Other Newsgroup Searches:
www.borland.com/newsgroups/ngsearch.html
Joi Ellis's FAQ-O-Matic:
www.visi.com/~gyles19/fom-serve/cache/1.html
 

Re:How to deal with JRE upgrades and installed files

Thank you all for your input. I tried the following (hoping it would work):
1) I only put the dll in the sys32
2) I put the jar- & property-files in the classpath (in the bat-file)
but it didn't recognized any com-ports. Until I can get rid of the
serial port communication I will stick with my first temporary fix, an
install.exe that only put the comm-files according to the latest
installed jre, and hand that over to the customers who call support when
they lost their communication...
Lori M Olson [TeamB] wrote:
Quote
Paul Nichols (TeamB) wrote:

>Magnus wrote:
>
>>Paul Nichols (TeamB) wrote:
>>
>>>Magnus wrote:
>>>
>>>
>>>>Kevin Dean [TeamB] wrote:
>>>>
>>>>>Magnus wrote:
>
>
>>Thanks Paul,
>>
>>The comm.jar file is already in the classpath
>>The dll is placed in SYSTEM32
>>
>>What about the properties file? Can that be included in the path
>>somehow?
>
>
>The best thing to do with a properties file is to reference it by the
>class
>path
>
>Example:
>public class SomeClass{
>
>public SomeClass{
>
>readPropertiesFile(this.getClass().getResource("MyPropertiesFile");
>}
>}
>
>>>Of course you could build a jar file to include all resources and
>>>dependencies as well (in most cases).
>>
>>I tried to include every jar file but if my memory is correct it did not
>>work for this comm.jar file.
>
>
>May be true. I am not sure about this one.
>Most of the time it will work just fine. But if you have other
>resources you
>are depending upon (graphics, dlls, so libs,etc), then it may not work.
>
>Many times when I have seen it not work, it is a dependency problem with
>other jars or resources it is using that is not in the OS path, or java
>classpath.
>
>
>Since I work on Unix/Linux, most of the time, I have little need for COM
>object integration.
>
>
>

Here is the best resource I found for evaluating javacomm issues:

practicalembeddedjava.com/tools/javaxcomm.html

The real problem here is that most people don't realize that the
javacomm library presents two special problems to those who want to
deploy it.

First, it is uses JNI. Second, it is a "Java Standard Extension" (it
uses the javax namespace). Each of these complicates deployment in
awkward ways. Combined, they are much, much worse.

Aside from the advice in the link above, the only other option I can
offer is to try using the -Xbootclasspath/a: