As Simon Brown pointed out the J2EE specification restrict you to access files on the file system but sometimes you have to and then you need to control the damage by keeping the breach of the specification local and not to spread it all over your code. Being confronted with this question just recently I came up with these ‘solutions’:

• Putting a file into the archive and read it out as resource. Note that you can only read from this file.
• Using a JNDI environment entry containing the path to the directory and/or file that then can be used to open the file later in the code. This allows the deployer to adjust the value before deployment so that it points to a valid file/directory the application can read from and write to.
• Using JCA to expose a connection to a file that allows the client to retrieve the connection and then open an input stream like you do with an URL.

First I was thinking that only a file service (like JDBC or JMS) provided by the server could solve the problem. But after thinking it through using Entity Beans seems to be a much better way to share the data on a cluster than through a file service. Then I realized that maybe each deployed EJB needs to have its own file that is not shared on the cluster. I think it is very important for each J2EE developer to see that there is much more between heaven and earth that a specification can ever capture. But it is important for the future of the code/project that ‘unportable code’ is kept localized and under control and that the assumptions and restrictions of that code is documented well.