Silly URL...

6

6e

Im trying to reference a file on my own PC, not a remote serer... So my
question is it still possible to use URL? Or would that be considered
bad form even if I get it to work? or do you have another item that I
should be using in mind?
 
C

CliffMacGillivray

6e said:
Im trying to reference a file on my own PC, not a remote serer... So my
question is it still possible to use URL? Or would that be considered
bad form even if I get it to work? or do you have another item that I
should be using in mind?

Why not use the path to the file in the java.io.File constructor? Are
you doing something more than opening a file?
Is this even a java question!?!?
 
J

Joan

6e said:
Im trying to reference a file on my own PC, not a remote
serer... So my
question is it still possible to use URL? Or would that be
considered
bad form even if I get it to work? or do you have another item
that I
should be using in mind?

I was just looking into "file chooser" and my book has an example
of how you can add buttons to the file chooser to play an audio
clip after you select it. The sample code uses URL to access the
files on the local disk. I think it is needed in this case in
order to
use the audio methods.
 
C

Chris Smith

Joan said:
I was just looking into "file chooser" and my book has an example
of how you can add buttons to the file chooser to play an audio
clip after you select it. The sample code uses URL to access the
files on the local disk. I think it is needed in this case in
order to use the audio methods.

No, I don't think you are correct. The only connections between audio
APIs and sound are:

1) The Applet class has a getAudioClip that requires a URL. However,
you almost certainly don't have an applet anyway, if you are accessing
files on the local hard drive.

2) The JavaSound API has a couple API methods that can receive URLs to
specify the locations of sounds. These are MidiSystem's
getMidiFileFormat, getSequence, and getSoundBank, and AudioSystem's
getAudioFileFormat and getAudioInputStream. However, all of these APIs
also have identical overloaded functions that use File instead of URL.

So I'm pretty sure you don't need a URL. However, if you do, then the
best way to go is to get a File object first, and then say:

File file; // the file object you start with
URL url = file.toURI().toURL();

Then yes, you are perfectly fine using the URL to refer to files on the
local disk. This is actually guaranteed to work, as all Java virtual
machines are required to support the URL scheme for accessing local
files. However, since the exact syntax is platform-specific, the
conversion methods above are your best bet here.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
A

Andrew Thompson

So I'm pretty sure you don't need a URL. However, if you do, then the
best way to go is to get a File object first, and then say:

File file; // the file object you start with
URL url = file.toURI().toURL();

Then yes, you are perfectly fine using the URL to refer to files on the
local disk. This is actually guaranteed to work, as all Java virtual
machines are required to support the URL scheme for accessing local
files. However, since the exact syntax is platform-specific, the
conversion methods above are your best bet here.

I don't agree.

Because of my long experience with applets, I have come to loath
using File's for *reading* resources, except where absolutely necessary.

Note that while an URL can refer to a local File..

- A File cannot pull a resources.jar!/README.txt straight out of
the archive, while a (jar) URL can.

- A File cannot refer to a resource on an http site, or ftp, or..

About all I uses File's for is when I am working on the local system
in a fully trusted applet or application and need a
File.listFiles()/File.listFiles(FileFilter), or File.listRoots().
[ Oh, and all that *O* of I/O. ]

As a further note, you mention the "exact syntax is platform-specific"
as a downside. But how many times have you seen code similar to this?

File props = new File("resources\\properties.xml");

...use of File's can easily be made 'platform specific', purely by accident.

As far as getting a handle on the resource, I would recommend an
alternate route (where practical*).

Class.getResource() - removes the platform specific parts from needing
any programmer intervention, the rest is handled automatically (which
is good, since I have a devil of a time remembering the format of
those 'jar file' URL's!).

* Which it is not, if the resource is not on the classpath!

In any case, if I offer the end user a 'File' chooser, the returned File
will (generally) be converted to an URL within the next few code lines..
 
A

Andrew Thompson

Because of my long experience with applets, I have come to loath
using File's for *reading* resources..

[ ..or even getting a handle to the resource.. ]
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top