jdk1.4 on OC4J - OC4J(Archived)

Hello -
On Orion, to switch out jdk versions, I would just switch (other than paths and such) the tools.jar file. However, I notice no such ability in the oc4j-extended version. How can I employ jdk1.4 with the latest release candidate?

Ray -- I'm not sure all of the needed changes (since we have not yet certified with jdk 1.4) but you may want to look at this thread for some ideas about getting JSPs to work.
later -- Jeff
Hello -
On Orion, to switch out jdk versions, I would just switch (other than paths and such) the tools.jar file. However, I notice no such ability in the oc4j-extended version. How can I employ jdk1.4 with the latest release candidate?


OC4J and JDK 1.5

Hi all,
which version supports the latest JDK (1.5 or 5.0 as you
As far as I know, no version of OC4J supports JDK 5.0
Although I imagine there is probably a workaround (or hack ;-), I'm sure Oracle would not support such a "hacked" version of OC4J.
I recall similar questions arising when JDK 1.4 first came out -- OC4J (then) only supprted JDK 1.3, but people found ways of making OC4J use JDK 1.4. Perhaps if you look at what people did back then, it may give you an idea. I suggest you search the forum archives -- probably for the terms "support" and "1.4"
Just out of curiosity, what advantages do you see in using OC4J with JDK 5.0?
Good Luck,
The real problem is that I want to use JDK 5.0 in my
web applications (especially for metadata annotations).
So once an application is written in JDK 5.0 in production
I will need the same JDK.
Hope this clarify the situation.
Although I haven't used it myself, perhaps XDoclet will be of help?
Good Luck,
The official production release of OC4J 10g (10.1.3) will support JDK 5.0.
We are also hopeful that the next update we make to the OC4J 10g (10.1.3) Developer Preview will work with JDK 5.0.
Pardon me for asking the obvious question ;-)
When will that be?
Good Luck,
gday Avi -- how are you? Good to see you still hanging out here answering (and asking) questions.
There's no firm dates I can commit to at this point. All I can say is that we're planning on having another developer preview which will be functionally complete and will closely represent what our production release will be.
So sit back and enjoy Developer Preview 3 .. ;-)
I tried to use OC4J preview 3 with JDK 5, and ran into one big problem: something references internal Corba classes that existed in JDK 1.4's rt.jar, but don't exist in JDK 5. So, it doesn't start properly. Hopefully this does get fixed in the next release. 
Actually, if you don't mind getting your hands a bit diry...
Please note, this is bad and wrong and Oracle may try to castrate you.
Open up the rt.jar from JRE 1.4. Rip out the com.sun.corba.se directory. Compress it into a new jar, I called it corba-rt.jar. Copy it to oc4j/j2ee/home. Edit the boot.xml in the oc4j.xml file, and add a new line under the <system-class-loader ...> element. That new line is should be something like <code-source path="corba-rt.jar" /> which points to the corba stuff that was ripped out of the JRE 1.4 rt.jar.
Things should now start up.
Of course, I have no idea what impact this will have on using EJBs, etc, etc, I haven't gotten that far. But hey, at least it kicks on. :) 
I'm all for experimentation .. just don't call Oracle support with your experimental efforts ;-)
Thanks for posting the info.
For what it's worth, I can comment that I've tried a recent internal OC4J build from our mainline with JDK5.0 and it now works fine -- as far as I tested it anyway.
One thing to note is that if you do follow this advice and start OC4J with JDK 5.0, then if you ever revert back to starting it at a later date with JDK 1.4, you will see some problems with the compiled EJB wrapper code. This is because it was originalled compiled with 5.0 but then later is being loaded by 1.4, and a class version exception is thrown.
If you get this and do want to use JDK 1.4, the easiest way to fix it is to remove all the generated subdirectories under the j2ee/home/application-deployments directory. This will cause OC4J to regenerate and compile new EJB wrappers using the JDK 1.4 compiler.

JDK 1.4 Beta

