Mastering J2EE can be daunting, with an ever-growing list of technologies and acronyms. The Java Naming and Directory Interface (JNDI) has been at the core of the Java 2 Platform, Enterprise Edition (J2EE) from its inception, but it is often underutilized by novice J2EE developers. This article will help demystify the role of JNDI in J2EE applications and show how it can help decouple your application from the details of deployment.
The role of JNDI in J2EE
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I liked the bit about mysql only being for development!
J2EE (i don’t know about .net). You spend a year poring over huge tomes, ploughing through tutorials, battling the xml configuration files.
And at the end of it, what do you learn? You learn that J2EE is a job creation scheme. Designed to give you 3-letter acronyms, to obfuscate and jorgonise your CV. It makes simple concepts difficult to explain and do. JNDI is an example. The reason its a mysetry is because there is a willful attempt to disguise it. From data sources to database persistent objects … the whole jargon and hype is incredible.
I spent a long time last year going through it – inlcusing sun’s own J2EE tutorial, and at the end you get that familair feeling: “why didn’t they just explain it like this, in 2 pages!”.
How many people know the difference between JavaBeans and Enterprise Java Beans? There’s big difference actually. But in Sun’s attempt to make it inpenetrable, a percentage of potential new users are put off, the rest are confused for 6 months and the rest are resentful.
Is that you find Java too hard. Well, that’s your tough **** to be quite honest, mate.
Lots of us know what Java Beans are, what EJBs are, what JMS is, what JDO is, how to program Swing properly, what JSPs are, what the difference between JSPs and Servlets are (hint – not much).
Java is not hard.
Java, as a language is not hard. Java’s API, especially anything even remotely related to ‘enterprise’ applications, is convoluted beyond belief. “tech_user” is absolutely correct. They make even the simplest of concepts into a pile on undecipherable TLAs and jargon. Two example off the top of my head: LDAP and XML. The LDAP access API will turn your hair gray. The XML API…well… it should not be as hard as they make it to write a DOM tree to a file.
It’s all a marketing scheme. For every minor release of any spec, there is a whole new set of books, tutorials, training classes, certifications, etc. To be fair, it’s not just the Java corporate machine that indulges in these practices. Any reasonably successful ‘technology’ does this.
I’m to have to agree here that the ENTIRE Java platform is completely and unnecessarily convoluted, especially when it comes to J2EE.
Free, platform independant with no vendor lock-in? Bah! The systems you get are so convoluted beyond belief that you’re locked into who ever the hell you got the system or solution components from.
It’s little suprise how rapidly .NET is catching on in the enterprise in view of the massive spagetthi pile that is J2EE.
Java is easy. The Java platform is a sad complex attempt to lock you in while selling you “free”, “platform independence”, and “no vendor lock-in”. When you have to market using those terms, it just means your platform is so damn convoluted to be practical. Which incidently drives your costs up, makes you lose platform independence because it’s now next to impossible to move your system to another pltform and make sure it works, and you get locked into the original vendor for support. Wonderful.