Installation error: Cannot find a J2SE SDK installed at path C:\Program Fi

Question

I am installing latest version of SQL Developer, Release 1.2. I have Sun Java 2 Standard Edition Version 1.5.0 (build 1.5.0_10-b03). When I browse and select the java.exe found it comes up with error: Cannot find a J2SE SDK installed at patch
C:\Program Files\Java\jre1.5.0_10
I am installing the version I downloaded for Windows systems with JDK1.5.
I have tried on two different machines.
Any ideas?

Answer 1

This is going to seem loooong, but comprehensive.
I'd initially always suggest using the bundled
package, since that's supposed to be a tested and
proven combination.You know what, I'm gonna be mighty surprised if you're implying that Oracle hasn't 'tested and proven' the releases at http://www.oracle.com./technology/software/products/sql/index.html other than the first 77 MB download labeled Oracle SQL Developer for Windows... :)
After having problems with a graphics card for
example, installing the latest JDK might be
indicated.Huh?!? Not a clue what you're talkin' 'bout! :S
It's also easy for users who don't know which Java
version to download, or even where to find it! You
guys have proven that: although it's stated you need
.First of all, it says right there on the download page (http://www.oracle.com./technology/software/products/sql/index.html) that:
"JDK 1.5 (JDK 5.0) is required. This is the minimum JDK version required"
And we've "proven that [..] although it's stated you need the JDK, [we]'ve tried running with the JRE" and have NOT been able to run the application. It just presents the user a dialog box to locate the 'SDK' manually and exits gracefully if you try to dismiss it. So, conclusively proven, the JDK (or as SQL Developer puts it, Java SDK) is required- QED.
And given users might have several versions running
on the same machine (I have half a dozen), sqldev
could easily pick up a wrong version.And every JRE installation (atleast all of Sun's) make sure they update the default (via PATH and other required system variables) JRE point to the latest one installed. So if you have anything 1.5+ you're good to go; if not, you've got an incompatile JRE. Doesn't sound that hard to me!
As for being bulky, even without the bundled JDK, it
still is.Ya missed the point. Developers are making Java applications bulkier by including the JRE/JDK with their distributions. A SQL Developer release sans JDK is about 46 MB; with JDK that climbs to 77 MB (sizes quoted from download page linked above).
Imagine what happens when you have, besides SQL Developer (JDK 1.5 included), some-cool-java-app that also includes the JRE/JDK it was built on; and then another-java-app that also includes a JRE/JDK... I bet JDeveloper also comes with a JDK bundled in. So, now you have FOUR copies of JRE/JDK (aside from the "have half a dozen" that probably installed themselves via Java Update Checker)!
Here's the big picture, the savings in disk space would only be the beginning of your benefits. Here's a few others:
- Class Data Sharing (http://java.sun.com/javase/6/docs/technotes/guides/vm/class-data-sharing.html) introduced in Java SE 5.0 provides for storing definitions of commonly used classes in a representation closer to machine code, even closer than bytecode, this reducing load and startup time. Plus all VM's launced using that particular distribution get to share the cache- Performace+ !!
Running each app offa' it's own VM just causes multiple caches to be loaded. You just multiplied your losses! :(
- Sun is currently working on a way to have applications simply inject into a running JVM. That way, there is no load and startup time for the JVM, just the time to load you app classes. Using different distros would completely defeat this!
(The reason why this feature isn't out yet is because they're still trying to make it possible to specify hitherto VM configurations like security and logging as application configurations. Then there's also the issue of setting up class loading boundaries between applications.
You say you don't have to bring over the VB runtime
for each app? I remember in the 90's doing it all the
time. Of course, being MS, now that's not necessary
anymore, since it's "magical" Windows. I don't have
any machine from Sun, but for sure they've got Java
bundled with it, right?I don't believe you had to do that since VB 5; and that's because MS realized that they messed up on this very point upto then! Sun worked the simple solution to that into their deployment strategy- install only ONE runtime and run all apps off that. As for you're half-a-dozen, I think you can safely uninstall the five older versions; because, even today, people are running apps developed using JDK1.1 on Java SE 6.0!
Again, I find the most logical difference between JRE
and JDK being the debugger. As you say it yourself:
JRE for end-users, who don't need to do any
debugging.
Now, sqldev is not just a table browser, but also for
debugging PL/SQL. 1 + 1 = 2.I think it's a little naive to differentiate between the JRE and JDK on just the debugger! Aside from the obvious inclusion of a compiler, the JDK has several other tools for monitoring/managing the heap, threads and logging on the fly. There's also the Doclet API and Sun's javadoc implementation, dev interfaces for instrumenting the VM, native interfaces, ...
And I reiterate, we're talkin' PL/SQL developers here. Why would I want to give a PL/SQL developer a Java Development Kit?!? ;|
Nevertheless, as said in the other thread, if the
team discloses how to circumvent the SDK check at
startup, you can go ahead and use the JRE. In any
case, you'd have to agree that won't work as
out-of-the-box solution...You're right, it won't work like a standard Windows OOTB app. But, it WILL work as a Java OOTB that only mandates that there be a JRE available; just like the scores of Java apps out there- from tiny little Pong clones to large IDE's like NetBeans.
BTW, don't even think about quoting Websphere/Rational/Eclipse as counter-arguments. They are the biggest offenders as far as this issue goes. And jikes is an abomination, a curse Sun must carry as a result to opening the VM Spec. But, I digress...