Develop Reference

Cross-platform building of code that uses sun.awt.windows.WComponentPeer [duplicate]

In JRE, Sun's internal packages are prefixed with 2 top-level domains (sun and com). For example,
com.sun.security.jgss
sun.security.jgss
It seems pretty random to me which prefix they choose. I am curious what rules Sun uses for this.

Not an answer to the question, but please be aware that you should not use 'sun' or 'com.sun' packages in your programs directly.
See Why Developers Should Not Write Programs That Call 'sun' Packages
Those packages are not part of the public API of the standard Java library, and using them might make your program incompatible with future versions of Java or implementations of Java other than the Sun implementation (and there are several implementations by other vendors, including Apple, IBM and HP).

The "com.sun" convention is the more preferable format because it follows the "naming conventions" that have been established for naming Java packages.
http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
You're supposed to use your unique company or personal website URL as the first few words in the package to guarantee uniqueness in the namespace. The ones that start with "sun" were probably not intended to be exposed to the outside world.

If you take a glance at the compatibility document for Java 5 you'll notice that there are other reasons too:
Apache - The org.apache classes, which have never been supported J2SE APIs but are used by the javax.xml package, have moved in 5.0 to **com.sun.**org.apache.package.internal so that they won't clash with more recent, developer-downloaded versions of the classes.
Any applications that depend on the org.apache classes being part of the J2SE release must do one of the following to work in 5.0:
* Code the application so it uses only the supported interfaces that are part of JAXP.
* Download the org.apache.xalan classes from Apache.

Warning When using AudioPlayer in Java [duplicate]

The compiler display warnings if you use Sun's proprietary Java classes. I'm of the opinion that it's generally a bad idea to use these classes. I read this somewhere. However, aside from the warnings are there any fundamental reasons why you should not use them?

Because they are internal APIs: they are subject to change in a undocumented or unsupported way and they are bound to a specific JRE/JDK (Sun in your case), limiting portability of your programs.
Try to avoid uses of such APIs, always prefer a public documented and specified class.

The JDK 6 Documentation includes a link titled Note About sun.* Packages. This is a document from the Java 1.2 docs, so references to sun.* should be treated as if they said com.sun.*
The most important points from it are:
The classes that Sun includes with the
Java 2 SDK, Standard Edition, fall
into package groups java.*, javax.*,
org.* and sun.*. All but the sun.*
packages are a standard part of the
Java platform and will be supported
into the future. In general, packages
such as sun.*, that are outside of the
Java platform, can be different across
OS platforms (Solaris, Windows, Linux,
Macintosh, etc.) and can change at any
time without notice with SDK versions
(1.2, 1.2.1, 1.2.3, etc). Programs
that contain direct calls to the sun.*
packages are not 100% Pure Java.
and
Each company that implements the Java
platform will do so in their own
private way. The classes in sun.* are
present in the SDK to support the Sun
implementation of the Java platform:
the sun.* classes are what make the
Java platform classes work "under the
covers" for the Sun Java 2 SDK. These
classes will not in general be present
on another vendor's Java platform. If
your Java program asks for a class
"sun.package.Foo" by name, it may fail
with ClassNotFoundError, and you will
have lost a major advantage of
developing in Java.

Try running your code with a non-Sun JVM and see what happens...
(Your code will fail with a ClassNotFound exception)

Yes, because nobody guarantees that these classes or API will be the same with the next Java release and I bet it's not guaranteed that those classes are available in Java versions from other vendors.
So you couple your code to special Java version and loose at least portability.

Sun's proprietary Java classes are part of their Java implementation not part of the Java API their use is undocumented and unsupported. Since they are internal they can be changed at any time for any reason that the team working the Sun JVM decides.
Also Sun's Java implementation is not the only one out there! Your code would not be able portable to JVMs from other vendors like Oracle/BEA and IBM.

Here is Oracle's answer: Why Developers Should Not Write Programs That Call 'sun' Packages

I recently had a case that showed a real-world problem you can hit when you use these classes: we had code that would not compile because a method it was using on a sun.* class simply did not exist in OpenJDK on Ubuntu. So I guess when using these classes you can no longer say things like 'this works with Java 5', because it will only work on a certain Java implementation.

Mixing Java 1.4 and 1.6 bytecode in a class hierarchy

The question first, the story will follow:
Is it safe to mix different bytecode version in a class hierarchy? What are the risks?
For a case, Class C extends B, Class B extends Class A. Class A implements Interface I.
My question would involve following example scenarios:
Class A compiled to Java 1.6 bytecode, and have 1.6 features such as generics, etc. The heirs, which are B and C was compiled to 1.4 bytecode.
Interface I compiled to 1.6, while the implementor compiled to 1.4.
Other exotic inheritance scenario involving different version of bytecode.
I have tried as many scenarios I could imagine and it seems to run just fine. However I still feel the urge to ask here as I only know Java at the surface; i know how to code and tweak Java but don't really know what happen under the hood.
Now for those minds who can't help themselves to ask "why would you need to do that???".
I'm in a project to assess the migration of legacy Java 1.4 Swing app, connected to EJB 2 via RMI, to Java 1.6 Swing connected to newer version of App Server running on top of 1.6 also. The J2EE platform will still be 1.4 (EJB 2).
The migration will not be "recompile everything to 1.6", but it will be "code and compile new features to 1.6".
The way they do things is like this:
They only have one path in the CVS, everyone commits there. No tags/branches whatsoever to get the production code.
Whenever a new feature need to be added, they get the JARs from production server, explode them, replace or add new classes as needed, repackage the jars, put them back to server.
Therefore, if they will use Java 6 to compile and using the above method for deployment, there will be a lot of exotic mixes of 1.4 and 1.6 bytecodes.

