Java losing grip on web developers

[SAN3141]

Java is coming under fire as a tool for building web applications.

In _Andreessen: PHP succeeding where Java isn't_, Marc Andreesen said
"PHP is such is an easier environment to develop in than Java."

http://news.com.com/Andreessen+PHP+succeeding+where+Java+isnt/2100-1012_3-5903187.html


In _Moving Past Java_, Bruce Tate said "Java will be dead like COBOL,
not dead like Elvis." He suggests Ruby on Rails is a better choice than
PHP as Java's successor.

http://www.webservicessummit.com/Articles/MovingPastJava.htm

 

[Andrew Thompson]

Java is coming under fire ...

Sounds appropriate for c.l.j.advocacy
<http://www.physci.org/codes/javafaq.jsp#cljad>

[ Whereas this is c.l.j.programmer.
<http://www.physci.org/codes/javafaq.jsp#cljp> ]

 

[zero]

(e-mail address removed) wrote in

In _Moving Past Java_, Bruce Tate said "Java will be dead like COBOL,
not dead like Elvis."

ROFL COBOL dead? When 80% of the operational back-end code is still in
COBOL? Many financial institutions continue to use COBOL for new code.

http://www.computerworld.com/hardwaretopics/hardware/story/0,10801,68764,00
..html

Sorry for posting in an OT thread, but it just makes me laugh when people
talk about things they know nothing about.

Perhaps you should look up the term "false authority syncrome".

 

[footybet]

I haven't read the URLs you posted as I don't want to read propaganda
from anyone who thinks they know everything and can predict the future,
whereas I believe we can only anticipate the future...

I am anticipating this...

Java will be twinned with PHP to create some breathtaking programs
I have just designed a game in Java that I need to use a PHP interface
with
so that I can access files on the fly, with mathematical computation
done in PHP
this may be how it goes...

watch out for the game, it will be both entertaining and educational
with positive rewards in an emotional sense...

I downloaded the Java SDK yesterday and found the applet examples did
what I wanted to do in the game graphically, I just need to interpret
the concept of the game into a Java design, but it will be in a Java
applet initially, so that anyone on any system can play...

I may be able to do the whole thing in Java, but I like PHP...
I have only just come to understand Object Oriented Programming with
reading an academic text on C++, and the class is no longer a mystery
to me...

I have programmed in Java, many years ago, but only by editing the
examples of Java in a Nutshell, where I didn't have to understand the
class structure, but just the Procedural statements...

I anticipate OOP as the way forward, but PHP, like Basic, is easier to
learn and lets you handle SQL databases...

 

[SAN3141]

I'd hoped this thread leads into a technical discussion about the
merits of Java, PHP and Ruby. The c.l.j.advocacy newsgroup often has
discussions driven more by zeal and emotion than by fact.

In terms of technical merit, it seems one issue is when a lightweight
technology is appropriate.

- Database connection pooling is important for scalability. It's
available to the Java and Ruby developer, but it's not inherent with
PHP. You need a third-party tool. So the need for connection pooling
might be a tipping point.

- PHP 5 includes PDO, a new data abstraction layer. Is it too
lightweight, compared to JDBC and JDO, to provide scalable
transactions, sufficient types and so on?

PDO lacks anything comparable to the JDBC metadata classes, for
example. Will you need metadata at execution time? Possibly another
tipping point.

 

[Tim Tyler]

I'd hoped this thread leads into a technical discussion about the
merits of Java, PHP and Ruby. The c.l.j.advocacy newsgroup often has
discussions driven more by zeal and emotion than by fact.

Discussions of the relative virtues of competing technologies
often tend to involve a certain degree of zeal - wherever they
are started. It's the nature of the beast.

Advocacy groups exist in part to get that sort of discussion out of
technical groups.

However, I can't say I've seen much zeal in c.l.j.a of late - the
group seems to be on life support.

Maybe it will start getting more activity again as the Java language
becomes more ossified and archaic.

 

[Dimitri Maziuk]

(e-mail address removed) sez:

I'd hoped this thread leads into a technical discussion about the
merits of Java, PHP and Ruby. The c.l.j.advocacy newsgroup often has
discussions driven more by zeal and emotion than by fact.

In terms of technical merit, it seems one issue is when a lightweight
technology is appropriate.

- Database connection pooling is important for scalability. It's
available to the Java and Ruby developer, but it's not inherent with
PHP. You need a third-party tool. So the need for connection pooling
might be a tipping point.

Database connection pooling is only important if opening/tearing
down a connection is more expensive than having to go through
pooling layer. That's not necessarily the case when connecting
to mysql on localhost via native library (which is what most php
apps do, I suspect).

- PHP 5 includes PDO, a new data abstraction layer. Is it too
lightweight, compared to JDBC and JDO, to provide scalable
transactions, sufficient types and so on?

Dunno, PearB seems to be good enough for simple use. Again,
keep in mind that "lightweight" usually means "faster".

PDO lacks anything comparable to the JDBC metadata classes, for
example. Will you need metadata at execution time? Possibly another
tipping point.

I suspect if you need metadata and all that, your application
is too complex for a web frontend anyway. All web does is show
user a document. You're constructing the document server-side
where database schema etc. is well known, so what do you need
metadata for?

Dima

 

[Roedy Green]

The c.l.j.advocacy newsgroup often has
discussions driven more by zeal and emotion than by fact.

Properly speaking the only people qualified to speak comparatively
are competent in all the languages under discussion. As you would
expect, the strongest opinions come from those who know only one.

 

[Andrew McDonagh]

....
Maybe it will start getting more activity again as the Java language
becomes more ossified and archaic.

That'll be next week then ;-)

 

[Chris Smith]

I suspect if you need metadata and all that, your application
is too complex for a web frontend anyway. All web does is show
user a document. You're constructing the document server-side
where database schema etc. is well known, so what do you need
metadata for?

I think this is confusing two things: applications with very complex or
interactive user interfaces can be too complex for a web front end (for
example, PhotoShop). Applications with complicated data access needs
may very well be web applications.

(Not that metadata necessarily implies complicated data access. After
all, metadata is used by any number of object/relational mapping
products, which are considered standard fare for a very large category
of web applications.)

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dimitri Maziuk]

