Name: bk70084 Date: 09/10/98
=20
Hello:
My company is using Java to develop front-end configuration interfaces to a=
ll of our major products. =20
We are using the Dais implementation of CORBA to do all of the communicatio=
n. I am one of the=20
Java programmers (Java kicks ass!).
Recently I looked into converting our products from JDK 1.1.3 to use JDK 1.=
2. Of course, we are not=20
going to make the change until your final release of 1.2 and until we can g=
et reasonable performance=20
from 1.2. Unfortunately when our software took over 30 seconds to load and=
the VM used over 20=20
Meg of RAM, this made converting to 1.2 a serious improbability. I have be=
en giving this issue some=20
serious thought. I maybe the only one in this company, but I see the step =
to 1.2 as inedible (hope I=20
spelled that right). In the spirit of moving forward, here is a suggestion=
:
//Excuse the implementation detail, I am a programmer
1. Add a parameter JDK 1.2 VM (ex: java.exe) similar to: -persistentMode
2. Implement the parameter:
=B7 Causes the VM to load and remain into memory. Does not execute any Jav=
a yet.
=B7 All subsequent launchings of the VM will be intercepted by the running =
process (above). The=20
classpath and executable class name information is passed to the running VM=
.
=B7 The running VM (above) will unload all classes and start executing the =
new class with the new=20
classpath.
In other words, the developer and user does not have to load the entire Vir=
tual Machine (reboot!)=20
every time he or she wants to run a program! Also, it seems like the -pers=
istentMode parameter=20
is the safest way to offer this optional feature.
This should be easy to implement and save users and developers lots of time=
. Sun gives new=20
meaning to the words Virtual Machine with this release of JDK 1.2. I can't=
wait until the VM is a=20
PC M(achine)!
(Review ID: 35927)
======================================================================
- duplicates
-
JDK-4187333 let multiple VMs share code & constant pools
-
- Closed
-
- relates to
-
JDK-4511554 RFE Class Information Loaded Into Shared Memory
-
- Closed
-
-
JDK-4287407 Sharing between JVMs
-
- Closed
-
-
JDK-4416624 multiple JVM runtimes do not share memory between themselves
-
- Closed
-