LAMP Grid Application Server, No More J2EE

An anonymous reader writes "Check out this blog entry in Loosely Coupled about ActiveGrid's new open source Grid Application Server based on the LAMP (Linux, Apache, MySQL, PHP/Python/Perl) stack. Not to start another PHP vs. Java flame war, but it looks like LAMP is starting to grow up, and that it is much better suited for next generation applications than J2EE."

Comments

In which world?

[Anonymous Coward]

Not to start another PHP vs. Java flame war, but it looks like LAMP is starting to grow up, and that it is much better suited for next generation applications than J2EE.

What the hell do you base that peice of tripe on? Why lets compare an incomplete system cobled together on top of PHP to a mature Java based solution which is currently being used in hundreds of thousands of enterprise sites daily throughout the world. Yeah, I can see how LAMP just kicks J2EE's ass on that one.

Seriously, overhype much?

Re:In which world?

[Anonymous Coward]

Begun this flame war has.

Re:In which world?

[Eric Giguere]

People often equate J2EE with web applications and so do the J2EE-vs-LAMP comparison without the right information. J2EE is more than just web applications. You can build non-web clients that use the J2EE component model (they can even be built in other languages and use CORBA mappings). J2EE provides connections to legacy systems. J2EE supports asynchronous messaging. You can do pretty much everything transactionally with J2EE as well, so that if something fails along the way you can rollback your changes.

Actually, comparing J2EE to LAMP is wrong in another way. A J2EE server can run on Linux. An Apache web server is often used as a front end to a J2EE server (especially when you integrate the app server within an already-existing web server infrastructure). You could use MySQL (though I think you'd better off using ASA, but I'm biased) as long as you make sure to use transactional tables. There goes the "LAM" part of "LAMP".

So really, you're comparing the Java-based J2EE framework against similar Perl/PHP/Python frameworks. At least, that's what you should be comparing. Maybe for pure web apps the latter are better. I don't know, but you have to compare oranges to oranges.

Eric
JavaScript is not Java

Re:In which world?

[Gr8Apes]

try maintaining a large commercial website in something non-structured such as Perl/PHP. Yick! (Been there, have the T-shirt and a really bad taste...)

Don't get me wrong, Perl and PHP have their uses, but running large commercial websites is not their strong suite, at least not with the additional maintenance requirements on ours.

Re:In which world?

[Lodragandraoidh]

Zope kicks both of their [censored] IMHO.

Zope has:
Built-in object database (hence Z Object Publishing Environment - ZOPE).
Built-in http server (Medusa), and ftp server.
Ability to integrate with other http servers (i.e. Apache).
Built-in scripting/application language (Python - and you can add Perl if desired)
Built-in ability to connect to traditional relational databases, if needed.
WEBDAV compliant.
Built-in support for XML, HTML, DTML, TAL, TALES, METAL, and CSS.
Ability to extend the environment by building modules that become integral to the site.
Web client based development and administration - with access control built-in and fully configurable to your needs. If you can reach it from the network, you can develop and administer it.
A large stable of free/open source modules that can be loaded (Plone - a full function CRM solution, Zwiki - wikiwiki web clone, just to name a few).
Built-in ability to cluster a site across multiple machines (can be architected to serve behind an SLB for scalability, or in seperate geographical locations to provide local access to shared resources).

This is the fastest development environment I have seen - bar none. The biggest benefit comes from the object database - you don't have to think about a logical or physical data model beyond the needs of your application - you don't have to worry about how structures are defined in the database. You can move your data structures inside of your scripts directly into the object database as-is without having to monkey with table structures and all of the other baggage a relational database carries with it. Once you understand and use the object database, you never want to go back. Of course, you can attach to SQL databases, and do the silly walk if needed.

I set up a CRM solution using Plone that has been up and working for 6 months now with minimal time babysitting it. Adjunct to that, I have built several unique apps far quicker than our IT department could possibly accomplish using J2EE (we have several projects through that group that are years overdue and over budget - hence my move to Zope for internal development of critical support functions that can not wait).

Among the principles behind the Agile Manifesto are several that are instructive:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."

Zope has helped me be successful with all of the above. How do your tools measure up?

Re:In which world?

[Anonymous Coward]

You said: Not to sound trollish because php and mysql are great for tiny websites and hobbiests...

Umm, your not very good with php are you? Like any product you need to use it correctly, with the right set of tools to get it to work properly. Most people install php and dont do any optimizing whatsoever, and when their code runs slow blame php. First off, you need to compile php yourself, with only the options you need. Secondly, if you want to run enterprise PHP apps, you need Zend's tools. What, never heard of Zend? Oh, thats the engine php runs on. You see, there are a number of products that one should use with php to deploy enterprise applications: Zend optimizer, encoder and accelerator.
Whats that you say? "Oh, those cost money! PHP is supposed to be free!". Well, yes, IF your a hobbiest, but if one plans to use PHP commercially, these are a must have.

Don't complain about a tool untill you've spent the time to master it.

Re:In which world?

[RetroGeek]

Java certainly isn't giving you a speed boost over PHP or Perl

Oh yes it does, for a very basic reason.

Java is already compiled, it just needs to be linked.

PHP/Perl has to be compiled (interpreted), then linked. For each page hit.

For trivial pages, this is not such a big difference, but add in I18N support, inter-page communication support, session support, etc, and the time it takes to load up the "environment" in PHP/Perl completely swamps the time it takes to render a page.

I code in both (and some ASP). For a q&d web site, PHP every time. For an enterprise level app with hundreds of pages, thousands of classes, J2EE is THE choice.

Also, J2EE gives you a running application, whereas PHP is started for each page hit. With a running app, you can keep all sorts of information in memory, you can trigger events based on time, you can spawn threads, etc. You can set up database connection pooling, which means that there are constant active connections to the database, which REALLY speeds up back end access.

Each has its own place. I use both.

We can also go into the fact that Java is not free, but I'll leave you to analyze that on your own.

d/l J2EE JDK (free)
d/l Apache/Tomcat (free)
d/l Eclipse IDE (free)
d/l MySQL (free)

Ok, I did my analysis, and my conclusion is that is it free.

Re:In which world?

[golgotha007]

I am lead developer (well, the only developer) for a major website (+half million page views per day).

