14

Today one person told to me that "Java EE programmers do not write to files". Why can I not write to files from within a Java EE container (for example from JBoss)? What is wrong?

AMIC MING
  • 6,130
  • 6
  • 44
  • 61
Volodymyr Bezuglyy
  • 14,337
  • 31
  • 96
  • 124

8 Answers8

32

You should do everything within the Java EE container itself: you can have no certainty that you will have any consistent access to the filesystem. There are many reasons for this, the most obvious being that applications running within a container will have:

  • no certainty that any subsequent invocation of an EJB would even be on the same physical server with access to the same files/filesystem (e.g. upon clustering)
  • no possibility of interfering with each other (multiple applications attempting to write to the same file)
  • no security issues (one app writing confidential data which another app could read)

You should also assume that you shouldn't:

  • create your own threads (the container will manage this for you; if you create your own you may starve other applications in the container of CPU time)
  • use socket-IO (also has security issues)
AMIC MING
  • 6,130
  • 6
  • 44
  • 61
oxbow_lakes
  • 129,207
  • 53
  • 306
  • 443
16

The best page to look at is this one: http://www.oracle.com/technetwork/java/restrictions-142267.html

It covers in detail the restrictions over the Java EE programming model.

Apart from the point mentionned above Security, Portability, Clustering, Threading also consider transactions and error handling (File systems are not transactional).

There is however no black magic happening in the JVM and you can create files (as long as you have the corresponding rights), use static variables, and create threads if you know what you're doing.

Better take the time to understand why these restriction are usually suggested, than to jump and write a JCA connector for the sake of being compliant.

cassiomolin
  • 101,346
  • 24
  • 214
  • 283
ewernli
  • 36,434
  • 4
  • 82
  • 119
  • 4
    Whilst there may be no "black magic", the JVM security manager of the container may have been set so that file creation is not possible – oxbow_lakes Nov 24 '09 at 21:08
  • 1
    @BorisŠuška This link looks very similar to the original: http://www.oracle.com/technetwork/java/restrictions-142267.html – ewernli Jan 31 '13 at 15:02
5

Even if you have access to the filesystem, with distributed systems you can't be sure that the next time a method is called, it will be handled on the same machine where the file was written.

Bozho
  • 554,002
  • 136
  • 1,025
  • 1,121
5

Per Java EE specifications, EJBs are strictly prohibited from accessing any external resources by any means other than through a "resource manager" (JDBC, JNDI, JCA, etc) and this includes especially access to the local file system through classes of the java.io package. Additionally, nor can a ClassLoader be used for such access, such as to load a properties file from the application's classpath.

Reasons for this have already been given in other answers:

  • Security issues
  • Portability issues
  • Clustering issues
  • Threading issues

Ultimately, the best resource for these matters is a database.

AMIC MING
  • 6,130
  • 6
  • 44
  • 61
Pascal Thivent
  • 535,937
  • 127
  • 1,027
  • 1,106
3

If your instance is not clustered or one can guarantee that all instances can use a network drive then its not really a problem to use the File apis to read/write files. However care must be taken to get paths right and clean up as appropriate. Often there are not any real needs to write files so think about it again. The main reason most people give is that in a cluster different servers wont see the same file bcause paths change and so on. In the end most many small apps dont run in such a cluster...

mP.
  • 17,011
  • 10
  • 66
  • 101
3

You should consider a Filesystem as a Enterprise Information System (EIS). Then you can create a ResourceAdapter which accesses this EIS, similar to a JDBC adapter which accesses a database. The spec is here: http://java.sun.com/j2ee/connector/download.html . This means file access is possible, but much more complicated. This spec even allows you to create some sort of "threads" called Work.

Luzifer42
  • 678
  • 3
  • 7
2

Because the Java EE spec doesn't offer an API to write files. Of course, you can just use the normal Java IO API to create files but you must make sure that this code is thread safe, that someone cleans up the files, that the file name is passed on to the next bean, that the file is migrated when your bean is moved to another node in the cluster, etc.

So while you can do it, in practice, you'll encounter lots of small problems which make handling files in Java EE really hard.

AMIC MING
  • 6,130
  • 6
  • 44
  • 61
Aaron Digulla
  • 297,790
  • 101
  • 558
  • 777
  • Nonsense - the J2EE spec does not offer its own API for a lot of things, such as the generation of images on the fly. – mP. Nov 24 '09 at 12:01
  • And your point is? If the image generation API is J2EE compatible, then all is well. When it isn't and creates local files, you're in trouble. But it's a fact that the IO API is not J2EE compliant. – Aaron Digulla Nov 24 '09 at 13:48
1

In order to inter-operate with a legacy non-j2ee systems, you occasionally have to do "bad things" like socket i/o, writing to files, etc. In the best of all worlds the j2ee spec would be followed strictly, but people get away with non-j2ee stuff all the time for the sake of expediency and getting the job done. There are ways to pull these things off safely and thoughtfully.

Angelo
  • 3,445
  • 3
  • 25
  • 39