Generic Java driver V2 FAQ
This table lists frequently asked questions regarding the generic Java Driver:
FAQ | Best practice |
---|---|
Must I change anything for the Java UPoCs I currently use? | Not when you are not using a GJD in the same process. Even then, in most cases there are no UPoC-related V2 changes. |
Can I still use environment variables to set my Java UPoC options? | No. You must use the process_name.pni file to set them even if there is no GJD in the process. |
How do I debug JMX and my Java UPoCs? | Create a process_name.pni and set the options you require for the JVM in it. |
Can I now shut down and restart threads with Java UPoCs without problems? | The best usage is to stop the process as before. The loaded Java classes are not removed from the JVM when a thread is shut down. |
If I use a Java UPoC in a GJD protocol thread, then is there anything special I must do? | No. All of the previous defaults are set for the UPoC in the JVM that is started in the process. |
Can I run my Java UPoC in hcitcl? | If you did in earlier versions, then you still can. When the UPoC is run this way, it uses environment variables to set its options as in the previous versions. No process name is available in this mode, so JVM setup cannot access the ini file. |
I am currently using an earlier GJD; must I change anything for V2? | No. Previous versions of GJD protocol threads work without modification as long as you do not add a second GJD protocol thread to the same process. |
What makes a loaded Java class unique? | Java uses the package.class_name and
the instance of the loader that loaded the class to define a class.
So, when a class with the same package.class
name is loaded by two different loaders, they are not the
same class. This is important when you use a shared JVM. |
Can I use a single
package.class in both a UPoC and a GJD? |
If the JVM is not shared, then the class that is used by both is the same. In other words, the class should have no static members that are modified by both the UPoC and the GJD code. |
Is the process_name.pni file required in all cases? | No. If a single GJD is used in the process and no UPoC requires the file, then thread_name.ini can contain the JVM parameters instead of process_name.pni. |
What goes into the process_name.pni? | It should contain only the JVM section as described for the thread_name.ini. That is, the parameters that are required when a JVM starts. When there is more than one GJD running in the process, the parameters are the union of what is in their thead_name.ini files. Required files for all Java UPoCs being used are also included. |
In what order are ini files processed? | When the JVM is start first the process_name.pni is used, if found there. If it is not found, then the thread_name.ini is attempted and used to set up the JVM, if found. If neither of these files are found, then only the UPoC JVM setup is finished. If one of these files is found, then the UPoC setup is added to the end of the parameters set by the file. |
What does "true" mean? | When USE_LOADER is set to "true", each GJD class
is loaded by its own class loader. The class path of each is usually
the same. This makes two classes with the same package.name unique in the JVM. Because
they are unique, any statics that are used in the class are also
unique. |
Can I have a class path that is unique to the GJD instance? | Yes, but be cautious. Usually, the thread_name.ini only contains an "include" that
points to the process_name.pni
file. When the unique loader is used ("shared" is being used), the class path for that loader uses only the thread_name.ini. Thus, if you add more class path entries in the thread_name.ini, then they are used only for that loader instance. In this way, you can set up common things in the process_name.pni and add unique jar files for the GJD instance by doing this. |
Can "shared" be used when there is only one GJD in the process? | Yes. If the code permits it, then this lets that instance of the GJD to be shut down and restarted. This can be an advantage if you are still changing the Java code. You can shut down, change a jar, and restart using the new code. If the implementation of the GJD Java does not permit shut down/restart, then there is no requirement to set things to "shared". |
What is new in the JVM section of the ini files? | The new parameter is USE_LOADER. This should be commented out, not be there, or set to "true." |
Can I now stop and start a GJD protocol thread? | This depends on what code is being loaded and how it is loaded. Some things, for example, Tomcat, uses the system loader no matter how they are started so cannot be shut down. Neither can things that conflict with classes loaded by Tomcat be used in the same JVM. Most things should permit it, but you must try it to find out if it works. If "shared" is not set, then the general answer is "no." Objects are not removed from the JVM when the thread is shut down. If a Java UPoC is being used, then the answer is always "no." |
Does the supplied general driver code support more than one GJD in the process? | Only if you have set "shared", although perhaps not even then. If the
supplied link class is loaded by the same loader, then it is not
unique. It contains static variables that are used by the C code of
the protocol driver. Because the class is not unique, these
variables are identical and cannot hold the two values as required
by two different GJD protocol drivers. There are several ways around this:
|
Does setting shared always work? | No. Some Java code does not use the GJD loader after they begin
running. For example, Tomcat switches to the system loader soon
after it starts. Other large code collections may do the same. Even
if the unique loader is used, other things may prevent protocol shut
down and cause problems. For example, another loader has a daemon thread that does not stop when you attempt to stop the server. Thus, there is no advantage to using "shared" for it. If there are strange errors or the thread does not shut down when "shared" is used, then move the GJD to its own process. There is no general way to predict when this is required. |
What kind of errors can show up when using "shared"? | Currently, one known issue happens when an
anonymous class is used for a new thread. This is the $ class that is made when the class
compiles. For unknown reasons, you get "Illegal Access" for the
$ class when creating the new
thread object. To workaround, you can create a new independent class
for the thread. You can also make the class with the anonymous class
implement Runnable and move the
run method into the class. It is yet to be determined whether other
uses of anonymous classes also have this issue. |
If "shared" has problems, then why is it there? | Using separate loaders (that is, "shared"), can be useful to reduce the number of processes being used in many cases. Not every GJD can use it until later. The main problem with using it is when odd errors happen. These show up early in the development process, so are not considered detrimental. The advantages outweigh the disadvantages. |
Forgetting "shared", why was this version of the GJD created? | To permit the use of Java UPoCs in a process that contains a GJD protocol driver. |