The JVM byte code is not siginificantly different between Java 1.0 and Java 6. In Java 7 they add one new instruction. Woohoo.
There are so little changes in how the byte code works that
The JVM doesn't support nested classes accessing private members of outer classes, this works through generated code.
The JVM doesn't support runtime checks for generics e.g you cannot new T() where T is a generic.
Basically, they make the JVM smarter and faster but until recently changing the model of how the byte code works has been avoided at all costs.

You can compile with Java 6 but target 1.4 with a compiler setting. We did this for a migration project once. If/when 1.4 disappears, you then change your compiler settings again and target 1.6.
Keeping the target version explicit also means that you can upgrade your SDK without fear of your JAR files becoming unusable to an older JVM.

I am maintaining an environment with mix of 1.4 (old library jars) and 1.5 (my fixes and stuff) classes on Tomcat using Sun JVM 1.5 and it runs fine.
However, for RMI you may be in trouble if client and server has different class version because the server might check the class version (I ran into this problem).
The best way to find out is to do a proof of concept type of project on small scale.
A friendly reminder though, you are digging a pretty big hole for yourself here :-)

These links seem relevant. They document the few edge cases that could break compatibility between 1.4 and 1.5 and between 1.5 and 1.6.
The biggest differences that could cause problems that I can think of is that enum became a keyword, but that would only effect a 1.5+ JVMs when loading an older class file (which doesn't seem to be what you will be doing). The other thing is annotations. The above links seem to suggest everything would be fine, but I would be wary about what would happen if an older JVM loaded up a class with runtime annotations.
Other than that I don't think there have been any bytecode changes between the first version of java and java 6. Meaning the only problems you should encounter are changes to functionality the API or deprecations (listed in the links above).

As long as you aren't using reflection, the only major problem you could have from differing bytecode versions is the ACC_SUPER flag.
In very early versions, invocation of superclass methods was not handled correctly. When they fixed it, they added a new flag to the classfile format, ACC_SUPER to enable it, so that applications relying on the old, broken, behavior were not affected. Naturally, using a class that doesn't contain this flag could cause problems.
However, this is ancient history. Every class compiled in 1.4 and later will have the flag, so this isn't a problem. Bytecode wise, the only major differences between 1.4 and 1.6 are the addition of optional attributes used to store metadata about inner classes, generics, annotations, etc.
However, these don't directly affect the bytecode execution. The only way these have an affect is if you access them through reflection. For instance, java.lang.Class.getDeclaredClasses() will return information from the optional attribute InnerClasses.

Why is org.ietf, org.omg, org.w3c, and org.xml part of the POJOs?

Hi all I was wondering how did the packages org.ietf, org.omg, org.w3c, and org.xml made it into the "official" Java classes ?
For example, it makes sense that the default JDK wouldn't have all the classes from Apache Commons,
By the same philosophy, shouldn't these org.w3c, org.omg packages be outside of the default JDK classes (i.e. not included within the JDK installation)?

These are all generally code representing standards, IETF, OMG, and W3C are all standards organizations. The code that you are referring to was created with these package names and was/is very widely used so it made sense to put it into the JDK with their original names. An exception to the standards name is the org.xml package. That has SAX which is an early Java/XML open source implementation of streaming XML event handling that became very popular. It's also code that is at the right level (a fairly low level) in the programming hierarchy so that it will be generally needed universally. Some of it is code that other parts of the Java runtime environment depend on.
Code in open source projects like Apache Commons is either not a standard or not required by other parts of the Java runtime, so there is no strong reason to include it.
Note in other cases, Sun/Oracle has added code external to the JDK to implement core features (Doug Lea's concurrency stuff comes to mind), but these packages were renamed into java packages.

Java JMC "MediaProvider" - mystery class

in a library i'm having problems with there is this class
com.sun.media.jmc.MediaProvider
which i want to have a look at.
i can't find a javadoc or anything for it, how do i find out its methods etc?

The classes of the package com.sun.* (and sun.*) are internal classes which backs the standard Java API. They are undocumented and subject to changes among versions and builds. You should in fact never make use of them in your Java code, else your code will break when you change the API implementation. Also see this SO topic.
In this case, the com.sun.media.jmc.MediaProvider is part of the Sun reference implementation of the JMF API (javadocs here). You are supposed to make use of the classes documented in the JMF API only. The (abstract) factories/builders will invisibly provide the Sun reference implemtations.

You should also consider Xuggler, which supports more codecs than JMF, is free and open-source, and is actively developed and supported (unlike JMF).