When the owners of the website first came to me, they basically had a team of developers who worked around the clock to maintain the old website which was running JSP and Oracle on a total of 5 servers (I don't know the proc, mem, etc).

The website ran like a damn pig and the owners were tired of all the problems.

Basically, they came to me and asked me if I could re-create the entire website using FOSS and on two servers or less, while speeding the whole thing up. I'll be honest with you, I agreed to the job, but I was a little worried. Would LAMP live up to the hype?

I settled on MySQL 4.1.3, PHP 4.3.8 and Apache 2.0.50. First, the owner wanted to see what one system (single 2.4GHz, 2 gigs RAM) was capable of before putting the second one online (which was only an additional web server). A few months later, the site was finished. I was sweating bullets when we switched the DNS record and the requests started to pour in!

We've never had to turn the second webserver on. A single processor server (apache + PHP + mysql) handles the entire website, while the load average never climbs over 0.20.
Every page is dynamically generated with several DB hits per page and we're talking about more than half a million page views per day (over 2 million hits per day, over 500GB per month), while the server sits not even breaking a sweat.

Now, what can we conclude from this?
First of all, JSP with Oracle isn't remotely capable of this project with the resources given.

However, I do know from first hand experience that a LAMP design works well for large operations.

Re:In which world?

[smcdow]

... and use CORBA mappings ...

Some people, when confronted with a problem, say, "Let's use CORBA."

Now they have two problems.

Re:In which world?

[mobiGeek]

Now, what can we conclude from this?

The only thing you can conclude is that your replaced a bunch of bozos. There is absolutely nothing else you can conclude.

Give me your PHP/MySQL solution and I bet I can bring it to its knees with a few properly placed bad queries and/or data structures.

To make any conclusions about technologies based on your one example would be a crime (...though, this is /. after all...)

Re:In which world?

[golgotha007]

You're right, we (as a group) can't make any solid conclusions from this data. One of the major problems is that I never saw the old code or know anything about the websites previous deisgn.

However, from my experience, in the future I will always recommend the setup I've already explained because I know it works well.

Give me your PHP/MySQL solution and I bet I can bring it to its knees with a few properly placed bad queries and/or data structures.

Of course, bad code will bring anything to its knees, no point there. That's the nice thing about advanced database methods; using stored procedures, transactions and the like can help maintain data integrity even if you've got a couple of bad developers in house, although it can act against you when considering performance.

To make any conclusions about technologies based on your one example would be a crime...

I could site other examples from co-workers or friends, but this is one example that has affected me personally. Do you have any examples of replacing FOSS with JSP and Oracle using weaker hardware and seeing an increase in performance?

Re:In which world?

[killjoe]

What ZOPE doesn't have.

Ability to publish zope objects with SOAP
CORBA support.
Message queues
Object relational layer
transaction support for relational databases
RMI or it's equavalent in python
Common logging infrastructure (log4j)
Timed services (cron like device for calling certain code)
Naming directory. .... Many Many more thing that are in J2EE but not in zope.

But what it lacks more then anything else is good documentation. Yes there are lots of products but the vast majority of them have no more then a one sentence explation.

FInally a plea to whoever is reading this.

I hate Java, please please please build a J2EE like container for python or ruby make sure it has everything I have listed above.

Re:In which world?

[j3110]

I think people are seriously misunderstanding the purposes of each peice of software... So I'll give it my best shot to clear it up.

1) PHP
For web scripting.
Do something small and fast.
Will run fast.
Won't scale for the strictest rules of scaling.

2) J2EE
For everything big, not just web sites.
Do something large and right, which takes more front time, but much less time to keep up. A good way to program yourself out of a job, easily. (Can be done with PHP, but not really stressed so much.)
Will run fast, but can consume a lot of resources in the process. If it's running slow, just give it more memory, and learn -Xmx settings.
Will scale in all senses of the word.

Now... a little on the scalability...
1) Load balancers are only 1 section of a huge problem, and you can load balance anything, including LAMP.
2) Transaction support is new to the M in lamp, and no one uses them in the P part. J2EE has a transaction system (JTA) that will combine all your data access into one big happy transaction, on all your resources that support JTA (includes JDBC).
3) Session state replication is completely absent from LAMP. A server could catch fire in a good J2EE configuration, and when the user clicks submit, they wouldn't even know, because at least two servers will have the users session id.

Ok... now about why it takes less upkeep in J2EE land...
1) Specs require backwards compatibility in all new versions. I've had problems with every section of LAMP on this issue, but never on J2EE.
2) A JSP page is only supposed to display information and forms. There is no logic in it. If you have problems with this, I recommend STRUTS. Some people recommend WebWork or Spring. It's a matter of taste, but STRUTS is still the top dog. In PHP, you have to work hard to not mix the two. I used to do action= in the get to simulate this behavior, but it's still not as good, just workable.
3) If you want a rich application accessing your data, you can do it through the same CORBA, SOAP, or XMLRPC calls. The newest spec from J2EE allows you to turn a normal function on a Session Bean (EJB) into a web service that can be called from anything, including JavaScript on Mozilla or a Flash animation (I have done this). Since it's calling the exact same method, if the database changes, you only have to update the code in the least number of places possible.

Features completely abscent from LAMP:
Good web-service support (you can fake it, but Zope actually does XML RPC for you)
JTA (Transaction system)
JMS (Messaging System for asynchronous processing)

Things commonly thought to be missing from Java, but aren't:
Easy scripting of SQL (The Java Standard Taglib is far easier to use than anything I used in PHP or Perl, but Zope probably has everyone beat there)
Speed (the bottleneck in 99% of all software is disk related... If you know how to make a database properly, it will be fast.)

Genuine concerns with Java:
Memory consumption.
Threading on your particular platform.
Lagged support for the newest features on all platforms.
Doesn't automatically pool database connections.
Can be hard to configure properly.
Requires more knowledge than it lets on.

Re:In which world?

[tanguyr]

try maintaining a large commercial website in something non-structured such as Perl/PHP. Yick! (Been there, have the T-shirt and a really bad taste...)

Oh come on! Some of the most heavily trafficed sites in the world - commerical and otherwise - are built on perl/php and seem to do just fine. Why do these discussions ALWAYS degenerate into "technology Y is better than technology X"? The fact of the matter is that, within a pretty broad spectrum of reason, what technology you use is not the deciding factor of how successful and maintainable your app is going to be. The day someone does come out with a miracle technology that REALLY improves a project's chances of success, we'll all know about it pretty darn quick because everybody will flock to it overnight - and i mean actual people, not magazine articles or Oreilly books. Given that we're all still having "my language can beat up your language" discussions on Slashdot, it's pretty safe to say that we're not at that point yet.

If you had a bad experience with a Perl/PHP based site before, the chances are pretty high that the fault is more with the designers (or lack of) and builders than the languages used. No sweat, this job is a learning experience and the first couple of apps will always be dogfood. A very good book once described mastery (in the development business) as the stage where you don't want to rip up all the code you've done in the last six months and start over.

Re:In which world?

[adamfranco]

You see, there are a number of products that one should use with php to deploy enterprise applications: Zend optimizer, encoder and accelerator.

For a free (at least as in beer) PHP extension to transparently cache the compiled version of you PHP scripts (instead of recompiling every page load), check out
PHP-Accelerator.

Re:In which world?

[Lodragandraoidh]

Killjoe wrote:

What ZOPE doesn't have.

Ability to publish zope objects with SOAP
CORBA support.
Message queues

SOAP and CORBA are data transport protocols. What would stop you from writing a product in python to handle these formats? Message queues are a physical implementation of those protocols. Again, you can implement your own queues in python (or any other language for that matter) This can be handled external to the Zope framework and passed into Zope via external methods.

Object relational layer

I'm not sure what you are referring to here. You can index and associate all sorts of meta-data with your zope objects - thereby relating the objects - is that what you were referring to? Additionally, Zope has a unique ability to acquire and use objects and permissions from folders above the current locale - so you could write a general purpose form that displays the contents of a directory for example, and apply it to multiple folders below without having to rewrite code.

transaction support for relational databases

Zope's ZODB (object database) does support transactions/rollback. Zope also has relational database plugins that allow you to communicate with all sorts of databases (oracle, sybase, mysql etc) - so if the database supports transactions - Zope should be able to make the database perform that function.

