 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2005Java losing grip on web developers
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-590318 7.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 > 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> ] 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. SAN3141@netscape.net wrote or quoted: > 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.  Signature__________ |im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply. ... > Maybe it will start getting more activity again as the Java language > becomes more ossified and archaic. That'll be next week then ;-) SAN3141@netscape.net 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 [quoted text clipped - 7 lines] > 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, Pear:DB 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 SignatureWe're part of that admittedly-too-small group that is trying to save the human race from itself. With any luck, we'll fail abjectly and the cockroaches will win out. -- Mike Andrews > 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.) Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation Chris Smith sez: >> I suspect if you need metadata and all that, your application >> is too complex for a web frontend anyway. All web does is show [quoted text clipped - 6 lines] > 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 SignatureRelativity, Uncertainty, Incompleteness, Undecidability: choose any four > 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. > > (Not that metadata necessarily implies complicated data access. After > > all, metadata is used by any number of object/relational mapping [quoted text clipped - 6 lines] > 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. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation Chris Smith sez: >> 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. 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/Pear:DB, then you should consider dumping the web front end as well and going n-tier/thi[n|ck] client/corba/buzzword du jour. >> Oh puhlease. It's java web applications that use ready-made O/R >> mapping products require metadata, not the other way around. [quoted text clipped - 3 lines] > > 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 SignatureI'm going to exit now since you don't want me to replace the printcap. If you change your mind later, run -- magicfilter config script >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. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > 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". 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... On Sun, 23 Oct 2005 02:30:12 -0700, SAN3141 wrote: > Java is coming under fire as a tool for building web applications. > [quoted text clipped - 8 lines] > > 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. On Mon, 24 Oct 2005 16:26:42 GMT, Steven Green <steven.green30@verizon.net> wrote, quoted or indirectly quoted someone who said : >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? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >On Mon, 24 Oct 2005 16:26:42 GMT, Steven Green ><steven.green30@verizon.net> wrote, quoted or indirectly quoted [quoted text clipped - 5 lines] >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. Signature"Yo' ideas need to be thinked befo' they are say'd" - Ian Lamb, age 3.5 http://www.cs.queensu.ca/~dalamb/ qucis->cs to reply (it's a long story...) Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.