The part of the Windows registry of most interest to Java is HKEY_LOCAL_MACHINE\SOFTWARE\Javasoft.
It points to where the JDKs, JREs and Java plugins are installed. HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java
Runtime Environment\CurrentVersion should be set to 1.4, the version of
the JDK.
Java and the Registry
Java.exe looks in the registry to decide which
version of Java to use. It can help to delete or replace the file C:\WINNT\System32\java.exe
which is often out of date.
It is wise to take a snapshot of the java portion of the registry. Then when it
is later inevitably damaged, you can restore it. Without such a backup you must
either manually patch the registry or uninstall all your JDKs, JREs, JWS etc and
reinstall from scratch.
regedit /E C:\ENV\java.reg "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft"
You can restore it with:
C:\ENV\java.reg
The exported registry is often in 16-bit unicode. You may have to translate it
to your native encoding if you want to view it. You
don't have to view it unless you are curious. If you do you will see:
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft]
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit]
"CurrentVersion"="1.4"
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.4]
"JavaHome"="J:\j2sdk1.4.2_04"
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.4.2_04]
"JavaHome"="J:\j2sdk1.4.2_04"
"MicroVersion"="2"
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in]
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\1.4.2_04]
"JavaHome"="C:\Program Files\Java\j2re1.4.2_04"
"UseJava2IExplorer"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment]
"CurrentVersion"="1.4"
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.4]
"JavaHome"="C:\Program Files\Java\j2re1.4.2_04"
"MicroVersion"="2"
"RuntimeLib"="C:\Program Files\Java\j2re1.4.2_04\bin\client\jvm.dll"
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.4.2_04]
"JavaHome"="C:\Program Files\Java\j2re1.4.2_04"
"MicroVersion"="2"
"RuntimeLib"="C:\Program Files\Java\j2re1.4.2_04\bin\client\jvm.dll"
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Web Start]
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Web Start\1.4.2_04]
"Home"="C:\Program Files\Java\j2re1.4.2_04\javaws"
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs]
Note you need both the generic 1.4 and specific 1.4.2_04
entries.
You could also use regedit to look at HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft
to see this as a small tree of fields. If it is damaged, and you don't have a
backup, you could patch it field by field, or use the text above to create phony
registry section backup, convert it to the encoding your version of regedit
expects, and restore that, and then fine tune the result.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft Windows\CurrentVersion\Uninstall
tracks all the uninstallable programs, including the JDK and JRE.
RMI Registry
Java RMI has a program called the registry (no
relation to the Windows registry) for tracking remote objects. However, most
people use the term registry to refer to a file in Windows or Windows NT
called the registry.
Backing Up The Registry
You can backup/restore sections of the registry, provided the registry as a
whole is intact, with code like this (which saves the NT SET environment):
You can spawn such regedit code with Runtime.exec. In
W2K, it dumps the file in 16-bit big-endian unicode.
If you try to read it with an ordinary 8-bit editor it will show every second
character as null.
Registry: Second Stupidest Idea In Computing
It is the second stupidest idea in computing. (DLL hell
was the worst, both compliments of Microsoft.) There is a single, shared,
central file that all applications use to store their configuration data in a
convenient hierarchical format. The file has a complex delicate structure, which
means you are putting all your eggs in one basket. If it becomes corrupt, you
lose the configuration information for all your applications. Because it
is so central to the OS, normally you can't even restore it as a lump from
backup, without rebooting to DOS first. The registry becomes a performance
bottleneck since different apps must wait in line for access to it. There are so
many negative consequences of having a central registry implemented as a single
file, that I have a hard time believing the true motives for creating the
registry were not sinister. I suspect these were the true motives:
-
Microsoft lock in
To make it more difficult to port Windows apps to operating systems without a
registry. Microsoft wants to lock in developers.
-
Piracy
To make it more difficult to backup and restore individual applications. You
have to totally reinstall them from the master CD. This discouraged piracy in
the days before the CD burner. As a side effect, the registry harms legitimate
users trying to restore a corrupted application or trying to move it to a
different partition. To move a application to a different drive or partition,
you must uninstall it, reinstall it, then manually reenter all the configuration
options, if you can remember them! If a customer has lost the key for an
app or misplaced the master CD, or can't figure out which key goes with which
disk, he can't even reinstall. He has to buy a new copy of the
application. Hmmm.
-
Cover Up for Incompetence
To make it necessary to reinstall Windows every once in a while. If anything in
the registry goes, novice users have little hope but to reformat the disk and
start over, and re-install Windows and all the applications. An ex Microsoft
employee told me that Microsoft coders do this as a matter of course each month.
The registration keys are designed to be easy to lose and hard to match with the
corresponding CD. Legitimate owners of software end up rebuying unnecessary
copies of the products. Registration keys have no effect on pirates; they only
harm legitimate users. Branding, in contrast, would deter pirates.
-
Intercorporate Spying and Warfare
To make it easier to snoop on and meddle with your competitor's configurations
and file associations. In future secure computer architectures, each application
will run in an airtight sandbox where it cannot snoop on or meddle with the
files or programs of its competitors. The CPU will have a "dark room"
where encrypted code is expanded using the CPU's private key. The code can be
executed, but not examined by anyone. This will put an end to piracy. There will
be no more need for the idiotic registry. The only central unified registry
needed will be a simple list of apps and where they are. The slapdash extension
association system will be replaced with a secure program association set for
each file.
Vendors should proudly advertise when their programs refrain from using the
registry. I suggest something like to the no-all-eggs-in-one-basket logo.
How could the registry be fixed. It need three major changes:
-
Separation
The OS assigns each application a hive -- a mini
registry. Applications can't look outside their hive, except read-only access to
a deliberately public central hive. Only the app itself looks at its hive.
Normally, not even the OS peeks inside an application hive. As a result, the
registry ceases to be a performance bottleneck. It ceases to contain material
irrelevant to the current purpose. It no longer requires contention to access it.
-
Placement
The hive for an app lives in the directory for that app. If the hive becomes
corrupted, only that app is harmed. If that app is backed up and restored to any
other machine, partition or directory it still works. The hive has no idea where
it is. Microsoft has to give up the idea of punishing legitimate application
migration and restoration.
-
Robustness Through Automatic Restoration
There is a mechanism to publish a few public facts, e.g. the mime types of files
the app is willing to display, edit, print ... (An app on its own cannot
commandeer a MIME type from all other apps. It can merely get it self added to
list of potential associations). This structured public information is
replicated centrally. If for some reason the central registry becomes corrupt
and loses these facts, the O/S can get them back by asking any hives it finds
lying about. It can thus recreate the damaged central hive from the public
portion of the application hives. The OS is the only entity that knows where an
app is. Apps themselves don't know where physically they are.
Manipulating the Registry
Staring with JDK 1.4 you can store information in the Windows registry in a
platform-independent way using the Preferences class.
On other platforms this is implemented sanely with an SQL database.
The Preferences feature of Java uses the Windows
registry to store configuration information. This does not give you general
access to the registry however. I take it Sun was too cheap to buy/write some
disk-based Btree code or a simple SQL engine to handle this with ordinary files
that could be easily backed up and restored.
For earlier JDK's IBM's Install
Toolkit for Java includes classes for doing registry manipulation. Giant
Java Tree also has a set
of classes. NevaObject
has a coroutine class for calling Windows APIs. JConfig
does not support registry operations because Jconfig is cross platform,
and Windows is the only OS with this idiotic contraption.
Nodes in the registry can have an optional name/key for direct lookup, and an
optional value. For nodes with keys, accessible via direct name lookup, the
associated value is called the data. For nodes without
keys, only accessible as a subnodes of some other node, the associated value is
called a value. Inserting a node without a key is
referred to as inserting a value.
If you are developer, a more robust technique is to store your data in C:\Documents
and Settings\User\Application Data\ in ordinary flat files.
Exploring The Registry
If you dig around the registry with regedit, you will
see terrifying data values to keys such as {098f2470-bae0-11cd-b579-08002b30bfeb}.
These are not encoded data. These are just random strings of gibberish,
hopefully unique, used to index some other part of the tree. All links are
symbolic, and these are the sort of names used when a human has not taken the
trouble to assign an intelligible name to the link. Sometimes you will find a
link to a link using this cumbersome mechanism. Unfortunately you cannot change
them to intelligible names since they are also hard coded into various programs.
Poking The Registry With JNI
If you want to probe or poke the registry, you will need some JNI that
implements some or all of Microsoft's registry API. Finding the documentation on
how it works can take a while. Look for HKEY_TYPE which
defines the various sorts of value a registry key can have. You will need to
implement SHGetValue and SHSetValue
as well as some of the 18 other methods. Trust Microsoft to make it is
complicated as possible. If you need such a JNI interface to the registry, I am
available to create you one for a fee.
Persistence
The Java Webstart java.util.prefs.Preferences on
Windows uses the registry to store persistent configuration information for your
applications. Check the registry My Computer/HKEY_CURRENT_USER/Software/JavaSoft/Prefs
for the entries.
Last updated 2004-06-30 by Roedy
Green ©1996-2004 Canadian Mind Products
registry