RMI or it's equavalent in python

You can write an external method to handle this, if needed, using jython. However, why bother with RMI when you can use sockets or python's Expect module? The benefit of these is not having to load anything special on the other end (I assume you would need Java on both ends of the RMI transaction).

Common logging infrastructure (log4j)

You could write an external method in python to write logs to a standard file - and call it from your applications.

Timed services (cron like device for calling certain code)

How about cron itself on a *nix system (you don't have to run ZOPE from Windoze - and I wouldn't recommend it anyway)? You can use cron to do certain administrative tasks for the overall system (such as packing the database). You could also write infrastructure pieces using python (or any other language for that matter) and have those modules run in cron (for example, an app to rotate your logs in the previous example).

Naming directory. .... Many Many more thing that are in J2EE but not in zope.

There is a python-ldap package available via sourceforge.net - you can use this and an X.500 (LDAP) directory to manage your names. You would use an external method (python) to manage input/querying the directory.

But what it lacks more then anything else is good documentation. Yes there are lots of products but the vast majority of them have no more then a one sentence explation.

I will agree that the documentation for Zope 2.X is not optimal (but there is certainly a lot of it - the Zopebook 2.6 version is 495 pages long). I am hoping the Zope X3 will have better documentation (several books on the subject can be preordered for a December or January delivery). X3 will serve as a testbed for new development paradigms, as well as bringing development tools in-line with some of the issues developers have complained about.

The important aspect that you are missing is you can extend Zope via products and external python/other applications to get most, if not all of the functionality you mention here. If you really want to dig into the code, you can even modify the framework itself - since it is open source. Can you modify other frameworks in a similar fashion, or are you limited to what the vendor has p

"Not to start another flamewar BUT..."

[rleyton]

...LAMP is much better suited for next generation applications than J2EE?

Not provocative at all that. No. Not in the slightest.

I'm sure the flamewar that no doubt follows is merely a figment of our collective imaginations.

Re:"Not to start another flamewar BUT..."

[timbloid]

It's the Slashdot equivalent of saying "No offense" after doubting someone's parentage to their face ;)

Re:"Not to start another flamewar BUT..."

[Alpha27]

Ha, you naive little underlying...

I use carrier pigeons to transmit the hole punch data to chicken routes, that spits out egg packets to your computers.

Next week, we are migrating to ant communication through the use of their scent glands for communication. Open Source all the way... just grab an ant and hack the chemistry and the biology.

Re:"Not to start another flamewar BUT..."

[GreyWolf3000]

That's nothing. I have a team of 11,000 midgets, with a dedicated sub-grouping of 26 midgets leading 13 categories, all shouting ones and zeroes in seemingly random succession, either to the group itself or to a "router" group.

Oh, and they snarl.

Re:"Not to start another flamewar BUT..."

[Bill, Shooter of Bul]

Not to start another flamewar BUT...

Here is a box of matches and a gallon of gasoline. Lets see who can light a mathc quickest after being drenched in gasoline.

What the?

[Prophetic_Truth]

Not to start another PHP vs. Java flame war, but it looks like LAMP is starting to grow up, and that it is much better suited for next generation applications than J2EE."

Thats like me saying, "Not to offend you, but check out goatse.cx!"

ITS JUST NOT POSSIBLE TO HAVE IT BOTH WAYS!

Re:What the?

[IO ERROR]

Not to offend you, but check out mysql.com!

LAMP is great for what it does, but MySQL has no place in the enterprise. There's way too much important stuff that it lacks. I'm sure the nice folks who run /. can tell you of their many misadventures with MySQL, if they chose to...

Now if you'll excuse me, I have to go find my asbestos suit.

Re:What the?

[GreyWolf3000]

MySQL recently has gained clustering support. Not that I'm contending that this is all that's necessary to be "enterprise ready" but it certainly is progress.

Re:What the?

[mr_angry]

I don't especially love microsoft products but for what we do at work, MySQL wouldn't be a possible replacement. Microsoft's Sql server doesn't seem to require that much attention here, maybe more than other products but it doesn't seem so bad. And the feature set is very good. MySQL has no triggers, this is something i can't live without. I don't think it has the same level of support for stored procedures and user defined functions and i don't know if it supports authentication thru something like LDAP.

m$ also provides neat tools like a db management tool with a gui and a query tool as well. The management gui seems to be pretty good for the times i've used it.

Microsoft's SQL Server isn't the best database on earth but i really think the SQL server product is quite decent. Please explain why you'd need much more DBAs for the ms product vs mysql ?

Re:What the?

[Khazunga]

Then, they're only missing these

Re:What the?

[drew]

While Oracle does seem to be the most powerful database out there, I see no reason for it to be near as complicated as it is. My theory is that Oracle is trying to mainting the artificically high salaries of Oracle DBA's. (Don't get me wrong, a decent Oracle DBA earns every penny he's paid, but why should they even be necessary?)

Re:What the?

[Bob Uhl]

What I don't understand is the love for MySQL when there is a better alternative available which is just as free and just as easy to use. PostgreSQL is a joy to use, and it actually does what one would expect with regards to referential integrity &c.

Re:mirrordot not quick enough

[Alioth]

