This content has been marked as final. Show 7 replies
It seems that OpenSCG has not followed the version naming standards here: http://java.sun.com/j2se/versioning_naming.html
The first line from the java -version command shows this:
OpenSCG: openjdk version "1.6.0-OpenSCG-Build-21"
Java 1.6.0_26: java version "1.6.0_26"
Java 1.7 initial release (OpenJDK project-based): java version "1.7.0"
So, not to say that SQL Developer couldn't be made to handle it better, but perhaps the bug should be filed against OpenSCG.
SQL Developer Team
Nice to have the developers monitoring the foruns. Thanks a lot.
I'll follow you sugestion and ask the OpenSCG mantainers to update the version string to something like "1.6.0_21-OpenSCG". That would be acceptable, correct?
But as I understand the document you quoted is not part of the JCP standards, it's not part of the Java platform standards. It's about an specific product. So SQL Developers was not made to run on any standard, certified Java implementation. It was made to run only on Oracle (before Sun) Java product. :-(
Funy that accordingto http://www.oracle.com/technetwork/developer-tools/sql-developer/certification-096745.html no Oracle JDK release would pass the version test:
"Oracle SQL Developer is certified against JDK 1.6.11 or above."
There is NO JDK 1.6.11, it would be 1.6.0_11, am I right? ;-)
By the way, I am curious: why requiring a specific JDK update level, and not a standard compliance level? I searched for but could not find this information on SQL Developer web site.
I found a simple workaround: instead of sqldeveloper.exe on sqldeveloper install home, use sqldeveloper\bin\sqldeveloper.bat. I even changed the bat file to invoke javaw.exe instead of java.exe so I won't get the ugly Command Prompt window. So far it's running fine here under OpenSCG OpenJDK build for windows. :-)))
Please, consider making SQLDeveloper running without hacks on any open openjdk build.
s, Fernando Lozano
Very glad to hear you found a workaround. Others searching this forum will no doubt find it very useful.
A debug run through our version check code shows it's only interested in digits, dots, and underscores, ignoring everything else. So even our own algorithm does not conform to the java.sun.com doc (which pre-dates by far Oracle's acquisition of Sun) on standard version strings. The key is having an underscore appear before the update number (_21). SQL Developer will not care if it comes before or after the other OpenSCG verbiage.
As for using JDK compliance levels, I'm not so sure. Eclipse only uses two digits (1.4, 1.5, 1.6, 1.7) for its Java Compiler property setting. Oracle JDeveloper and SQL Developer require a version check to guard against Java bugs pertaining to specific update levels within a major Java release. But perhaps the compliance level standard supports a finer granularity, down to the update level.
Your feedback is much appreciated.
That sounds like work. The few bugs I have seen that fall into this category were logged as 'internal', which often means we caught them before the production release and customers were not impacted.
For example, one such bug, logged against JDeveloper (from which SQL Developer gets its IDE framework), complains that a cascading style sheet could not be generated because its path/filename was too long for Windows XP. That got filed in Jan '07 and relates to this Sun/Java bug filed in Oct '04:
Suffice to say these situations come up occasionally and even if a specific Java version is required to use our (free-of-charge) product, then at least the Java is also free-of-charge.
With OpenJDK the order of the day, I suppose any OpenJDK implementation provided through a partner/collaborator/contributor (Oracle, IBM, Apple, SAP and others(?)) for a specific OS platform would be considered 'official'. Presumably these implementations go through rigorous tests to certify their compliance with the Java language specification.
So in theory, yes, SQL Developer should run under any of these. Remember, the goal of "write once, run anywhere" was the reason so many businesses adopted Java in the first place. Anything getting in the way of that doctrine encounters resistance. For example, Microsoft once tried to make a proprietary JVM, but had to drop that as part of an out-of-court settlement with Sun. We actually expect, want, hope and pray that SQL Developer runs with each and every vendor's implementation. Fewer complaints that way!
In terms of something like Apache's Harmony project, I have no idea. IBM switched from that to OpenJDK, so perhaps OpenJDK is open enough for IBM but not Apache. This all seems very political, and well worth steering clear of.
As far as I am aware, development and QA for SQL Developer do their work on the Windows, Linux, and Mac OS platforms. Until recently, Sun provided the JDK implementation for Windows and Linux while Apple provided it for Mac OS. So, as a practical matter, if something in SQL Developer didn't work on those, we would find out about it in short order. Going forward, I imagine we will use the Oracle and Apple implementations, and would be very surprised if anyone on our team goes out of his/her way to test against other implementations. It is simply not feasible to test and certify each SQL Developer release with each JDK implementation.
If any 'dependencies on Oracle JDK internals' are present, I would think them accidental rather than intentional. Moreover, any such dependencies would most likely get caught before a production release if not also present in the Mac OS implementation.
Edited by: gggraham on Sep 21, 2011 2:21 PM