-
Enhancement
-
Resolution: Fixed
-
P4
-
5.0
-
None
-
b08
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2121067 | 5.0u2 | Vijayan Jayaraman | P3 | Resolved | Fixed | b02 |
A j2se workspace developer needs access to a prebuilt hotspot jvm
in order to build and test j2se. In general, the jvm must be very recent
since changes to j2se often require concomitant changes to hotspot.
There are many reasons why developers would want to specify a specialized
hotspot build:
- Copying the hotspot build to local disk gives better performance
or network failure independence, or ability to work offline.
- A hotspot feature may only be available in a nightly, not a promoted
build.
Currently, specifying an alternate hotspot source requires THREE
environment variables:
ALT_HOTSPOT_SERVER_PATH
ALT_HOTSPOT_CLIENT_PATH
ALT_HOTSPOT_LIB_PATH
Although this flexibility is useful, it is almost never needed
by j2se developers.
I believe the right model is as follows:
All developers are working on some component that builds on other
components, which are logically "imported",
generally in binary form like a libjvm.so, by the developer.
Each component also exports build results to other components
higher up in the food chain.
The release engineering team assembles all the components together
and builds them all as a unit. Let's call such a beast a "full build".
It's not quite the same as an install image that a customer gets, because
this "full build" also exports intermediate build results used by other
components in the build, but it's pretty close. For the particular
case of j2se, there are no intermediate components needed from hotspot
that are not also shipped to the customer.
Anyways, in general we want one ALT_ variable that points at a "full build",
containing all exports from all components. The name ALT_IMPORT_PATH
is a name that captures the intent.
If ALT_IMPORT_PATH is defined, but ALT_HOTSPOT_SERVER_PATH is not,
then the makefiles would access libjvm.so from ALT_IMPORT_PATH.
I believe this model should scale to other component developers like
deploy, although I don't understand their development tasks.
Whatever the implementation details, the end result should provide this
specifically for j2se developers:
- If no ALT_ variables are defined, all components are automatically imported
from some release-engineering provided default (promoted build).
This should even work on Windows WITHOUT the need to explicitly
mount a network drive using `net use'.
- There should be exactly one ALT_ variable that the developer should define
to access a different set of component imports. Different
values of this variable should allow developers to access nightly builds
or promoted builds, or copies of these on
a local disk. Developers should be able to build their own
"import tree" using modified source without guru-level knowledge of the
build process
###@###.### 2003-08-22
in order to build and test j2se. In general, the jvm must be very recent
since changes to j2se often require concomitant changes to hotspot.
There are many reasons why developers would want to specify a specialized
hotspot build:
- Copying the hotspot build to local disk gives better performance
or network failure independence, or ability to work offline.
- A hotspot feature may only be available in a nightly, not a promoted
build.
Currently, specifying an alternate hotspot source requires THREE
environment variables:
ALT_HOTSPOT_SERVER_PATH
ALT_HOTSPOT_CLIENT_PATH
ALT_HOTSPOT_LIB_PATH
Although this flexibility is useful, it is almost never needed
by j2se developers.
I believe the right model is as follows:
All developers are working on some component that builds on other
components, which are logically "imported",
generally in binary form like a libjvm.so, by the developer.
Each component also exports build results to other components
higher up in the food chain.
The release engineering team assembles all the components together
and builds them all as a unit. Let's call such a beast a "full build".
It's not quite the same as an install image that a customer gets, because
this "full build" also exports intermediate build results used by other
components in the build, but it's pretty close. For the particular
case of j2se, there are no intermediate components needed from hotspot
that are not also shipped to the customer.
Anyways, in general we want one ALT_ variable that points at a "full build",
containing all exports from all components. The name ALT_IMPORT_PATH
is a name that captures the intent.
If ALT_IMPORT_PATH is defined, but ALT_HOTSPOT_SERVER_PATH is not,
then the makefiles would access libjvm.so from ALT_IMPORT_PATH.
I believe this model should scale to other component developers like
deploy, although I don't understand their development tasks.
Whatever the implementation details, the end result should provide this
specifically for j2se developers:
- If no ALT_ variables are defined, all components are automatically imported
from some release-engineering provided default (promoted build).
This should even work on Windows WITHOUT the need to explicitly
mount a network drive using `net use'.
- There should be exactly one ALT_ variable that the developer should define
to access a different set of component imports. Different
values of this variable should allow developers to access nightly builds
or promoted builds, or copies of these on
a local disk. Developers should be able to build their own
"import tree" using modified source without guru-level knowledge of the
build process
###@###.### 2003-08-22
- backported by
-
JDK-2121067 Allow developers to specify hotspot imports via ONE ALT_ variable
-
- Resolved
-