Slashdot tends to put spurious spaces in long URLs making them useless. Please enclose them with the URL tag (note under the Comment text box, it tells you how to do this - just

Example:
http://66.102.9.104/search?q=cache:AXRoWhcH5UIJ:ww w.looselycoupled.com/blog/lc00aa00074.html+lc00aa0 0074.html&hl=en

Let me get this straight

[Anonymous Coward]

So you are basically saying: Throw more hardware at an inherently slow platform (LAMP) than to use highly optimized J2EE-servers with s state-of-the-art hotspot compiler?

New /. business model?

[dr_d_19]

Seriously, is the flame war the new source if income? I mean, it sure increases the number of banner views. Let's report on a new emacs-version, citing it as "far less potent than the newer VI. also notepad K1CK$ aSS".

Where to go ?

[KingRamsis]

Slashdotters help me with this; on the right I have an over-engineered J2EE with a dozen of work arounds that are over hyped like EJB facades and dozens of frameworks that are difficult to learn and slow (..and kinky, every one and their mom developed a framework), and there are no free (as in beer) quality servers (I know JBoss but good luck without the documentation), on the extreme left I have LAMP, a loosely coupled system, PHP is popular but lets admit it is an ugly hack just looking at PHP5 reconfirms my believe that PHP didn't handle it fast growth properly, in the middle there is Microsoft which I hate and don't want to consider., I want a decent middle ware, that is cross platform, fast, and well documented, free as in beer (and preferably as in speech also).

Re:Where to go ?

[Enygma42]

Java is well suited for middle-ware too. You don't have to install a big heavy duty J2EE server and enterprise level DB server. Tomcat & MySQL does the job just fine for smaller operations.
Take a look at O'Reillys "Better, Faster, Lighter Java"
http://www.oreilly.com/catalog/bfljava/

IMHO Java scales very well, from small prototype projects right up to enterprise level apps. PHP is fine for the smaller stuff but I'd rather poke my eyes out with a white hot needle than develop and enterprise app with it.

Re:Where to go ?

[LarsWestergren]

Slashdotters help me with this;

Allright then...

and there are no free (as in beer) quality servers

Apache Tomcat.

(..and kinky, every one and their mom developed a framework)

Doesn't mean you have to use them all.

I want a decent middle ware, that is cross platform, fast, and well documented, free as in beer (and preferably as in speech also).

That's Java.

Re:Where to go ?

[Eric Savage]

Your assessment is unfortunately a common one. Class, repeat after me, J2EE does not mean you have to use EJB. The "dozens of frameworks" is a growing problem, caused by picking bad/inappropriate ones and/or weak architectural management.

In my experience, as a developer and as a web user, a simple non-EJB java webapp running a relatively mature framework (or not), on something like Resin is capable of tremendous performance, but I'll state that as opinion to try and avoid baiting some PHP flametard into posting how many views his anime forum can handle.

If you are developing for something that isn't going on a server you run, with a nice simple Java webapp all of a sudden you (or more often someone else) can choose your OS (Windows, Mac, Linux, Solaris, etc), your DB server (MySQL, PostreSQL, Oracle, etc), AND your web server (Apache, IIS, none, etc). Thats something that MSFT and LAMP-heads don't offer (without compromising their acronym) and something that client IT departments will very much appreciate. A "pure" admin (i.e. one who doesn't consider him/herself a developer), HATES being told by some outside developer to patch their systems, or run something they don't know or don't like.

Re:Where to go ?

[CountBrass]

You do realise that J2EE is not a synonym for EJB don't you? And that xdoclet is one of the worst villains when it comes to meta-data hell?

Do yourself a favour, stick with J2EE, dump that p-o-s EJB and use Hibernate and Spring and you'll do fine: and be amazed how much you can achieve if you don't tie yourself to the EJB dead horse. Seriously: you'll thank me.

Re:Where to go ?

[JavaSavant]

Who needs EJB when there's Hibernate http://www.hibernate.org/ and Spring http://www.springframework.org/. Persistence, Transaction Management, and SQL generation in one tidy package. And it works on any J2EE app server, no matter how lightweight or robust.

Not that I have qualms with any attempt to provide these services in PHP. It's not a matter of having just one tool in your toolbox, but rather knowing which tool is right for which job. My only response to the original poster is "I don't want to start a flamewar, but if you aren't a sound enough engineer to know when to use which tool, you pretty much suck."

Re:Where to go ?

[timbloid]

> be amazed how much you can achieve if you don't tie yourself to the EJB dead horse.

EJBs do have their place. They are good for distibuting your objects across servers when the data processing is so costly that it outweighs the cost of remote invocation.

The problem with EJBs is that everyone tried to use them for everything, and later realised that they were using an expensive (processing wise) hammer to crack a nut.

JMS and MDBs also shouldn't be ignored...they too have their place.

To claim that EJBs are a p-o-s is to ignore the applications where they do work...

Re:Where to go ?

[markroth8]

...there are no free (as in beer) quality servers

Actually, Sun Java System Application Server 8 PE is free as in beer, and it is high-quality with good documentation:

http://java.sun.com/j2ee/1.4/download.html

It is a fully compliant J2EE 1.4 application server that is free for development, production deployment, and redistribution.

Disclaimer: I work for Sun.

Get a fucking grip

[Timesprout]

Some muppet posts a blog and immediately hundreds of millions of dollars investment and countless man hours of work on a mature, strongly adopted platform become irrevelevant. This is pure flamebait.

The only thing this indicates to me is that Grid/LAMP is going to struggle to gain acceptance in the enterprise because it proponents are idiots.

Still no TPC

[dras]

For the majority of enterprise projects I've worked on, we wouldn't event consider a platform that didn't perform Two Phase Commits (MySQL) nor supported distributed transactions. This stuff still has a long way to go before it's to be taken seriously.

Re:Still no TPC

[GreyWolf3000]

Clustering support has recently been added to MySQL.

I haven't RTFA, but...

[Zangief]

Can you use Postgres instead of MySQL in LAMP, without extreme pain?
--
Wiki de Ciencia Ficcion y Fantasia

Re:I haven't RTFA, but...

[dave420]

No, 'cos then you have LAPP.

ba-DING.

Re:I haven't RTFA, but...

[NickeB]

Which is the swedish word for patch... It's a sign I tell you!

Do not equate JAva to J2EE

[Trinition]

Not to start another PHP vs. Java flame war, but it looks like LAMP is starting to grow up, and that it is much better suited for next generation applications than J2EE

(emphasis mine)

Remember, folks, Java is more than just J2EE and J2EE is only a part of Java. There are many enterprise applications written without the cancer that is J2EE. There a great number of alternative frameworks for building enterprise applications.

Personally, I feel that J2EE justifies itself because the bloat of a J2EE server means you have to have multiple instances to support an equivalent load a non-J2EE solution could handle on a single server.

Re:Do not equate JAva to J2EE

[CountBrass]

Personally I think you're wrong. J2EE is great if you need the features it supports: JMS, distributed transactions, database connection pooling, jsp/servlets etc etc.

Now if you'd said "EJB", which is only a part of J2EE: and by far its worst part, then I'd have agreed with you. EJB is the epitome of what happens when something is designed by committee.

Slashdotted.

[edooper]

Hope they don't run this on a LAMP server...

Anyway, here is TFA:

http://66.102.9.104/search?q=cache:AXRoWhcH5UIJ:ww w.looselycoupled.com/blog/lc00aa00074.html+&hl=en& lr=&strip=1

Re:mirrordot not quick enough

[buro9]

The spaces aren't spurious.

They are there to prevent trolls from stretching the width of the page by inserting silly long strings of text that lack breaks.

Slash code adds spaces, and that enables the text to wrap, meaning you don't get an ugly and ill-behaving website.

The point is... Add the tag or make it HTML formatted to make Slash know that it is a URL and to not only hyperlink it, but not to break it either in the hyperlink (but still in the render as we still don't want wide pages).

RTFA

[aled]

"Of course, calling its platform an application server is something of a marketing ploy since, as Peter has explained, an application server is the last thing you need. What ActiveGrid is really providing is a highly tuned "text pump" to occupy the fabric/bus space in a transaction-intensive enterprise data center."

Translation?

[Jacques Chester]

I tried every online translator I could, however the article still comes out as absolute gibberish.

What with the concurrent text pump synergies, next languages, impedance mismatches and grid quantum antipolarity trilithium subspace continuums, I got a bit lost.

Anyone understand what they're peddling?

LAMP may be fine for web-based applications...

[altgrr]

...but doesn't it seem a little silly to base computational applications on what is essentially a glorified webserver? Sure, use LAMP for your shopping cart, but enterprise applications are more than just shopping carts.

"There is no impedance mismatch, everything talks SOAP/HTTP" - well, yes, that's great, but you shouldn't be talking SOAP/HTTP internally. There are faster means of communication, so use them.

"Apparently what is needed is a language/environment that is loosely typed in order to encapsulate XML well and that can efficiently process text" - only on input and output. In intermediary stages, you should be using a much more efficient format. If you're doing something clever, it's going to involve much more than just plain old text.

"J2EE and .NET applications were never designed with grids in mind" - well, I can't speak for .NET, but J2EE is designed for clustering and distribution. Have you seen EJBs? EJBs are designed for interaction across computers.

RTFA and you'll see that LAMP is being pushed for "text-pumping". Why aren't they saying it's any good for anything else? Because it most likely isn't.

Scripting languages suck

[Anonymous Coward]

Can any fan of the Perl, PHP, or Python explain why they are better than java or C# for LARGE applications? Strict type-checking is extremely useful, and I believe essential, for large applications. With strict type-checking and OOPS, the compiler does a lot of the work to ensure that the correct objects are passed to functions and that they are initialized, etc.

But with any scripting language, you have to run the application to catch even trivial bugs like misspelled methods and incorrect argument types.

I'm sure scripting languages have their place, but I've NEVER written a large script, without eventually wishing that I'd originally used a strict language. Scripts are great for fast turnaround, but only if you don't mind chasing trivial bugs that a compiler should have caught. I want a language that's tighter than a straightjacket.

Sigh...

[LarsWestergren]

Ok, I had already spent a modpoint in this topic, but I realized it is better to speak up to defend your position than to stand on the sides and give out points to "your" team.

Article is Slashdotted, so I can't comment on the content, but just to reply to some of the posts that will defenitely come up, because they ALWAYS come up when Java is discussed-

EJB are bloated etc:
J2EE is does NOT equal Enterprise Javabeans. J2EE contains classes for lots of things. XML processing, messages, web servers, database connectivity, etc. You don't have to use EJB. Lots of Java developers don't like EJB because they are too cumbersome, and there are plenty of alternatives. Check out for instance O'Reillys recent book Better, Faster, Lighter Java.

Java is slow:
Startup time for the JVM is still slow yes. This rarely matters for a web/application server. When it comes to running, it is plenty enough.

It isn't open source:
So what. It's close enough.

Ok, that over with, was this darn topic necessary? I like both LAMP and Java. They have their uses, why did the poster and the article have to turn this into a confrontation?

More marketing hype

[standards]

Check out this blog entry in Loosely Coupled about ActiveGrid's new open source Grid Application Server based on the LAMP (Linux, Apache, MySQL, PHP/Python/Perl) stack.

I love marketing hype like this.

One sure sign of marketing hype is to quote a venture capitalist on technology. That's why we all don't own a Segway, despite its claimed "future".

Second of all, a technical paper shouldn't be based around a press release that quotes the same venture capitalist. Not too many technologists will take that seriously.

Next, don't bring the NetDynamics CTO near me. Maybe he's a good guy and all, but in my experience, NetDynamics was one fucked up product. And this was before AND after Sun gobbled them up. It was like the Marketeers and Experimentationalists got into it, forgot that it was supposed to be an enterprise product, and screwed it to hell.

Finally, a combination of Perl, PHP, and Python for a complicated enterprise app isn't going to win any awards - damn, how many specialists does one need?

Finally, I'm not going to be running my payroll on a core of MySQL, PHP, Python, and Perl. And which version of Apache? 1.3 or 2.0? Perl 6? Why isn't ksh in there?

I love people that seamingly have ZERO large, enterprise-class application experience telling those who do how to do it.

Use Lisp

[RAMMS EIN]

Use Lisp. Seriously. It's one of the oldest languages out there, but it has features that other languages can only dream of (in fact, when other languages improve, they almost invariably get closer to Lisp).

The language is well-documented. Implementations range from simple interpreters to complex, optimizing compilers (they are on par with C, and sometimes outperform it). It has packages for many purposes, enough to implement Yahoo! Store at any rate.

People complain about the parentheses (some say LISP is short for Lots of Irritating Superfluous Parentheses). That's a valid point. In C syntax, at least there's variation. Besides parentheses there are curly braces, straight brackets, commas, semicolons, etc. Seriously, the parentheses make for a very simple and consistent syntax.

Lisp allows you to program in whichever paradigm suits you best (pick the right one for the task at hand). Functional, object oriented, imperative, it's all there. It's macro system is so powerful it lets you basically generate programs, rather than writing them. Add garbage collection, higher order functions, dynamic typing (although static typing can be used for performance), arbitrary precision arithmetic (integers are not limited to 32 bits), multiple inheritance, and tail call optimization (recursion in constant space), and you have a language that blows all others out of the water.

Why does nobody use it? Fear, uncertainty and doubt. People think it died with AI. People think its old, so it won't be up to modern tasks. People can't get over the parentheses. The boss won't approve it. Nobody else uses it, so it's hard to get support. Any number of reasons.

Re:Use Lisp

[Anonymous Coward]

Why does nobody use it? Fear, uncertainty and doubt. [...] People can't get over the parentheses. The boss won't approve it. Nobody else uses it, so it's hard to get support.

You know, I think those were all pretty valid reasons. ;-)

Re:Use Lisp

[namekuseijin]

I agree.

Don't know why the hell people modded this funny. It is very serious. But then again, most of the code-monkeys enterprises like to hire for quick hacks for low salaries wouldn't ever be able to use nor understand Lisp.

Of course, VB lusers can laugh at Lisp, since they don't understand it, but some very large companies use Lisp as the base for their systems, like Intercontinental Airlines (using C++ like assembly for critical sections) and Yahoo.

Re:Use Lisp

[hey!]

Lisp needs an application server like Zope. Zope has driven many to learn Python so they can create Zope products.

Re:Use Lisp

[heathm]

Not only has Zope driven people to Python, it has also driven many of us to contemplate suicide... but that is beside the point.

LAMP

[slittle]

Substitute Postgres or whatever to taste, but that just fucks up a perfectly good acronym, so we'll pretend MySQL is a placeholder for $REAL_DATABASE of your choice.

Re:LAMP

[v01d]

You're right: PHP doesn't natively support database abstraction. Every database you want to support has it's own set of functions and must be specifically compiled in. There is a PEAR class that provides an abstraction layer though...

Re:I just got myself some new asbestos underwear

[iBod]

Of course LAMP is better suited for next-generation applications than Java.

Why "of course"?

Am I alone in wondering exactly what a "next-generation application" is anyway?

What qualities or requirements define a "next-generation application", other than it not having been developed yet?

Anyhow, it was my take on the article that the use of 'P' languages was incidental, it was the grid concept and the horizontal scaling. The 'P' languages just happen to be part of a readily available set of tools for implementing this idea.

Flamewar

[pigeon]

"Not to start a flamewar, but you java developpers are a foul smelling, foul tasting bunch!"

Forced into and OO "paradigm"?

[TheConfusedOne]

Ummm, last time I saw that I called it development.

The reason for using an OO language is to get you to work with objects and encapsulation. There's a really good reason to do any large enterprise level application using objects. That is that the app is being designed to last longer than one year. That means that during it's life back-end systems are going to change, customer requirements are going to change, and new requirements are going to be introduced.

If you haven't properly separated out all of the portions of your code then when they come back and say "can you give us these two functions running on PDA's?" you're gonna be SOL.

(I spent a year building a system and they promised to transition one of the back-end systems to a whole new platform by the end of the job. They never succeeded but we developed against the old system and the new so it didn't slow us down one bit. THAT'S why you take the time to do OO work.)

Laughing all the way!

[tod_miller]

I didn't even know there was a PHP and Java flamewar going on! Where do I enlist?

No seriously, it is like comparing apples and oranges. PHP and the wonderous LAMP stack (I have just heard about it, so that is the first stumbling block for its adoption! many companies like to be fast followers) might be able to do what Java does if you look at output, it might even be quick, but that has nothing to do with the costs and development and staffing that real people with real money care about.

Java has a huge demand in industry that is being met with huge interest in terms of capable candidates which is proven by the number of successful and *bearing in mind this isn't a flamewar!* well written open source project out there.

The level of Java competency in the industry is growing enormously as a result, which is a good thing. PHP is also good, and I like PHP, lets not get things mixed up here.

[snip = list of reasons why people choose java, which was boring even me]

Also J2EE is *the* platform for applications running for thousands of users, on machines with 90+ GB of ram, and 24 processors just to handle the data requirements.

Oracle love J2EE. Oracle is a fairly decent enterprise (not just performance, but support and board level confidence) db to say the least.

Now, LAMP might be lovely, but why even pitch it against anything, dear LAMP community, just be, don't try and compare it against anything.

FUD et al.

PS: erm, nerr nerr? u sux0r? pwned? I am loosing my touch at this internet name calling gaff, time to retire.

Ruby on Rails, and Trails

[martinde]

This month's meeting at my local Java user's group there was an impressive demo on Ruby on Rails. The presenter built a blogging application live in front of the group, literally in 10 minutes or so. Prior to this demo I had pretty much written Ruby off "just another alternative to perl or python" but I have to say that Rails looks really impressive, enough so that I'm taking a closer look at Ruby.

One of the guys in our user's group, Chris Nelson, is building a similar framework for Java - called Trails. He also built a blogging application live during the meeting. It took him a bit longer - perhaps 15-20 minutes. It was impressive as well, although I will say that for Trails you need to know a fair amount about Hibernate and Tapestry. Realize that he's been working on this only for a few months and suddenly you see that this work is very impressive too.

Anyone interested in developing web apps might want to check these projects out - very impressive stuff!

Rapid prototyping overrated

[daBass]

You can prototype - or simply develop - most things as quick in Java as in any "P" language; the only exception I can think of being a GUI interface, in that respect Tk kicks Swing's butt. Personaly I don't like the Ps much, I prefer the T - as in Tcl - for scripting. That language kicks any Ps ass when it comes to design, though it can't win on available libraries. (which I never missed yet, all the important ones are there if you know where to look)

Besides, rapid prototyping is overrated for all but impressing your manager or client. If you need to protoype you clearly do not understand the problem at hand and if you do prototype for the above given reason, you manager will make you use the prototype as base for production development. This means you spend the same amount of time as if you'd started properly straight away (and told him/her and their required demos to get lost for a few weeks) but end up with an inferior product because you are contantly hacking around the shortcuts you took to make that rapid prototype.

The two are just very different beasts and there is a clear case when a proper OO language with clear contracts and inheritence is the best tool for the job. Unfortunately, web apps aren't the best example of such a case and that makes this comparison flawed, not the language in question itself!

Whoa there cowboy.. you don't understand.

[sporty]

Linux, Apache, MySQL, PHP/Python/Perl

J2EE is not about the OS, server or database. It's a specification. JBoss (JBass.. heh), Geronimo, Welogic and many others are implementations of it. Some are certified, some are not, like Resin.

You can run it on many os's, including linux. Apache is making one of the J2EE servers. I'm not sure where databases came into all of this, since it's fairly independent. I.e. w/ jboss, there are data mappings for all of these servers, if you decide to use EJB, which is part of the spec, but not a requirement to use. The last thing is the big ol' P.

J2EE is a set of technology specs. Things like XML manipulations (JAXB, JAXM), communication "stuff", like SOAP, JMS and JMX, database abstractions, like EJB using JDO, CMP, BMP.. "web stuff", though you can do your own protocols, with the servlet spec. Last I checked, the closes to a spec I've seen is p5ee, which had an interesting run. You had options of what to use, maybe too many, in p5ee, but that was about it. It would have been nice to see a tight binding between everything.

Anyway.. the LAM in LAMP is irrelivant in this article. I can use Linux, Apache and MySQL with J2EE if I so desired.

GAS LAMP

[suso]

Grid Application Server based on the LAMP

So does that make it a GAS LAMP?

*ta dit boom*

Re:he said quality servers (nt)

[puddpunk]

Tomcat is the reference implementation for Sun's Servlet specifications (the last 3 versions running).

Tomcat is an enterprise level, quality implementation of the servlet specification. We use it at work backending to a postgresql database and the traffic loads (and system loads of complex financial analysis) are high but Tomcat has been able to handle anything we through at it.

So with a bit of clue learning to write xml config files you have a fast, efficient, standard-adhesive and supported servlet container for a price that can't be beat.

FACT: Tomcat is a quality server :P

Erm, back to basics folks... EE and strings?

[tod_miller]

So let's look at the requirements for today's corporate applications ... Given these requirements, Java does not fare very well. Apparently what is needed is a language/environment that is loosely typed in order to encapsulate XML well and that can efficiently process text. It should be very well suited for specifying control flow. And it should be a thin veneer over the operating system.

So we came from string programming roots, we developed OOP and AOP, and now... now we go back to string programming because of xml parsing?

I find this a worrying trend, you have to understand, an application is state, and behaviour.

This is trying to tie an application into a 'thin veneer' over an operating system, which seems a bit worrying for an app that will cost a few million to develop in the right circles.

Be reducing all the benefits of OOP (huge and varied, numerous and wonderful) we seek to define our crowining enterprise applications with an approach from the 70's that would pioneer the use of string processing programming constructs over highly developed and structured powerful programming tools.

The program isn't the code, it isn't the data, it is the design, the behaviour, the organisation, the people understanding it. All of this becomes very alien to us when we go this route.

Humanising code is key to developing the kind of applications this company has now touted.

What is looselycoupled? Anyone read it regularly? is it a valid news source? Is this some free advertising for a fad?

I am almost tempted to read more about the LAMP, but I just have a knowing feeling it will be another 'cure all' product.

Yep, tick tick, oops, missed one, back to step 1.

Re:I just got myself some new asbestos underwear

[Sanity]

Java is comparatively heavy,

Compared to what? Evidence?

forces you into an object-oriented paradigm

You can put your entire applcation in one class and pretend it isn't OO if you want.

has static typing

Oh what a terrible terrible thing!

and doesn't lend itself well for rapid prototyping and development.

Bullshit. It is just as suitable for rapid prototyping as anything else if you know how to use it.

Quite the reverse

[kahei]

He's saying: use a suite of highly-optimized tools (the various LAMP components, most of which are fast and all of which can be replaced with alternatives as necessary) rather than throw more hardware at an inherently slow platform (Java).

It's all pretty much a matter of what you were brought up with. On the other hand, I'm working for a household-name client now that's banned Java across the board because they got sick of the 'buy more chips' solution to performance problems. Acceptable platforms: LAMP and .NET.

MySQL isn't suitable

[Anonymous Coward]

MySQL isn't suitable for 'enterprise' - you'd really need PostgreSQL. I tried for years to use MySQL in that manner before giving up and trying PostgreSQL. Wish I had done so earlier.

Finally!

[Anonymous Coward]

Finally, a break from the Sun tax. Yeah, you know the one -- the one that makes you pour hundreds and hundreds of wasted man-hours into using poorly written programs with little or no documentation. What can you expect from crappy code written by scientists and corporations? I'll happily use code written by hobbyists any day, no matter what News for Nerds declares. Honestly, I know most of you agree with me!

Mason rather than PHP

[grey1]

Forget about clunky PHP, try Mason instead. And use whichever db makes sense for you - for us it's often Oracle but then we've got the DBAs and experience to make use of it (oh and the licences...).

And sometimes Java (even J2EE) makes more sense than working in Perl. Which is why we do that too.

Choose the kit of parts that suits your application needs and the skills of your developers. And think about avoiding lock-in to a closed-source vendor. That has always seemed like a big risk for a project.

Re:Mason rather than PHP

[Prowl]

Agreed.

We started using Mason here and have just not looked back. It has so many useful features built-in for site maintenance, and to top it all it allows me to embed Perl. We put all our application logic in Perl modules, then wrap the site around it using Mason.

In fact I hereby propose a new meaning for LAMP:
Linux
Apache
Mason
Postgres

You're missing the point

[TheConfusedOne]

The "light" part of the application is the user interface. That should always be as light as possible.

The "heavy" part of the application is what does all of the back-end work. Database manipulation, messaging, legacy-system communication and integration, calculations, life cycle management, etc.

The fact is that customers hardly ever know what they want when you start developing. Development is a continuous feedback cycle where you show some, get new requirements, and show some more.

So, maybe you save a week or two of development time using one of the P's instead of good OO design and Java. What happens when they come back a month later and say can you hook in system X to this? What happens when the small system unexpectedly takes off and they need to add in 150+ more concurrent users?

Strong design should not be looked at as an extra expense. Strong design should be looked at as future proofing.

Lisp vs. C

[namekuseijin]

ah, the eternal dynamic/productive/high-level/slow vs static/unproductive/low-level/fast debacle.

Nice to see the Lisp vs C flame still going strong these days... :)

Nice to see too both have many intelectual descendents which are very good on their own.

And finally, nice to see that both sides of the same coin have seen such widespread adoption to this day, proof that more than one way of thinking is a good thing.

Re:Lisp vs. C

[smittyoneeach]

Uhhh, I think LAMP and J2EE are both flavors of OO/procedural. All of the tools involved are based on C, directly or otherwise.
Help me understand where the functional paradigm of Lisp enters either side...

Re:Parent rewritten with some HTML code

[altgrr]

J2EE is overengineered for everything, and darn too complex to learn.

It took me one week as part of a work placement in a summer holiday to learn all about EJBs. Either it can't be that hard, or I'm a genius. ;)

