Actually, the reason listed in the spec is because java.io.* isn't "well-suited" compared to things like JDBC for business data access. Sounds a little murky to me. If you use the resource bundle manager you wouldn't (directly) be using java.io, but the access is read-only.
Customer surveys are for companies who didn't pay proper attention to begin with.
What is JDBC backed ResourceBundle.....First time i am hearing of such a thing and would like to know more :roll: Simon, Out with all the kitties in that bag
sharp shooter, and author
Joined: May 10, 2000
Originally posted by sandy ind: Simon, Out with all the kitties in that bag
Well a ResourceBundle is an abstract class, with concrete implementations including a properties file backed bundle, where the resources are loaded from a properties file. So why not write another concrete implementation that loads the resources from a database? [seems a little off-topic from J2EE/EJB now!] Simon
Originally posted by Tim Holloway: [QB]Actually, the reason listed in the spec is because java.io.* isn't "well-suited" compared to things like JDBC for business data access. Sounds a little murky to me. I'm not sure what the wording of the spec is, but I can think of a practical reason for avoiding I/O in EJB. I/O operations can block. Blocking makes threads unrunnable. You aren't managing the threads, the EJB container is. The container won't know what you did (at least not without a lot of introspective effort). Doesn't sound like a great situation for holding a container responsible for managing resources.