Chris Smith sez:

I think this is confusing two things: applications with very complex or
interactive user interfaces can be too complex for a web front end (for
example, PhotoShop). Applications with complicated data access needs
may very well be web applications.

Yeah, but do you really want to do O/R mapping on the client?
Given that you can use an object-relational backend or write a
business logic tier and have clients talk to it via corba or
soap or a plain socket?

HTML does not display objects. You're sending code (e.g.applet)
to the client to do that -- if you're giving them code, keeping
O/R mapping in the server-side tier will make client code simpler,
smaller, hide business logic from prying eyes, etc.

(Not that metadata necessarily implies complicated data access. After
all, metadata is used by any number of object/relational mapping
products, which are considered standard fare for a very large category
of web applications.)

Oh puhlease. It's java web applications that use ready-made O/R
mapping products require metadata, not the other way around.
Sure you can't do a generic one-size-fits-all O/R mapper without
requiring metadata, the $15 question is if your particular task
actually needs a generic O/R mapper.

Dima

 

[Steven Green]

Java is coming under fire as a tool for building web applications.

In _Andreessen: PHP succeeding where Java isn't_, Marc Andreesen said
"PHP is such is an easier environment to develop in than Java."

http://news.com.com/Andreessen+PHP+succeeding+where+Java+isnt/2100-1012_3-5903187.html


In _Moving Past Java_, Bruce Tate said "Java will be dead like COBOL,
not dead like Elvis." He suggests Ruby on Rails is a better choice than
PHP as Java's successor.

http://www.webservicessummit.com/Articles/MovingPastJava.htm

As before mentioned I am not going to bother reading the attachments.
Waste of gray cells.

Another opinion on COBOL being dead. As a former COBOL developer
it has some strengths and as mentioned before there is some new
development happening on COBOL. I really don't feel like getting into
details, I am only just bored enough to read this group. But for record
processing and batch applications COBOL is a good language to use. Maybe
not for front end applications but on a mainframe who cares ...

Just my 2 cents.

 

[Chris Smith]

Yeah, but do you really want to do O/R mapping on the client?

No, of course not.

The two options being compared were: (a) database access from PHP, and
(b) database access from Java. This assumes an architecture in which
data mapping layer is embedded into the web application, running on a
single server. It's assumed that there are no middleware servers
involved, just because PHP is rarely or never used in those contexts.
When there's a middleware server, PHP has other disadvantages since it
isn't designed for that environment.

HTML does not display objects. You're sending code (e.g.applet)
to the client to do that -- if you're giving them code, keeping
O/R mapping in the server-side tier will make client code simpler,
smaller, hide business logic from prying eyes, etc.

Applets have nothing to do with this. Yes, information about objects is
presented using HTML or an equivalent. A miniscule number of web
applications use applets for presentation, because they are overkill for
most data-oriented applications.

I don't know where you got your scenario from, but so far it isn't at
all relevant to this subthread.

Oh puhlease. It's java web applications that use ready-made O/R
mapping products require metadata, not the other way around.
Sure you can't do a generic one-size-fits-all O/R mapper without
requiring metadata, the $15 question is if your particular task
actually needs a generic O/R mapper.

I'll tell you that I'd rather use Hibernate than reinvent it. The
problem with O/R mapping is that it's easy to get it MOSTLY working, but
it's very difficult to do well. Reinventing O/R mapping when options
like Hibernate already exist is a waste of time for most applications.
In fact, for every project I've ever worked on, either an established
O/R mapper is a better choice, or the task isn't well suited to O/R
mapping at all. I've never seen good come from trying to reinvent the
technology in a project-private code base. I have, though, seen a lot
of pain come from doing so.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dimitri Maziuk]

Chris Smith sez:

No, of course not.

The two options being compared were: (a) database access from PHP, and
(b) database access from Java.

Are you sure? -- My reading of OP is that it was comparing web
development with PHP and Java, and mentioned connection pooling
and DB metadata as examples of functionality not readily available
to a PHP developer.

....This assumes an architecture in which

data mapping layer is embedded into the web application, running on a
single server. It's assumed that there are no middleware servers
involved, just because PHP is rarely or never used in those contexts.

Well, duh. If we assume a Java application built on top of Hibernate,
then of course there's very little use for PHP in our context.

My argument was that web frontends are limited and PHP works very
well within those limitations. And if you want something less limited
than PHP/PearB, then you should consider dumping the web front end
as well and going n-tier/thi[n|ck] client/corba/buzzword du jour.

I'll tell you that I'd rather use Hibernate than reinvent it.

Yeah, mee too -- iff and when I need it. So far I haven't as my
data tends to map directly to relational schemas.

Dima

 

[Roedy Green]

As before mentioned I am not going to bother reading the attachments.
Waste of gray cells.

I always wonder at comments like that. If you don't read something,
how can you have an opinion on it?

 

[David Alex Lamb]

I always wonder at comments like that. If you don't read something,
how can you have an opinion on it?

Unfortunately opinions need not be based on facts. Just informed opinions.
But I bet you knew that.