Oh, and I think it's a little contradictory to argue this line, then argue along the lines of just doing some no-brainer form-filling with the application server.

J2EE is about more than just shopping carts, and thus it WILL take longer to learn than a system that's suited to running an online shopping cart.

Java AS suck RAM big time (and CPU too). BEA advises customers to use open-source technology (Apache) to server static content, cuz' it would kill the server.

That's because application servers are not web servers. Sledgehammer and nut spring to mind.

PHP actually is running the internet far more than java has ever been

See above. Java is about running applications that just so happen to have a web front-end. PHP is about hosting websites that just so happen to have some application logic behind them.

J2EE only has it place in big enterprises that are willing to get it becuase the big bucks it costs come with some big name company that offers support.

"the big bucks it costs" - *COUGH*

even in enterprise contexts, the largest part of the majority of apps is pretty stupid form entry and validation

If that's the case, you don't need a big server cluster to manage it...

Just say no to "LAMP"

[huntse]

"LAMP" is marketing-speak and not a platform, and anyone posting to /. should know better. What are they really talking about? Linux (well, you could just as easily use BSD) Apache (well you could use another free webserver or an appserver like Zope) Mysql (well you could use Postgres) Php/Perl/Python (well PHP is just plain awful and there are other alternatives anyway). Firstly, mysql may be fine for small applications, but is pretty rotten as databases go. When I have used it in the past it really begins to suffer from lock starvation as you scale to more and more read and write contention. As free databases go, postgres has been superior in my experience. Really what people mean when they talk about "Lamp" is "open source n-tier architecture" or "open-source middleware with a database".