Are thwere any dangers/issues concerning the beta version of jdk 1.4
Is it better to stay with 1.3.1 or should I move to 1.4
The Beta version still have some bugs,
and still in testing status.
I use that only in personal program.
Well, the 1.4 version ist still BETA, as the name mentiones. However, I have been using some other beta jdk's, and encountered no problems. The reason is i think, that the old classes stay unchanged in most cases, sometimes they get marked "deprecated", but are still the same, so the possible problems are little, and most of them only with the new classes.
On a production system, I would stay with a stable runtime, but for development, as long as you care a little about usage of new classes (for backward compatibility), it should work fine enough. 
The BETA software should be fairly stable, there have been many testing releases and candidates before the BETA release.
Having said that this should not be used in a production environment or for critical applications at this stage.
I would suggest to use the release for testing and development purposes only.
If you have no specific reason to move from a stable version then it would be best that you continue with 1.3.1 until 1.4 is released officially.
Java Developer Technical Support
Sun Microsystems 
Just to add, please check the release, readme files and license that may describe any issues regarding this release.
Java Developer Technical Support
Sun Microsystems. 
FWIW, I've been using JDK 1.4 for about a week now with no problems other than some rather esoteric CORBA problems while running Weblogic.
I've just recompiled a couple of applets under 1.4b and now I get 'NoClassDefFoundError's under IE5...back to 1.3 for me. (PS if you can find a bug report in the database pls post the id# - cheers)

JDK 1.3

I am using JDeveloper 3.2. The install file indicates how to add JDK 1.3 for use with JDeveloper. Is there any reason this is not a good idea? At the moment, I have no compelling need to use JDK 1.3 over 1.2.2, but generally like to work with current releases (if reliable).
Any advice?
Dave Butler 
you can develop and debug with jdk 1.3, but you have no oracle products you can deploy the code to...
so you'll have problems -- at that point.
no oracle products --
the jdbc drivers -- any version,
8i rdbms,
ias 1.0.x or ias 9i, or
oas -- any version --
supports jdk 1.3. 
Currently using JDK 1.3 with 3.2 for building a fat client application. For this use I've run (so far) into no major issues, as far as the JDK is concerned. ( I think ).
Primary reason for upgrading was to allow users to enter lower case q's in jtables without having to mouse click each cell.
fyi - could you clarify " the jdbc drivers --- any version ..."... I'm unsure what you mean. I'm using jdbc drivers out of the application to the database... they seem to work OK? Probably confusion over semantics on my part? 
I am unable to Debug using JDK 1.3. Do you have any pointers on how to configure JDev to do this.
I am unable to Debug using JDK 1.3. Do you have any pointers on how to configure JDev to do this.
Hmmm.. debug how? I can debug 3.2/1.3 applications just fine.
If you are deploying (beans,jsps, servelets, etc ) I've no idea if 1.3 is supported by Oracle yet. To be sure, the 1.3 JRE would have to be on the target machine and hooked in, eh?
If you are simply doing a client application I may be able to post if you can describe what you are encountering.
Good Luck 
no oracle jdbc drivers are certified to work with jdk 1.3.
if it is working for you -- GREAT !!!
But -- if you run into a problem using the oracle jdbc drivers and you're using jdk 1.3.x, oracle support WILL require you to reproduce the issue with jdk 1.2.x before any bugs can be filed against the jdbc drivers.
so you are using jdk 1.3 in an oracle unsupported configuration and doing so at your own risk.
i hope this clarifies the issue. 
Noted. But also as noted before, who can deploy something where when you tab into a JTABLE and type "q" ( or several other symbols ) and the keyboard input is ignored? That was a show stopper that forced movement to 1.3 for us.
We can't have/assure that users will always mouse click on every editable field to type in a q. It's a heads down application, and missing characters in the middle of official document text is not neat. grin
Hopefully Oracle will fully support 1.3 tout suite so that we can deploy safer real world applications that are actually usable.

JDK 1.4 fails on OC4J

