Slashdot Mirror
Scriptiing The Enterprise With Java And PHP
jontr writes "There are many benefits of using PHP together with Java. In an article about JSR 223, Dejan Bosanac looks at origin of each language and describes future benefits for PHP and Java developers."
OK, that was not what i was expecting.
I was sort of expecting auto-generated scripts for star trek...it's time to go to bed.
If Mr. Edison had thought smarter he wouldn't sweat as much. --Nikola Tesla
If you want to do some quick and dirty job, use PHP. For larger projects, JSP and J2EE make more sense. I don't see any valid reason to mix PHP and Java together at all.
What makes PHP great is an impressive set of embedded libraries, easy integration in an already existing plain HTML document and POST, GET, cookie, session management.
Look at this beast: *SQL*, FTP, zip, flash, XML, gettext, image manipulation, LDAP, UNIX process control... all rolled-into-one language. Wow. Perl is, in that respect, with the right CPAN modules, as nice as PHP, but dare I say... easily obfuscated?
PHP had (still has in 5.0?) enormous deficiencies and bugs in its OO model. Works great for quick pages, but as the article says, does not scale well.
So, why insist on keeping PHP for large-scale sites instead of plain java? to use PHP's libraries, HTML integration and web-oriented features, that's it. An artist can draw a page in his favorite application, export to HTML, the coder only has to fill the blanks.
The language in itself has no advantages. If java had all these libraries and "native" web access, why would we consider "merging" these two languages?
Think of it, two interpreted languages joining forces to drain down CPU and memory...
(just my two cents)
With regards to caching, server farms, execution speed etc. PHP does indeed "scale" quite reasonably within its limitations.
However, if you are ever involved in building an enterprise level application using PHP alone you will become intimately familiar with its limitations, particularly it's semi-OO implementation (ie. no provision for protected members or private variables).
Compared with the equivalent Java based business logic, the PHP code is a nightmare to maintain. This isn't helped by it's restrictive OO model...
Q.
Insert Signature Here
The rule #1 of scalability is to avoid doing the same thing twice but rather to store the result where it can be reused (by other threads here).
One may call this a "limited support for object-oriented programming" because it's indeed impossible to implement most of the common OO design patterns in pure PHP but this has in fact very little to do with OOP: shared memory is a system notion and storing intermediate results is what variables exist for! Storing data for later reuse by another thread is not fundamentally different from introducing a variable before a loop to store a constant expression used within this loop instead of recalculating it at each iteration.
You can't do the former in PHP unless you use a RDBMS (not as fast as direct memory access) or... C/C++ extensions which is what Yahoo does (Making the Case for PHP at Yahoo!). Through such extensions, PHP enables the implementation of something similar to a servlet instance member.
But that's much more complicated than in Java, even more if you're trying to implement a generic extension because of type mapping issues between PHP and the extension (C/C++ being stronly typed). Yahoo can of course afford the effort but the result is light-years away from common PHP usage: most of us can't just say they are doing like Yahoo because they also use PHP.
This to say that PHP is a wonderful language. It simply has some drawbacks like all others.
What freedom and what was making it more time consuming than PHP?
I have to agree with the previous poster that JSP offers the same functionality as all of those nice libraries PHP comes with. I don't see where PHP offered such a significant advantage over JSP that you would choose it over JSP when developing a web client. I have used both JSP and PHP on several project and both worked very well but I wouldn't mix them together unless it was absoultely necessary. If you are starting a new project with Java, I would highly recommmed using JSP instead of PHP. JSP has come along way especially since the advent of JSTL (which I continually praise on Slashdot everytime a Java article is posted ;-) ). Mixing technologies should be done only when absolutely necessary (i.e. integrating C and Perl for necessary performace gains) as it's generally much more difficult to debug and maintain by a group of developers. Although there are alot of developers that are very skilled in more than one language, there are many who are experts in one language and are remedial in a few others.
I am not flaming PHP. Dynamic websites can be constructed quickly and easily and it is a nice language in which to develop. if you have an existing Java codebase and you wish to add a web client, I would strongly recommend using JSP instead.
OOGG lack much experience in PHP, but have much experience in stone age OO design.
OOGG confused by combined complaint of "restrictive OO model" and "no provision for protected members or private variables."
PROTECTED MEMBERS, PRIVATE VARIABLES ARE RESTRICTIVE OO MODEL. OOGG use simple stone-age example. OOGG HAVE STONE WHEEL. USE AS WHEEL. SOMETIMES, WANT ACCESS TO HOLE IN CENTER. Some programmer say that hole "protected implementation detail." OOGG think OOGG NO CARE WHAT YOU THINK AT DESIGN TIME. OOGG NEED HOLE ACCESS. OOGG NOT WANT BE FRIEND WITH ALL YOUR CLASSES, JUST USE HOLE!!!
OOGG not like restrictive OO model, INCLUDING not like often useless "protection" features. In general, programming languages ineffective tool for preventing stupidity. Should rather use club on head of stupid programmers. Darwinian process then result in smarter programmers, less outsourcing to foreign caves.
Wrong!
The truth is this:
Business Logic
Java - Good
PHP - Bad
Presentation Layer
Java - Even better
PHP - Good
I used to code in PHP all the time and loved it. But then I learned JSP and realized PHP is a waste of time...after I discovered JSP's tag libraries (both official and open-source ones), amazing amount of templating options, not to mention frameworks like Struts.
The guy who thinks PHP is good for the presentation layer simply hasn't really used anything else...he probably thinks Visual basic is great too.
PHP is cool, but it has so many missing features it's not even funny...and yes, it's SLOW. PHP functions that are built-in are fast (of course...they're written in C/C++), but if you write any of your own complex business logic it falls apart peformance-wise.
I had to write some XML processing in PHP and used the PHP XPath class from sf.net (since my ISP did not enable the built-in XML extensions). In most cases my pages timed out, PHP was not able to complete processing the XML file within 30 seconds (!). Java's JDOM did the same in 3-4 seconds.
but, back to JSP...they're great and make PHP look like a toy. Those who think otherwise have probably never written a real site in JSP. I've written them in both languages and I'm never coming back to PHP again...it's like going back from the full power of Unix to the clunky user-friendliness of Windows 3.11.
Java is not more scalable than PHP by its own because it shares memory. Java enables/simplifies the design of scalable applications, which is not exactely the same. If there is nothing to share, then the execution model doesn't matter. If you can capilize on stuff created once for all, or at least reusable several times, then being able to share memory has a big impact.
"Java-based SEDA Web server outperforms Apache and Flash (sld12)" because of a design aimed at limiting object reinstantiations and context switching. These two pains obviously occur when you do the same things on many concurrent threads: you'd better do it once and share the result.
There is really nothing special with Java and multi-threading about that. The same is true for multi-process Apache C modules programmed to use shared memory.
In fact all four components of the LAMP architecture internally make extensive usage of shared memory (for i in linux apache mysql php; do google "shared memory" $i ; done) simply because cpu cycles and memory allocations are expensive and high performance objectives imply not to waste them. If PHP had a higher level API than its existing one for managing shared memory, web programmers would be able to easily prolong the benefit of using shared memory to the application itself.
I shouldn't end my post with a flamebait but I believe that if a web developer suffers from Java's drawbacks (bytecode/JVM, performance cost of native UTF-16 strings, garbage collection, ...), he's 99% likely to under-use its strengths (great thread API, servlet model, great librairies, ...). Well used, they enable really performant designs. I've seen so many times applications refactored from C to Java performing several times faster, just because it was easy to do things smarter in Java, while very risky in C (Never had a SIGSEGV in a large multi-threaded C application ? Happy debugging and next time you'll keep it stupid!).
The "separation of presentation from logic" is often overdone in my opinion.
Allow me to disagree. The lack of separation between presentation and logic and/or data cost a lot of time and money.
Example: Think of a business like a bank of insurance company. A lot of their data structures and logic have been proved to work for decades. The last 15 years, companies like these have gone through a number of presentation changes: from console to console graphics to window managed systems (often a few different flavors/versions) to html and maybe to wap and soon to ... (whatever the next big thing may be). The logic and data structures does not have to be touched just because people wants a new presentation - but only if separation was done properly. I've built systems which generated web-pages, pda-targeted pages and FrameMaker documents (for printed publications) - all from the same data. In such systems, mixing presentation and data/logic is a sure way to introduce problems.
Another example is the misuse of the RAD tools. RAD tools seem to tempt programmers to skip separation. Why? Well, you can just doubleclick on a button to end up in a "onButtonPressed" method where you can write code. This ease of this is of course good, but what is not good is that way too often the programmers seems to stop thinking and actually writes the logic code there instead of the call to the logic code (which is what should be written in such methods). So, what happens when the vendor stops supporting the tool? Or when a new important presentation technique shows up? Rewite the presentation? Yes, if separation was done properly. If not, you can look forward to rewriting it all.
It often results in having to make changes in TWO places instead of one when you add or alter UI elements, and you cannot switch from say desktop-targeted-HTML to PDA in a one-to-one manner anyhow.
Of course one needs to write new presentation code if you want to present your data in new ways. But logic for business rules and all the data and data structures does not have to be touched if the separation exists. That is truly important if stability of the system is of high priority and wasting time/money is of low priority.
Some of us think that OOP is oversold.
Since I became a bit curious about this opinion I visited your website (http://www.geocities.com/tablizer) and found a lot of interesting reading. In some ways I agree with your point altough the discussion seems to be very database-centric. I do agree that if the application layer only builds an OO-version of the data just to put it up and down to a relational database - then nothing is gained. If the applications are very db-centric and does not do much with the data except for presenting it to users and letting them add/edit/remove blocks of data - nothing is gained. That, however, does not make OO any less useful for a wide area of problems. But that is a discussion of its own. OO is a lot about encapsulation. Encapsulation promotes separation. Separation can definately be done without OO - but lack of separation frequently ends with disaster.
> Also, there was no system support for transactions
Isn't that the database's job?
Not always. If there is only one database or the transaction only has to span over interaction with one database - it could be the database's job. If the transaction involves more than one database and/or something else, i.e. an accounting system or a credit card system, then it can not be database's job.
Hasn't MVC been discredited? There are a lot of complaints about it in techie forums.
(Is there anything that hasn't been discredited?) MVC is about separation of concerns. The Model changes due to changes in the business, the View may change due changes in the business, but major View changes is often the result of either fashion or technical evolution. These concepts are held toghether by the Controller so they can remain separeted. MVC is useful when the need for separation exists.
To sum it all up: Don't forget separation. It is one of the most important things in software development.