Re:mirrordot not quick enough

[Shaper_pmp]

Or why not insert tags instead? Ok, so it's not valid in later dialects of (X)HTML, but since when has slashdot's code validated as anything?

Seriously - <WBR> tags either don't render at all, or render as "\n" (if a long string needs to be broken at that point). I've never understood why slashdot uses spaces (which muck up URLs), instead of <WBR>s (which generally don't).

Anyone?

Re:I just got myself some new asbestos underwear

[boodaman]

Java is flawed? How, exactly? You do mean "flawed" as in "broken", right? Or do you mean "flawed" as in "doesn't handle every possible thing that might ever need to be handled, now and forever"?

I do know one thing...the systems my company develops and sells could never be written in a "P" language. We tried perl and PHP and both failed miserably. Java works quite well, however. So from our perspective, Java is not flawed.

Re:J2EE != EJB

[GuyWithLag]

The main advantage of EJB as I see it is declarative security on a per method basis ...

Yes, and when your security needs are more complex than the simplistic EJB model, you have to either use no declarative security (and write your own) or to apply ugly hacks around the deficiencies...

Re:And you should talk about being sound engineer.

[JavaSavant]

Lots of flames here, but through the burning embers I just want to point out that using Hibernate and Spring is not supposed to be an excuse to use XML - it just so happens that XML is the glue that these packages use to do their work. I personally could care less if it were a binary format or a CSV file. Love it or hate it, .net uses a lot of XML metadata as well. Arguably in the Java community, XML probably gets a worse wrap simply because it doesn't have the tools that .net does to obsfucate the XML glue from the developer as they desire. XDoclet and AOP is a step in the right direction. I can definitely empathize with your complaints about XML from a Java background. But I think when looking at Spring, Hibernate, Struts, or any Java tool that uses XML metadata for configuration/persistence of application state - that unless you are looking to do some serious hacking of the package that would require that you denature the glue it uses, blissful ignorance is probably beneficial. The aforementioned packages work as advertised by their development teams - even if they do use XML.

Just tools, use them accordingly

[AwesomeJT]

I use all of the above technologies, depending on the needs and what I am trying to do.

For large scale projects, I use Java. It is great Object oriented language that I can use to the fullest extent. I can get very close to that MVC pattern that is soo useful in large-scale projects. I don't use EJBs -- not needed them yet. I use the JMS, WebServices, JSP/Servlets, etc. We connect to a real database (DB2). J2EE offers a completely different scale with work with. You can do everything from simple web applications to clustered app servers at several levels.

For smaller stuff, I like LAMP fairly well. It is simple and easy to get started, although not great for larger projects (code reuse, management, scaleability). MySQL, again, nice and fast for small stuff. I perfer PostgreSQL because of the power and flexibility. I'm trying to move more towards PostgreSQL especially after recent changes in licensing with MySQL. For these projects in general, I like PHP over Perl for webpages. Perl is still great for admin tools on the console or for confusing the heck out of folks not familiar with your code. PHP is simple and made for website based applications. Again, I'm not going down that path if I know it will grow into a huge project.

The deal is, they are tools. The both have their strengths and weaknesses. Evaluate your needs, and choose the best tool for the job. I use both and love both -- but choose wisely.

Re:Developing distributed apps is very hard with J

[TheLink]

Java is useful if you intend to treat most developers like lego blocks.

Example scenario: you have one main guru programmer who writes the program in Human Language (e.g. English). And you have the other much cheaper developers (in-house or off-shore) who compile that to Java. After that the guru programmer(s) can move on to other stuff whilst the interchangeable and cheap programmers maintain it.

You appear to NEED a fair sized team for lots of Java stuff, which if done in some other language can be done by just one to three people. This can be considered a minus or a plus. Coz in many organizations if you are a Boss of 20 people, you outrank a Boss of 3 people (and probably get paid more too) - which is why MS has its uses ;).

