Slashdot Mirror

Also, is anyone else distraught by the obsessive use of the acronyms POJO/POJI? While it's understandable that a bunch of open sores asshats enjoy indulging in this fappery, I find it highly upsetting that this 'street lingo' has made its way into a supposedly professional serious spec. Is it so hard to say JavaBean/Interface? What's even funnier is that in every case, the POJO/POJI silliness is never used standalone, but always in paranthesis after 'regular java bean' and 'regular interface' respectively.

> the steady stream of hate mail

Heh, yup, as characterized by this BileBlog entry.

And XMLSpy won the BileBlog best Java book award!

The Bileblog has an alternative view on Maven.

> you mean "only used by a handful of dorks

Heh, on a similar note, the BileBlog's take on GMail invitations is scathing - as usual.

J3EE is moron bait I've been trying to ignore this nonsense, but frankly, it's just so ridiculous and such a nice big fat juicy target that it's hard to pass up.

Do you care about the future of Java? Are you interested in seeing Java continue to be the premier platform for computing in the next several decades?

Then please take the time to sign this new Spin Java petition, which asks Sun Microsytems and Scott McNealy to spin off Java into a separate sister company.

Spin Java Petition

For more info click here. Thank you.

From my weblog:

Could loading all your objects into memory, and keeping them there, possibly work? That's what the folks at www.prevayler.org think. Breakthroughs in memory technology, cheaper RAM, 64-bit computing, better JVMs -- all these instances of technological progress, we are told, ought to finally make it possible to keep all your domain objects in main memory. The advantages are obvious. Systems become simpler. The need for caches is all but eliminated. Performance can be enhanced dramatically as there is no longer need for expensive disk access or network communication with the database. No longer are you limited by the query language of your database; use whatever query mechanism that best suits your needs.
Wonderful! But, does it work in practice?

1. Cheaper RAM. While it is true that RAM has been getting cheaper and cheaper, the same is true of hard disks. A look at the web site of a nearby computer shop reveals that a 512MB RAM unit costs 84 euros; you can buy an 80GB hard disk suffering the same amount of monetary drain. It is not to be expected that this two-orders-of-magnitude difference would disappear anytime soon. Therefore, for large amounts of data, even if you could buy enough RAM, would you really like to?

2. 64-bit computing and JVM support. Extensions like Intel Extended Server Memory Architecture aside, 32-bit computers can address only 4 gigabytes of data. In practice the number for an individual application is less, and for a Java application even more so. Java heaps on x86 platforms were restricted to approximately 1.5GB last I looked. This is not enough for many enterprise applications. It is not nice to be running at 1GB heap utilization, knowing that users are creating new objects all the time, fast...

64-bit architectures get rid of the 4GB barrier thus carrying with them a promise of prevalence nirvana. Right now, though, all 64-bit systems are stratospherically expensive. Have you seen the prices of those Itanium 2 boxes? AMD promises to come to the rescue with x86-64, but the practical utilization of this architecture from Intel's chief rival in Java application is a little off, since there's not even a Java VM for x86-64 yet (though one has been promised to appear in 2004).

3. Simplicity. I'd love getting rid of caches. Caches suck! And don't even get started on all that pesky O/R mapping stuff. Without a query language, though, the distinct possibility exists that the magic box full of promises will turn out to be half-empty. Writing queries in SQL is, well, convenient. If you have to manually construct hashtable-based indexes, then the value proposition of object prevalence diminishes. Fortunately, there are object query languages, though none of them seems to be widely accepted as a standard. However, there should be no obstacle in principle why such standardization couldn't take place.

4. Performance. Queries from a hashtable-based index are fast. For updates the situation is different, as updates will have to be written to the command log; all in-memory indexes, too, will have to be updated. If such indices are not maintained, databases could in case of a huge data set turn out to be faster, even though they often have to access the disk to get to the data. The big performance advantage that I see coming from object prevalence is in the area of very complex, deeply-linked data structures: you can build them and still not worry, given the right combination of hashtables.

Conclusion? If an application deals with lots of data, or if the amount of data grows fast or unpredictably, object prevalence won't be viable until 64-bit architectures establish themselves in the marketplace (which should take a couple more years). Regardless, you can look for subsets of data that could be kept in memory in their entirety. The more often that data is accessed, the more performance benefits will accumulate. For example, in a server-side business application, it might be possible to

I used to be a COBOL programmer for an insurance firm. It wasn't by choice. I started out on a Java web app team and got transfered. I must say that there was a general lack of good technical knowledge about mainframe programming at the company (it didn't help they laided off some of the best guys) which made it even hard to do my job. Developing on the mainframe is much different, I find it more mondane and boring, then working with modern PCs and OO languages.

I am sure some people like it but I hated it and had to leave the company to get away from it since no one would transfer to my position.

--Kurt A web developer's weblog

One way to help structure your PHP application would be to use Fusebox, an open standard that encourages separation of logic from data (from a DB for example) and presentation (HTML).

I have used Fusebox with several Cold Fusion applications and have that it with FuseDoc are a great combination for creating a webapps in a standard fashion. It allows new developers who are familar with the Fusebox structure to pick up on your design quickly and implement their assigned pieces in a more reusable manner. Here is a good tutorial on Fusebox with PHP. This site is another great Fusebox with PHP resource.

A ColdFusion, Java, and PHP developer's weblog might also be helpful. (Disclaimer this is my weblog! :)

And Jikes too.

The Eclipse live compiler is related to Jikes.

Here is another take on that topic:

There were actually a number of bloggers at ApacheCon aside from Michael Radwin - each with their own independent views/opinions (!) of what they saw/heard ;-) They provide a alternative perspective to Mr. Radwin's own blog. Here are a couple of others:
[you may have to skip to the dated entries Nov 19-22 - the conference really started with the first keynote on that Tuesday, there were tutorials only (extra $) on Monday]

Andy Oliver

Ugo Cei

Peter Royal