When will Oracle Support JDK 1.4??? There is documentation on how to upgrade your JDK in Metalink to 1.4, which I did, and then it broke OC4J.
Other replies posted from Oracle in this forum indicated that JDK 1.4 would be supported in OC4J 903, which we're using (trying to use anyway).
This is getting extremely frustrating, I have users beta testing applications on jakarta Tomcat using 1.4 w/No problems as well as Macromedia JRun 4, also w/No problems. This does not make it easy to sell our client on OC4J when it doesn't support current technologies. Any idea when Oracle will catch up to the rest of the world? 
OC4J 9.0.3 supports JDK 1.4. You have to replace the tools.jar in OC4J_HOM/jdk/lib directory with your new tools.jar
OC4J 9.0.4 Developers Preview by default uses JDK 1.4.1
Thanks for your reply. Is there a different tools.jar other than what comes with the JDK?
I followed the instructions exactly as they were displayed in metalink:
stopped all oracle services, renamed current jdk folder to jdk_1_3_1
installed jdk 1.4 in OC4J_HOME/jdk/
Restarted the server, brought up the OC4J instance and jsp pages would not operate correctly. Threw a strange class deprecated error.
any insight you can provide would be very helpful, thanks!
Hey Justin,
Can you or anyone post the document or note number that describes the steps to update the jdk from 1.3 to 1.4? Thanks. 
I think there are settings you can make in the config files to adjust this. I don't know if this fix will address what you're seeing but it helped me with something else. Sounds like it might be related:
In server.xml, as child element of "application-server":
<compiler executable="javac" classpath="C:/j2sdk1.4.1_02/jre/lib/rt.jar" />
In global-web-application.xml, add the following init param to the "jsp" servlet:
Of course, you'll need to update the paths to point to your actual jdk installation. 
A couple things to keep in mind if you want to use JDK1.4 with OC4J.
First its not enough to install the JDK 1.4 onto your system. You need to physically copy the tools.jar from the jdk1.4\lib and replace the one in your oc4j\jdk setup.
Second, you need to check you system path to ensure that the reference to the JDK1.4 JRE precedes anything Oracle installs. I noticed that if one installs the Oracle 9i client, or even software, they'll jam Java 1.18 runtimes out there that'll screw alot of things up including Oc4j. So you might want to double check that to make sure the JRE is in since with the tools.jar you're using
Pardon my grammar in the above post. I meant to say that you need to ensure that the JRE runtime in use is in sync with the tools.jar in use.
Apologies for the confusion
Metalink-Document : How to upgrade the JDK1.3.x shipped with 9iAS to higher versions?
Document-ID : 232496.1

Changing Developer Suite JDK to Java 6?

It is possible to download Jdeveloper and SqlDeveloper without the JDK and when you run them the first time you can specify the path to your JDK.
With Developer Suite 10g it comes with JDK 1.4.2_06, with no options to use a different one. Has any one successfully upgraded this to JDK 1.6?
I am not talking about using Java 1.6 to run the Forms Applet. What I am attempting to do is start the OC4J container so I can run Forms locally, and use other iDS features that require the JDK. 
Sorry Don, you've got to run the developer suite with teh JDK that comes with it: hence 1.4 
Sorry Grant, but that's not true. I have successfully upgraded mine to 1.5, and this works fine. I simply installed the standalone JDK 1.5.0_16, and after this I renamed (DevSuite)\jdk to jdk_old, and copied the complete JDK folder from Program Files\jdk1.5.0_16 to (DevSuiteHome)\jdk. This works without any problems.
I had to do this, otherwise Reports Builder would cause Vista to go into "Vista Basic" mode, because JDK 1.4.2 is too old to be compatible with Vista's Aero system. Upgrading the JDK fixed this problem.
Oracle Support actually told me, that this approach was fully supported.
I believe a similar approach might be possible for 1.6, but as I havent tried, I can't tell.
You are right, its only software and everything is possible ;o) However, I was referring to the following document
And go to:
Certified JDKs
Specifically this is not a test that we in the Forms team run. However, if Support think this doc us superseded by another I'd be happy to be pointed to that.
I just checked MetaLink, and unfortunately, the SR where they told me this is no longer visible to me, it's a while ago - and I don't remember who handled that SR. I can only say for sure, that the support called this approach "fully supported", and that I haven't had any problems doing it.
The section in the document you talk about is for the Application Server, and he was talking about the Developer Suite - personally I wouldn't bother messing around with the Application Server, but with Developer Suite, it's a different matter. In my case I just had to solve an actual problem :)
That being said - you know, 1.4.2 is very old now... maybe it might be time for a new certification and a revision of that document?
In any case, I hope you include either JRockit (is that a JDK or just a JRE btw?) or JDK 1.6.0_10+ in Developer Suite/Application Suite 11g whenever it comes out "sometimes in 2009 if you ask nicely and promise to buy the entire Forms Development team, including the managers, a beer at the next OpenWorld" - would you release 11g faster if I made that promise? ;-) (Sorry, it's friday...)
Thanks, I really didn't expect it to be possible. The local VISTA policy police have only authorized Java 1.6; and want us to upgrade due to that. I need the confirmation in my on going fight with them.
I agree with Jacob that 1.4.2 is a bit too old and 11g should catchup to the latest JVM. 
11g will be released with later versions of the JDK 
From a Support point of view, changing the jdk in the ohome beyond 1.4.2 is not support and therefore not recommended.
Regarding thoughts of Oracle simply recertifying in order to support newer versions, well it isn't quite as simple as just waving the certification wand. Because of functionality changes in newer jdk versions, the Oracle product code may need to be changed in order to support it. This kind of change is not likely to occur.
If you choose to use a jdk version newer than 1.4.2 in the ohome, you do so at your own risk.
Michael Ferrante
Global Technical Lead
Oracle Forms