I find Java stuff to have a lot of "make-work" stuff. You need all these layers and layers of stuff because you have all these layers and layers of other stuff. And often these layers and layers of stuff _don't_help_very_much_ - diminishing returns. Sure it is more "organized", but now you have to change 3 different files to make one change, or something like that (e.g. code, data, metadata) .

Whereas the LAMP style stuff is relatively simple - O/S, Webserver, Database, Programming Language. So what if it isn't N-Tier, or have "Enterprise Java Beans" or have built-in caching or some other buzzword, very often you don't need that stuff - you run out of bandwidth, or hit some other limit first. If you keep things simple you can often easily scale the webservers (and appservers) horizontally (keep adding them). So the bottleneck is usually the DB, and there are many known solutions for that.

You probably end up with similar scaling limits with a Java solution anyway (except the Java solution typically has more layers, complexity and work).

The disadvantage of the LAMP stuff is while you only need a very small team (of one sometimes), since after all the guru programmer codes most of it; the problem is if the guru programmer gets bored or wants to do something else, you have a problem - who's there to maintain it? The "lego brick" programmers may not be able to handle the job. So you need to get another guru programmer who costs as much and is just as likely to get bored.

The lego brick Java programmers don't seem to get bored maybe because they get the feeling of satisfaction coz they are definitely doing lots of work and achieving a "lot" - (remember there are lots of layers to glue together- N-tier ;) ). Or they don't care - it's just a job after all - that's what they got the java certification for.

