why this java code isn't cross platform ?
Hi all,
Map volumes=new HashMap();
File[] f = (File[]) sun.awt.shell.ShellFolder
.get("fileChooserComboBoxFolders");
for (int i = 0; i < f.length; i++)
volumes.put(fsv.getSystemDisplayName(f[i]), f[i]);
this code runs well on windows box ; but the map is empty for both Mac os and Linux boxes .
is there an explanation for this ? how to get the same resultes for Mac & Linux as for windows.
thanks & Happy holidays !
> sun.awt.shell.ShellFolder
This class is not a part of the standard API and it is provided specifically for Windows to retrieve larger (32 by 32) desktop file icons and stuff like that. It won't work on other platforms.
http://www.onjava.com/pub/a/onjava/2005/08/10/swinghacks.html?page=last
> File[] f = (File[]) sun.awt.shell.ShellFolderWhere did you find that package?kind regards,Jos
On Linux FC5 using JDK1.5 and 1.6 I get one entry of '/' .
darn, when I started replying there were no previous replies yet ;-)kind regards,Jos ( < slowest old sod )
> darn, when I started replying there were no previous> replies yet ;-)> > kind regards,> > Jos ( < slowest old sod ):-( But still faster than me!
> > darn, when I started replying there were no previous replies yet ;-)
> >
> > kind regards,
> >
> > Jos ( < slowest old sod )
>
> :-( But still faster than me!
I'm not going to say it; I'm not going to say it ;-)
kind regards,
Jos
[url=http://java.sun.com/products/jdk/faq/faq-sun-packages.html]Why Developers Should Not Write Programs That Call 'sun' Packages[/url]
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. In other words:
The java.*, javax.* and org.* packages documented in the Java 2 Platform Standard Edition API Specification make up the official, supported, public interface.
If a Java program directly calls only API in these packages, it will operate on all Java-compatible platforms, regardless of the underlying OS platform.
The sun.* packages are not part of the supported, public interface.
A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.
For these reasons, there is no documentation available for the sun.* classes. Platform-independence is one of the great advantages of developing in the Java programming language. Furthermore, Sun and our licensees of Java technology are committed to maintaining backward compatibility of the APIs for future versions of the Java platform. (Except for code that relies on serious bugs that we later fix.) This means that once your program is written, the class files will work in future releases.
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.
Technically, nothing prevents your program from calling into sun.* by name. From one release to another, these classes may be removed, or they may be moved from one package to another, and it's fairly likely that their interface (method names and signatures) will change. (From the Sun point of view, since we are committed to maintaining the Java platform, we need to be able to change sun.* to refine and enhance the platform.) In this case, even if you are willing to run only on the Sun implementation, you run the risk of a new version of the implementation breaking your program.
In general, writing java programs that rely on sun.* is risky: they are not portable, and are not supported.
~
> I'm not going to say it; I'm not going to say it ;-)> Stop trying to bite your arm off! Just come out and say IT.
> > I'm not going to say it; I'm not going to say it ;-)
>
> Stop trying to bite your arm off! Just come out and say IT.
No, my parents raised me to be polite and all that. I'll bite my left leg off
now, ok?
kind regards,
Jos ( < always polite towards slow old sods ;-)
thanks yawmark for detailed reply : it enlightened me a lot on the sun package issue.
Now is there a hack or workaround to get all File[] object in a JFileChooser combo box Folders like what the above sun shell class is doing ?
I'm guessing it should be a way to get a reference to this combo box component inside the JFileChooser then we can probably ask it to return it's data Object...
I'm not sure but seems to be a difficult thing to do . am I right ?
Any cross platform solution to this issue will be greatly appreciated.
thanks.
> Any cross platform solution to this issue will be> greatly appreciated.> I still can't see what you are trying to achieve.
> > Any cross platform solution to this issue will be
> > greatly appreciated.
> >
>
> I still can't see what you are trying to achieve.
in JFileChooser there is a look in ComboBox at top from which you can quickly select drives and folders of user machine.
I want to get theses drives and folders (cross platform) but without using a visual JFileChooser. i mean i can behind the sene ask a JFileChooser to return theses drives & folders .
is this a possible thing to do ?
Check File.listRoots() to see if this does what you want.
