It's Time to 'Re-Align' the JCP? 79
jgeelan writes "The original glorious premise behind a J2EE container was to abstract multithreading issues, server memory management, wire protocols, and so on, from Java programmers and allow them to focus on implementing solutions, not server infrastructure. Yet in the current issue of Java Developer's Journal, the director of technology at Personified Technologies, Jason Weiss, has lit a flame under J2EE, the jewel of the Java specification crown. The spec, writes Weiss, is too complex. As a community Java developers must pay attention to the beleaguered JCP process and realign it with creating solutions, like those routinely released by the Apache Software Foundation. Weiss argues that by taking steps now, Java developers would be investing in the future both of Java and the community that has grown up around Java. 'The entire JCP process must thematically reflect our desire to build solutions that simplify complex technologies for programmers,' Weiss continues. 'In fact, the JCP process should continue to use the JSR acronym, but with new meaning: "Java Solution Request," he adds.
'Somewhere during this journey the JCP has shifted from its solution-oriented roots to merely implementing specifications. This trend must be reversed ... for the sake of our community.'"
about damn time (Score:2, Interesting)
The things that J2EE aims to accomplish can be (and have been) done with far less in a more architecturally palatable (read sensible) and scalable way. Please, please. I hope J2EE dies.
Re:about damn time (Score:2)
Re:about damn time (Score:2)
I've found that building my own server, but using some of the simpler protocols like JMS, JDBC, the whole XML set is easier than trying to fit my logic into a J2EE server.
You need a server to answer JMS requests?
while (true) {
process(queue.receive());
}
You need to to answer multiple messages in parallel?
while (true) {
final Message message = queue.receive();
new Thread(){
public void run() {
process(message);
}
}.start();
}
What is hard about that? Why do I need a billion dollar copy of WebSphere for that? And that is what I have seen companies using WebSphere for, because that is what IBM is seller J2EE for.
I think that the important technology is the low level APIs, not the server chunk of J2EE. And MS does have good APIs that perform the same function.
Joe
Re:about damn time (Score:5, Informative)
You don't. You use JBoss [jboss.org]. Why would you build your own server from scratch when you can already customize and extend the JBoss core server as much as you need (be it for J2EE purposes or not).
Re:about damn time (Score:2, Insightful)
We had a home grown web server that was extremely secure because we hard coded the only two files it would serve. It was small and fast. It was less than 100 lines of code. Management required that we junk it and install Apache. Apache's configuration file is over 600 lines! I have the same problem with the rest of the J2EE server infrastructure. Normally what comes prepackaged as 10,000s of LOC can be written from scratch for my specific domain in a couple dozen LOC. I can completely understand those couple dozen LOC, where as I have a rough time understanding just the configuration of Apache, WebSphere, JBoss, etc.
Re:about damn time (Score:1)
I guess there's nothing to a server in case you don't need pooling, caching, transactions, security.
But then your server sucks hairy old goat balls.
that was extremely secure because we hard coded the only two files it would serve
Ahhh! All middleware problems solved! Congratulations.
JMS does a bit more than that (Score:2)
One of the best criticisms of J2EE is in fact just this: EJB, JMS and so on allow blue-collar engineers to build really serious enterprise scale systems, but in fact most systems do not need anything like the firepower J2EE provides, and most engineers don't even know what XA *is*. It therefore gets used in lots of cases where it is analagous to using an Apache helicopter gunship to crack a nut. The average website just doesn't need most of J2EE.
This is what MS were playing on, whether they realise it or not, when they rewrote the pet-store application using ADO alone a claimed some incredible speedup. J2EE is just not needed, even some something like Amazon. Certainly not for Slashdot. Banks and airlines do need it, but not everyone works for a bank or an airline.
Re:JMS does a bit more than that (Score:2)
Banks need something much simpler than J2EE that can be completely understood. Airlines need something that is more efficient than J2EE. Once you implement a system in J2EE that is efficent, you will have removed all the OO effects that make it convenient. You might as well have implemented it in COBOL.
Joe
I would (Score:4, Interesting)
The reason they end up with J2EE is it is *relatively* cheap and reliable, standard and easy to find developers for, while allowing for distributed transactions that ensure their databases don't become corrupt. That tends to be what really matters to them: if the system fails, which it will, regardless of what it was written in, and we bring it back up, will it Just Work ?
Oh please... (Score:4, Insightful)
Re:about damn time (Score:1, Insightful)
Yes, because as we all know, relational databases are not part of the "real world" of the enterprise middleware.
Moron.
nice try (Score:2)
Re:nice try (Score:3, Informative)
2) A well written CMP2 engine will give you a great deal of flexibility on how JDBC is used (read-ahead buffering, load groups, etc.)
yes, but... (Score:2)
In the end, the whole exercise gets you no closer to a solution with a whole lot of baggage.
Re:yes, but... (Score:2, Insightful)
the abstraction is there however, today I can easily switch between different databases I use for my projects (from postgres to oracle for example). The abstraction exists there to a level where I can use these tools to manage most of the migration of the db schema from one db to another.
The performance issues are a matter of configuration of the CMP engine. My code stays the same. The abstraction is very real.
Re:about damn time (Score:1)
That's about the most stupid thing you can do at the server side.
Specifying Java (Score:3, Insightful)
This is not just a matter of corporate policy. When I worked at JavaSoft, I actually met people who would not distribute their specifications in editable format, for fear of losing control of same.
Whats interesting is also that (Score:2, Informative)
js
IDE is the missing link (Score:1)
I'm working with Eclipse on Solaris; Dog slow. not sure why.
I love IDEA from intellij.
But neither of them allow WYSIWYG jsp development coupled with Automatic definition of Data bindings.
Maybe Dreamweaver MX will get it right.
Re:IDE is the missing link (Score:1)
Re:IDE is the missing link (Score:2, Informative)
Re:so ... (Score:1)
Re:IDE is the missing link (Score:1)
Re:IDE is the missing link (Score:2)
good point about data binding though. JSTL is not the answer, at least to me.
J2EE is the C++ of our time (Score:5, Insightful)
Oh, come now. The jewel of the Java spec crown is the JLS itself -- Java's a gorgeous language (complaints from Lisp and Smalltalk purists aside), it's the language itself that won developers' hearts, and it's the language itself that underpins the good work of all the other specs.
J2EE is nobody's jewel. It's more like what C++ was about 15 years ago -- big, ugly, stinky, convoluted, overfeatured, overspecified, yet still incomplete, and works best if you just pretend that certain parts of it just don't exist
And, like C++, in about 10 years somebody will come along with something much better that looks like the vague picture of perfection we all almost have now, something cleaner and smarter, which picks the right problems and solves them well -- something that does to J2EE what Java did to C++.
The question is, will that something in 10 years also be a specification based on the Java language? That's what I think Jason Weiss's questions may really drive at. And I'm not willing to take guess at the answer.
Re:J2EE is the C++ of our time (Score:3, Insightful)
- why are packages and classes treated differently? They are both just namespaces.
- Why can't I 'Object i = 5;'? There should be a 'void*' type.
- Why can't I 'Method m = Object.toString;'
- Why can't I
Object f(String s) {something(s);}
Object f(List l) {somethingelse(l);}
void main(String [] a) {
f(a.length == 1
? a[0]
: Arrays.asList(a));
}
and get the right method called!?
- Why can't I 'import java.util.*String*;' or 'import java.*.*;' ?
- Why do we have 'new' instead of alloc and init? ObjC/NeXTSTEP used '[[MyClass alloc] init]' seperating the process of allocation from initialization. It would even allow MyClass to return an instance of a different class, so if you need to make a short term change to the system (ie. replace all occurances of MyClass with MyClass2), just change MyClass.alloc to return a new instance of MyClass2 instead.
- Why aren't static methods inherited?
public class MyClass1 {
static MyClass1 alloc() {}
}
public class MyClass2 extends MyClass1 {}
public class Main {
public void main(String [] a) {
MyClass1
arg. And these are just off the top of my head.
Joe
Re:J2EE is the C++ of our time (Score:5, Informative)
You don't want a "void*" type; you just want int and the other primitives to be fully privileged objects (subtly different). This is probably the most common criticism of Java, and it's reasonable. There are also reasonable arguments for having primitives apart from objects, however. They didn't do this without some thought. Still, I lean toward your opinion on this one.
Why can't I 'Method m = Object.toString;'?
Reasonable -- it's a little shorter than Method m = Object.class.getMethod("toString", new Class[0]). But it's not a big issue -- in most cases where you'd use that, an interface paired with an anonymous inner class is more appropriate (and typesafe).
Why can't I [stuff] and get the right method called!?
Because that's a pretty wacky idea. Think for a moment about the implications of what you're proposing here -- x ? y : z is an expression...what is its type?
You could make this work, but would it be worth the hideous mess it would make of the spec to save you from having to type the words if and else?
Why can't I 'import java.util.*String*;' or 'import java.*.*;' ?
Because it poses tremendous potential namespace conflict problems with little clear benefit.
Why do we have 'new' instead of alloc and init?
Separating instantiation from initialization is reasonable; static factory methods do this just fine, but require foreknowledge of the problem. Such a facility, however, would still need to provide the guarantee that you can't actually obtain a reference to an object until it's fully initialized, which is where a naive implementation looking like like MyClass.class.alloc().init() would fail.
Why aren't static methods inherited?
Because that's an absolutely hideous idea. Static methods aren't part of the signature matching that underlies the type system, and don't participate in polymorphism; they are semantically equivalent to methods on the class, not the object (which is how Smalltalk does it).
I'd add to your list the lack of generics (which they're working on [jcp.org]) and some of the unpleasant aspects of the memory model on multiprocessor machines.
Re:J2EE is the C++ of our time (Score:2)
Yes, but most people don't understand that so I worded it the other way.
it's a little shorter than Method m = Object.class.getMethod("toString", new Class[0])
It is also compile time, not run time.
Because that's a pretty wacky idea.
Using the types of the arguements for the method lookup is not wacky. Haskell does it. I don't know the right words to use, but it is like polymorphism including the arguments, not just the target. I would save using lots of switch statements that just switch on the type of the argument. I suppose in most cases you wouldn't need it and it would unecessarily significantly slow down the method look up. Not wacky, just dumb.
Because it poses tremendous potential namespace conflict problems with little clear benefit.
If I could use patterns for imports than we would put fewer classes in packages and have a bit more organization to the packages. With more packages I could be more selective about what I want to import instead of exact match or package.*.
Because that's an absolutely hideous idea. Static methods aren't part of the signature matching that underlies the type system, and don't participate in polymorphism; they are semantically equivalent to methods on the class, not the object (which is how Smalltalk does it).
OK. I guess I just have problems with static methods. This goes back to implementing alloc().init(). You can't do it with static methods. If I could use a subclass of Class then I could add the methods there and be happy (is that the way to do it in smalltalk?).
I use arrays in cases where I need type safety, though generics would be better. I just hacked up something [soliddesign.net] that is close to generics with Proxy. You still have to specify the interface to the resulting class, but you don't have to write it. This would solve some problems I had with clients that really needed the type safety and needed more complexity than just arrays.
Joe
Re:J2EE is the C++ of our time (Score:4, Informative)
Java does use the types of the arguments. For example, the following will do what you want:
Object f(String s) {something(s);}
Object f(List l) {somethingelse(l);}
void main(String [] a) {
if(a.length == 1)
f(a[0]);
else
f(Arrays.asList(a));
}
The reason the code you posted doesn't work isn't that Java doesn't use the compile-time types of the arguments to resolve overloaded functions. Rather, it's that x ? y : z is an expression, and it needs to have a single type. What is that type in your example? Do you want expressions to have a set of possible types, like {String,List}? That's what I was saying would play hell with the spec. Or do you want the expression to have the type Object, and have overloaded function resolution use runtime types? If so, you lose a lot of compile-time type checking.
The reason Haskell lets you do this is that it's much more weakly typed than Java. Personally, I like the strong typing, and I think the inconvenience here is minimal.
I guess I just have problems with static methods. This goes back to implementing alloc().init(). You can't do it with static methods.
Actually, you can. What you're looking for is the static factory method pattern. Here's an example that returns a single shared "empty instance" of a class if an argument is null or empty:
public abstract class Thinger
{
public static create(String thingerValue)
{
if(thingerValue == null || thingerValue.length() == 0)
return EMPTY_THINGER;
return new Thinger(thingerValue);
}
private static final Thinger EMPTY_THINGER = new Thinger();
private Thinger()
{
private Thinger(String thingerValue)
{
}
You then say Thinger.createInstance("foo") to use it. The static method takes the place of your "alloc", and the constructor is the "init". You can also use this technique to return a subclass of Thinger; give the subclass a package-private constructor if you're worried about outsiders instantiating it.
I think this does everything you want. The only problem with this technique is that you have to know that you're going to do it ahead of time -- you can't retrofit a constructor as a static factory without breaking the API.
generics
Your proxy thing is nifty at a glance. Generics are supposed to be there soon -- quite possibly in 1.5 -- and promise to be good.
Re:J2EE is the C++ of our time (Score:2)
So how do you instantiate a subclass of Thinger? You write another create method. Wouldn't it be nice of ThingerSubclass.create(String s) called Thinger.create(String s) and assigned this to ThingerSubclass.class so you didn't have to copy and paste the factory method? What is so hidious about that?
Joe
Re:J2EE is the C++ of our time (Score:2)
Right, but you lose all kinds of compile-time type safety if the language allows your example. Think through the static typing of your example's parse tree -- if we allowed the code you suggest, you also have to allow f(new Object()) to compile, even though there would be no matching method at runtime.
So how do you instantiate a subclass of Thinger? You write another create method.
Not necessarily -- you can have a single method that dispatches to a bunch of different constructors: return foo ? new Quux() : new Fruux();. If you have all the different subclasses in the same package, you can keep the constructors package-private.
If your subclasses are all in different packages, and you want to control instantiation within your project, I suggest you take a look at Macker [innig.net] (see sig).
Re:J2EE is the C++ of our time (Score:1)
public static Thinger create(String thingerValue)
{
syncrhonized(Thinger.class)
{
if(thingerValue == null || thingerValue.length() == 0)
{
return EMPTY_THINGER;
}
return new Thinger(thingerValue);
}
}
js
Re:J2EE is the C++ of our time (Score:1)
Re:J2EE is the C++ of our time (Score:2)
- why are packages and classes treated differently? They are both just namespaces.
Because classes define the behaviour of instances, whereas packages are just namespaces ? The only reason packages exist at all is to break up the class namespace.
- Why can't I 'Object i = 5;'? There should be a 'void*' type.,
No there bloody well shouldn't, but there certainly should be type that is a sypertype of both the primitive and the reference types. I would personally prefer something between the "everything is an object" model of Smalltalk, and the automated boxing and unboxing of the .NET languages. The current system is pretty nasty.
- Why can't I 'Method m = Object.toString;'
I don't know. It would be a lot nicer, wouldn't it ? Probably because reflection only appeared in 1.1, and changing the way the class namespace worked to allow this would have broken existing code.
- Why can't I [stuff] and get the right method called!?
Because Java doesn't do multiple dispatch. It only does static method overloading. The example you give (and multi-dispatch in general) conflicts rather with being statically typed. There are, of course, well known cases where multiple dispatch is useful, but they're not *that* common, and one of the design goals of Java was not to scare C++ programmers.
- Why can't I 'import java.util.*String*;' or 'import java.*.*;' ?
Ewww.
- Why do we have 'new' instead of alloc and init?
Given that instantiation is not polymorphic, I don't see what the benefit would be. Having said that, it would be nice for instantiation to be polymorphic, but it is hard to do without metaclasses, and once again static typing might get in the way
- Why aren't static methods inherited?
They are. If f() is static and visible on X, and Y extends X, you can call Y.f(). It isn't very useful, though, because they aren't polymorphic. A method in X that called f() would always call X.f(), rather than Y.f() even if it was actually invoked on an instance of Y, and Y had another method f() that hid it.
If that is what bothers you, you really need metaclasses. In languages with metaclasses the class of an object is represented by an instance of a unique class (the metaclass), specific to that class. The metaclass can define methods and data that the class will possess. f() above would be a method on the metaclass of X and Y, so Y could polymorphically override it.
The fact most readers of this comment will already have given up, have their toungues lolling out, or be preparing to flame me for suggesting anything so obviously stupid and useless (ie. not in C++), should given you a clue as to why the designers of Java did not do this.
Re:J2EE is the C++ of our time (Score:2)
--
package test;
public class Test2 {
static public class A {
static public class B {
static public String c = "C";
}
}
static public void main(String [] a){
System.err.println("test.Test2A.B.c="+test.Test2.
}
}
--
Why differentiate packages from classes?
Ah, 'multiple dispatch'. That was the term I was looking for. After more thought this afternoon, I have to agree that the efficiency trade off would not be worth it all the time, but it would be a nifty answer to the huge switch statements that occur when parsing.
Ah, 'meta classes'. Another term. That would fix that problem.
I guess the only difference we have is import with globing or regular expressions. I just figure that the extremely limiting import a package, but not a group of packages is a silly limit.
Thanks for taking time out this afternoon.
Joe
Packages and classes (Score:2)
Re:J2EE is the C++ of our time (Score:5, Informative)
A fourth capability, in the first released version of java, but not used to its fullest capacity until Java2, was the use of "interface" over abstract base classes as a means of building frameworks in the newer library components such as JDBC, Collections, and XML. C++ always had this, but "interface" is a much simpler syntax and means of expression verbally over "abstract base classes with only pure virtual functions" (the C++ version of a Java interface). Also, newer C++ libraries and designs tend to rely on templates and traits to enforce an interface (ala generic programming) rather than class design, because its easier to just write a class than to design a hierarchy -- java's "interface" took the hierarchy out of places it didn't need to be).
Now, one of those ended up an utter failure (AWT), and its replacement (Swing) though amazingly more successful as far as design and power goes, is as noted dog-slow (though its something that does get faster as machines get faster; moore's law does help Swing considerably). I personally love swing just because (when used properly) the WORA DOES work (layout management is the #1 problem for almost every bad interface out there, and that's not unique to swing; i recall a lot of bad motif layouts too from windows programmers not used to Xt's approach); also, the power in using renderers for complex components and dividing up responsibility of showing the look vs managing the data, is something i miss in any other gui library out there.
The second, the standard networking library tied to the I/O library, remains its brilliant point and the basis for Java's most successful libraries and projects, including all its server-side work. Bjarne is most impressed that the standard socket + stream library that works on ALL platforms (its the one that's most reliable in that respect of WORA) that he's planning to propose a standard socket interface to C++, though I think its now too little too late. I'm not saying that java.net and java.io aren't flawed. The use of abstract base classes for Socket and URLConnection, which likely dates to before the interface keyword was introduced is a "bad thing"; java.util.Dictionary was like this as well, but at least that's been deprecated out. Similarly, java.nio addresses most of java.io's problems, but at the considerable cost of code simplicity; if you need java.nio, it'll take a lot of time and work to use it correctly, and few books and articles are really making it clear when you actually need it. In the early stages of new technology, the "how do i use it" well-buries the "when do i need it" question.
The language itself has remained simple, with only 2 partially-incompatible changes over the years (inner classes including anonymous, and assert), and this may be its one saving grace against C# (which has a more complex syntax, but currently a much simpler library based on a cleaner syntax to most of MFC -- that will change in the future as M$ will always code-bloat their products).
The "interface" syntax is to me still Java's most powerful feature; again not in that it provides any more capabilities over C++'s abstraction (as i worded it above), but by being so simple, did more to improve inexperienced developer's OO code than any other OO syntax out there (IMHO). I'm not suprised at all that C# also chose to keep the interface keyword.
Re:J2EE is the C++ of our time (Score:1)
I for one wish Bjarne would add all of these features to C++. It's all doable of course, but it goes against his vision of imposing details on C++ compiler implementors and breaking C compatability.
And one last point - C++'s iostream library has got to go - what a useless, slow, needlessly complicated and unextendable piece of shit that is!
Ironically, C++'s own IO library is the worst example of design that a new C++ programmer could face.
At least C++ projects such as Boost are starting to catch up with Java's standard library functionality, so there is hope.
C++ is the C++ of our time (Score:1, Interesting)
As a side note, Java still does not have generic programming as does C++ which is very useful in scientific modelling. The proposed java generics solution does not work on builtin types without awkward and inefficient runtime boxing.
Re:C++ is the C++ of our time (Score:1)
How do you explain the great success of KDE [kde.org]?
Gee, what language do you think that is written in?
It's good ol' C++ code written in the last few years. And it's only getting better with each new release.
Add to the list: Microsoft Office and Sun's OpenOffice.
Face the fact that there does not exist a general systems language that can rival C++ for low memory footprint and speed (other than C).
Java has its place - but not in the desktop or operating system arena.
Re:J2EE is the C++ of our time (Score:5, Insightful)
Where I will attack J2EE is it's redundancy of input. How many times do you have to tell a computer that there is a public function of this bean that people in the role of admin can call? This is just a tool problem though. There are some nifty tools out there (XDoclet, objectfrontier) that help, but nothing that integrates all knowledge of a bean into one single point of access AND comes with a deploy tool to reconfigure the bean.
Re:J2EE is the C++ of our time (Score:1)
In my observation the popularity of Java is from a combination of PHB's and newbies who bought Sun's hype, and people who hate Microsoft so much that they will back just about anything that looks like it can hurt them.
I see nothing magic about Java as a language. OO-Pascal and Eiffle were not significantly different from Java (if you like that static-typed OO sh*t) when Java was being concieved. Many people want procedural-friendly constructs in Java anyhow. Some of us don't like OO and don't buy into its software engineering claims. Even many OO fans agree that one-paradigm-does-not-fit-all situations and apps.
Java is a marketing triumph, NOT a technical one. There is nothing original in it.
Re:J2EE is the C++ of our time (Score:1)
Then your observations are extremely limited, considering for example that Java is widely used across universities to teach people to program. And people tend to stick with what they know.
Re:J2EE is the C++ of our time (Score:1)
Okay, but why did the Universities pick Java in the *first place*?
Note that Pascal was widely used in schools, but still never really caught on.
Re:J2EE is the C++ of our time (Score:3, Interesting)
Because by and large the world had moved from procedural programming to object oriented programming and Java was the 'cleanest' mainstream OOP language at the time therefore matching two critical requirements:
a) easy to teach good OO progamming practices with
b) relevance in the job market therefore motivating the students
Those would be my guesses. a) is not driven by marketing where as b) is
No one denies there was a huge marketing effort to get Java accepted in the mainstream but that does not mean the language itself is bad.
Re:J2EE is the C++ of our time (Score:1)
In name only. Actual production code still tends to be procedural in nature, dispite all the doctrinaire nagging from the evidence-free zealOOts. (I know, I'm being flamey.)
easy to teach good OO progamming practices with
Smalltalk? Python? OO-Pascal?
relevance in the job market therefore motivating the students
This sounds like it was chosen to match the market, yet you said that schools were one of the reason for market acceptence. Is the egg laying a chicken?
No one denies there was a huge marketing effort to get Java accepted in the mainstream but that does not mean the language itself is bad.
Doesn't mean it is good either. If a bunch of experts looked at it and rated it, they would have given it a C.
Then again, languages are probably subjective. There are no agreed-upon metrics for measuring.
Re:J2EE is the C++ of our time (Score:1)
Which is a good reason to start teaching people how to solve problems using the OO paradigm, using a OOP language, such as Java.
Smalltalk? Python? OO-Pascal?
None of which are mainstream OOP languages. That's the leg up Java had.
yet you said that schools were one of the reason for market acceptence
I said no such thing. It plays a part to the popularity Java enjoys today.
If a bunch of experts looked at it and rated it, they would have given it a C.
Who would those experts be then?
Re:J2EE is the C++ of our time (Score:1)
Appearently animals and shapes examples are not good enough. Time to try torture?
None of which are mainstream OOP languages. That's the leg up Java had.
You are missing my point. You still have a chegg problem. I give up explaining.
Re:J2EE is the C++ of our time (Score:1)
Re:J2EE is the C++ of our time (Score:1)
Also, when I think "gorgeous" I think of Gwen Stefani in that new video where she's jumping up and down on the bed. Java never springs to mind. But if I *were* to code Gwen, she'd be "private", "friend"
J2EE not nearly as difficult as you describe (Score:1, Funny)
huh? (Score:1)
Don't get me wrong, I love and appreciate what ASF has been doing, I just question how one can derride the specification while praising the implementation?!
The Jakarta code is clean. (Score:2, Interesting)
Use a database (Score:3, Insightful)
Some people still prefer the code-centric approach for some reason, and that is fine. But keep relational technology and tables in mind when doing complex projects. Try to communicate between processes via relational tables instead of language-specific constructions and see how it turns out. It takes a little while getting used to and to get skilled at sometimes, but worth it IMO.
Java represents the pennicle of the code-centric approach to managing complexity, and I think the pendulum will start to swing the other way soon (no pun intended).
(oop.ismad.com)
Re:Use a database (Score:2)
This is only partially true, and the "partially" derives from the scale the application is being built on. It's very possible to realize development time savings by whacking your mp3 playlist information into mysql rather than parsing out data yourself - but that won't work quite as well when you're indexing 30,000,000 mp3s.
Using a database will make WRITING your application easier - but the job is not done when QA gives it the green light. That application has to be maintained, either by you, or by the customer (and since we're talking about J2EE server applications, we'll presume its by you).
Databases are expensive, not just in the cost of the software/hardware, but in the cost to manage them. The whole model of tightly coupling data together in one place is what allows you to realize development savings ("Rather than write an efficient Java function to find every person who lives in the specified state in the same zip code, I'm going to let the database figure it out with two lines of SQL!!") - coupling, though, also forces you to have big databases - you won't get any benefit if your data is spread across farms of different servers. When I'm referring to databases, btw, I mean OLTP-style databases, as it is very rarely acceptable for web applications to have data warehouse-equivalent delays in data retrieval.
As your database increases in size and complexity, the cost to operate it increases EXPONENTIALLY. So, while dedicating a 2-processor linux box to database traffic is highly cost effective (say $2000), the cost of dedicating a 10-processor, 64-bit Sun box to database traffic is not (market price $100k-200k depending on new vs. reman, discount structure, etc.). Likewise, software and storage costs grow in a similar fashion - two 36GB scsi disks will cost you a few hundred dollars, while a 3.6TB enterprise storage array will cost you in the hundreds of thousands of dollars. Management costs as well begin to come into play - it takes a very different skill set to run a 2GB database from a 2TB database.
If you expect your application to grow exponentially, relying on a database will make your costs grow exponentially as well.
The right way is to only put long-term, persistent data in your database. Nothing transient should ever hit your database, ever. Even old and unused persistent data should be periodically dumped out to tape or to a data warehouse and purged from your production database. Scale horizontally, not vertically. Put yourself in a situation where when your site gets slow, you need to buy another 5 linux web/application servers, not forklift upgrade your 4-processor database to an 8-processor database.
This fundamental flaw in the all-in-the-database system is why companies like Oracle have invested millions of dollars in allowing their software to scale horizontally - in effect, to get the best of both worlds. But, you still have the management problems associated with large centralized storage, backups, plus licensing costs, etc.
None of this is to say that centralizing business intelligence in a database is always a bad idea. But I have worked in situations where people put intelligence in the database with the best intentions, only to discover themselves victims of their own success. Look at google for possibly the ultimate example of de-centralization. They do nothing BUT scale horizontally, and while that isn't necessarily the answer either, it shows it can be done.
Here's what you have to ask yourself as you write any serious, enterprise-grade application:
1) As my data grows, does my revenue grow exponentially (or even linearly) with it?
2) How long does this data need to persist?
3) How can I group my data in such a way that groups can be completely uncoupled from each other within the database as my environment grows?
4) How can I accomplish my purpose without touching the database?
Of those, 1) is the longest term - very rarely does revenue grow at the same pace as data, so the cost of data storage has to be kept down. 2) and 3) is pure practicality - never store anything that you don't plan to eventually delete, and 4) is getting yourself into the mindset that the OLTP database is the location of last resort for data.
Phew. I've been wanting to get that off my chest for a while.
Thanks,
Matt
Re:Use a database (Score:1)
Until I saw your domain name
Re:Use a database (Score:1)
Thanks,
Matt