Last but not least of all - it may not even matter at all whether you go LAMP or J2EE.

Coz amongst the most important bunch on the team are the graphic design/art people. It doesn't matter to the client or PHB how cruddy the architecture is - if the software _looks_ great, you are more than 50% done. It doesn't matter if your architecture handles up to 1000 transactions a second on an el-cheapo dell server, and scales very well. If the widgets look ugly you're unlikely to win the project.

After all not many can tell whether a software/system architecture is ugly or not. Whereas very many can agree and tell you immediately that a widget/icon/colour/layout is ugly. And that includes the people in charge of approving stuff.

MySQL no place? It has many places...

[tizzyD]

Just like you don't use Oracle to handle a simple little db holding some responses to a recent questionnaire or for a quick little conference, I would not use MySQL for a big data warehouse or SAP deployment. Silly db admins have gotten it into their head that DBs at all levels should be compared equally. That is simply not true. Use what's appropriate where it's appropriate. Don't use C for a quick data analysis tool (try Excel first), and don't develop full enterprise apps using cobbled together MS-Office solutions.

Re:Free?

[Doctor Memory]

He said free as in beer. JREs for all major platforms are available for the downloading (either from Sun or the OS vendor).

OTOH, if you really want to add features to the JRE, there's no stopping you from extracting a class from rt.jar and replacing it with one you wrote. If you're really clever, you can even get a bytecode editor, change the name of the original class, then writing a new class with the original name that extends the original class, and only adds the new features you want...

Re:Free?

[coyote-san]

I'm struggling to think of any reason why you would want to modify the JRE. That's comparable to hacking the gcc compiler or C library to add a new feature. It might solve a local problem, but will introduce numerous global ones.

JNI is more than adequate if you only need to access external libraries.

Language extensions could be handled by the C/C++ model - write a tool that compiles your "j++" code into standard java and then compile that.

Re:I just got myself some new asbestos underwear

[ph1ll]

Java ... forces you into an object-oriented paradigm, has static typing, and doesn't lend itself well for rapid prototyping and development.

And these are bad things?

• OO is generally considered a good thing.
• type safety is generally considered a good thing
• Rapid prototypes rarely get thrown away. Generally, if management like what they see they say "continue building".

I do agree with you, however, that PERL (the only P language I have experience with) is great for quick applications. But there is no way on G-d's Earth I would use it for enterprise (50 000+ LoC) worthy applications. I'll stick with Java.

But that's just my opinion...

Point me to a fast Zope site

[SuperKendall]

All of those are nice, but when I was looking around at solutions for a kind of document management solution, I found all of the Zope sites I tried were kind of sluggish. If your main goal is to satisfy customers then response time has got to be a factor.

Java has everything you listed, and multiple frameworks to boot - if your J2EE people are so far behind, perhaps they should just be writing servlets, or using Tapestry or Spring or IDE's that help you put together standard J2EE components more quickly.

Plenty of people in the Java worls are doing just fine with Agile development practices, thanks - Zope has no exclusivity there.

In the end for my own project I'm using Nukes on JBoss.

WebObjects Cocoa::Apple should re-release

[tyrione]

Seeing all this about this kicks ass over this rhetoric it is too bad Apple decided to curtail the original WebObjects into Java and not provide WebObjects ObjC and the full-power of EOF and all the extensive frameworks.

Hopefully, they'll release it and rejuvenate their Enteprise presence, but who knows.

Re:Why not use Jython? or Groovy?

[bwt]

True for jython, false for groovy. Read about groovy beans.

Among python, perl, and PHP, only python has superior language syntax to Java, and groovy leapfrogs python. Groovy's syntax is probably second only to ruby in term of OO purity and clarity. Perl's CPAN libraries are the only one competitive with Java's libraries (and java wins narrowly even over perl). When you give groovy syntax to java, you will have an absolutley lethal combination.

Goovy's benefits from complete bytecode equivalence to Java cannot be overstated. Groovy simply reuses the entire java class library set.

One other major innovation is the hierarchical syntax using closures that makes it superior to everything else for processing markup like HTML and XML. Java was strong on XML to begin with, with groovy it becomes dominant.

The only big problem with groovy now is that it isn't quite ready. I expect that in a year it will begin to be a compelling solution, especially when combined with the lightweight, containers and frameworks (things like Spring and Hibernate) that emphasize Aspect Oriented Programming, Inversion of Control, and heavy use of XML configuration.

Re:Why not use Jython? or Groovy?

[killjoe]

I should have been more specific I should have said you can't build EJB beans with groovy. I would love be wrong though.

"Among python, perl, and PHP, only python has superior language syntax to Java"

Here is an example from the apache merlin web site

"ReferenceDescriptor reference =
new ReferenceDescriptor( Widget.class.getName() );
ComponentModel model = (ComponentModel) m_model.getModel( reference );
model.commission();

Widget widget = (Widget) model.resolve();"

Notice how you have to type everything three times. Just reading that makes me angry.

Re:Developing distributed apps is very hard with J

[The AtomicPunk]

Whatever drug you're on, send me some.