| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Does anybody knows how to _remove_ Java option from 8i?
Unix box:
Connected to:
Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production
Does anybody know is it possible to remove Java _option_ from Oracle8i kernel? As stated, this is _option_, like other. So I guess that there can be an option to turn off this option... I know that this may be a hack (not supported by Oracle), and there is no such option in standard places (Oracle Installer).
On Unix (Linux, Solaris, HP/UX) Oracle links they executables at install/configure time (in opposite to Windows world that lacks compiler/linker). I looked to makefiles and found some options as targets, for example -- parropt/no_parropt, sdopt/no_sdopt, etc. This targets simply do modifications of libraries, exchanging real things and stubs for them. But for Java (jox_on/jox_off, I guess) there are empty targets (maybe Oracle lives them at historic reasons?) -- all of this are in $ORACLE_HOME/rdbms/lib/ins_rdbms.mk.
So real question is -- does anybody knows what objects are responsible for Java (jox?) option? Or what names this option uses?
Yes, I know two things also -- there is a Oracle8.0 version, and that this is a "dody trick". But: Oracle8.1 (8i) have some new features not related to Java and not available in 8.0, and, as I guess, 8.0 will be replaced completely by 8i in future. And I know also about hacks used for installation of 8i on Linux -- at least one library, missing from distribution, I should make myself, tracking symbols referenced from it and making stubs for them (compiled small .c source file). So I already did some tricks here.
May be question about why you need remove it -- this is simple. First is consistence -- _if_ it is a option, it should be removeable, or it should not be an option. And second -- server now takes a lot of memory (yes, it costs less than year ago) -- I should pay for about 64megs that I know will never be used, e.g. I should take avay this megs to big backet... Not good, yeah?
Any ideas? Received on Thu Aug 19 1999 - 15:02:34 CDT
 |
 |