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."

Comments

OK, that was not what i was expecting

[Rhinobird]

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.

Re:OK, that was not what i was expecting

[Anonymous Coward]

If you want to see auto-generated scripts for star trek, turn on any episode of "Enterprise."

You can tell this story isn't about screenplays because they used the spelling with 3 "I"s. The word for movie screenplays is actually spelled with 4 "I"s.

JSP

[cloudless.net]

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.

Re:JSP

[Anonymous Coward]

If you want to do some quick and dirty job, use PHP. For larger projects, JSP and J2EE make more sense.

You did not give much justification for this claim.

How about we agree that for "quick and dirty" stuff, use PHP. But for "lumbering, bloated, and dirty", use Java.

(If you mod this down for insulting Java, then mod the parent down for insulting PHP. Fair? Fair.)

PHP doesn't scale?

[trompete]

I didn't know that PHP didn't scale well. Then again, I just use it for hobby sites.
How does Yahoo! use PHP? Do they generate static HTML snapshots or something?
The article was really short....what will PHP5 do to help scalability?

Re:PHP doesn't scale?

[Electrum]

I didn't know that PHP didn't scale well. Then again, I just use it for hobby sites.

PHP does scale. Most people just don't know what they are doing. A good start is not doing fifty queries to the database every page load.

Re:PHP doesn't scale?

[tangi]

PHP is a very performant and handy language but it misses a shared memomy model which is the most important source of scalability.
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.

Re:PHP doesn't scale?

[DavidNWelton]

So Java's answer is just to hoover up all available memory and then share it?;-)

Interesting post though - you stipulate that the java model works because it's all one process with multiple threads that can share data? How is this scalable, say, to multiple computers? Can you point to a document that explains some of this stuff without using words like 'enterprise enabled'?

I know there are some good ideas in Java land, but there is so much marketing bullshit about how it is *the* language for everything. I can't stand that myself.

Re:PHP doesn't scale?

[tangi]

So Java's answer is just to hoover up all available memory and then share it?;-)

Yes ;-) and no. PHP provides a bit less control on choosing the appropriate trade-off between size and speed: an issue born with data structures and algorithms, much older than Java.

How is this scalable, say, to multiple computers?

Performance is a matter of software design and not of language or bytecode or whatever. It's like the "don't debug, verify correctness" principle of eXtreme Programming. Here it's: "don't optimize your code, design it to be fast and scalable".
On multiples computers, your design should also reflect the same principle: avoid reprocessing the same things again and again. The difference is only about granularity. Caesar's "divide and conquer" principle is very useful too.
You may specialize some machines on some subsets of data so each can have in memory the data they need most of the time, let each work on it, and finally merge all sub-results. That's how Google manage its huge index for instance.
You may also keep databases but use them through Active Objects to "decouple method execution from method invocation to enhance concurrency". I often use a LRU cache to address the issue of what should be kept in memory and what should not.

Can you point to a document that explains some of this stuff without using words like 'enterprise enabled'?

That's a very wide topic covering most of computer science: data structures and algorithms, design patterns, architectures of OS, ...
With some experience, I discover OOP and system programming are very similar. Programmers of both worlds often argue although they in fact agree: they simply don't use the same words for the same things!
I therefore suggest you have a look at Design patterns from Gamma and al., Pattern Languages of Program Design from Vlissides and al., read any good book about the architecture of modern OS (paper on I/O aspect), and for god sake keep off "The ultimate /my-favorite-language/ Programming Bible ;-).

IMHO, every programmer should know about design patterns, even if he doesn't consider ever practicing OOP, and about how wonderfully OS are designed, even if he doesn't consider ever leaving Java to write a device driver or an I/O library in C.
In addition to improving software around, it would also make a true miracle: terminate the weekly Biggest Di*k Contest about languages on /.

Re:PHP doesn't scale?

[Anonymous Coward]

And in my opinion everbody who reads Design Patterns should be aware that most of them are really bandaids for symptoms of limited and limiting languages like C++ and Java. Learn Common Lisp CLOS and discover just how much Java sucks.

Re:PHP doesn't scale?

[DavidNWelton]

Thanks for your answer.

To tell the truth, I am familiar with the Design Patterns book, and have notions about system design.

More than anything I was curious about server side Java in particular, which you claim is more scalable because it shares memory. I'm interested in hearing some more details about this - why you think it's so and any references to back it up.

Re:PHP doesn't scale?

[Tablizer]

You can't do the former in PHP unless you use a RDBMS (not as fast as direct memory access)

It is a myth that RDBMS *must* use disk. True, the current implementations were built around a disk-centric approach, but they are slowly evolving to make better use of more memory as the prices drop.

By the way, there seems to be a division forming between relational-centric shops and OO shops. PHP shops are probably more likely to use RDBMSs more extensively, while OO shops tend to kind of do database-like things in code. To me, that is too much hand reinvention of the database, plus does not give you the power of relational theory, but relational-vs-OO debates have already raged on slashdot.

Re:PHP doesn't scale?

[tangi]

More than anything I was curious about server side Java in particular, which you claim is more scalable because it shares memory. I'm interested in hearing some more details about this - why you think it's so and any references to back it up.

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!).

Re:PHP doesn't scale?

[Anonymous Coward]

PHP is a very performant and handy language but it misses a shared memomy model which is the most important source of scalability.

in my country we call java's shared memory model by its traditional name: "swap"

NoooO!

[HaloZero]

I just... cannut... dooo it, kaptain!... the damned server j'st dunnit have the POWAH!!! Filthy cyrix piece of jun'k. I've seen Klingon garbage scows with bet'er processin' units than theeeze. Ah mean, you cannut really expect meh to be able to run a business on THIS kind of processor!

Tho I may be able to give ya' warp three...

Re:NoooO!

[ophionman]

I know you can scotty! deflect power from the shields!
* Cheese background music *

Pffff... overkill?

[ptaff]

What makes PHP so nice for web development?

• Is it syntax style? No, it's pretty standard C-like-syntax-with-braces;
• Is it speed? Nah, interpreted like most of them web languages;

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)

Re:Pffff... overkill?

[quinkin]

You want to wait for one language that has all of the positive aspects of Java and PHP, and none of the negatives??

In the intervening century, you may want to look at using the right tool for the right job...

Just my AU$0.06

Q.

Re:Pffff... overkill?

[jrumney]

An artist can draw a page in his favorite application, export to HTML, the coder only has to fill the blanks.

And if the artist's favorite application happens to be MS-*, good luck filling in the blanks.

I'm having trouble working out from your post what exactly the advantages of PHP are over JSPs. Everything you mention is easily available as a Java library, and standard tag library has most of the more useful things for web pages (SQL, gettext) covered so you don't need to write code to use them.

Re:Pffff... overkill?

[BigGerman]

Java/JSP _does_ have all these libraries and HTML/session integration. With JSPs you have the same:
access to rich Java libraries for text processing, XML, LDAP, images, zip, etc
plus easy way out to the enterprise world with J2EE.
So what is the point?

Re:Pffff... overkill?

[Anonymous Coward]

Java culture labors under a bunch of CS-educated programmers and complex "Best Practices". This tends to make Java apps more "scalable" and "maintainable" -- but the side effect is that they are more expensive to produce for small apps, and have a longer turnaround time.

Meanwhile PHP doesn't pretend to be anything other than a quick hack language, so quick hacks are not only culturally acceptable, but even encouraged.

JSP does support PHP/ASP-style hack spaghetti programming if you want it too. However, your "Java Architect" will puke all over his shoes.

Prescient Today

[quinkin]

Wow, I was just discussing this with my boss this morning and here it is!

All of the problems I have with the existing methods of JavaPHP integration look like they should be fixed.

Not being able to use references is the most crippling aspect of the SAPI interface - well that and the fact it is completely unreliable. :)

Q.

JSP/PHP Compare and Contrast

[quinkin]

Let me make it simple for you (aka. troll follows).

Business Logic
Java - Good
PHP - Bad

Presentation Layer
Java - Bad
PHP - Good

Now if you can use the good aspects of both of these languages (ie. Java for business logic and PHP for presentation layer) then you get Good + Good.

Currently they integrate both unreliably and limitedly - This project is designed to fix these shortcomings (initially for PHP, but using it as a template for further scripting integrations).

NB: Troll complete

Q.

Re:JSP/PHP Compare and Contrast

[ForteTuba]

I'll bite. Alas, what often happens in situations like this is that you get Bad + Bad: people use the wrong tool for the wrong job. It's sad, because the idea that for a given job there are more and less appropriate languages is practically a cultural meme among programmers -- but that idea is regularly ignored in practice.

Re:JSP/PHP Compare and Contrast

[Anonymous Coward]

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.

Re:JSP/PHP Compare and Contrast

[Randolpho]

Here, let me rewrite that for you:

Business Logic Java - Good
PHP - Bad.

Presentation Layer (Web)
Java/JSP - OK
PHP - OK

There, that's more in keeping with what I know of both languages. Now, Java is superior to PHP for business logic, as you picked out, but Java has JSP/Tomcat, which is functionally just as good as PHP, at least according to benchmarks I saw recently.

Now.. given the choice of Java over PHP for your presentation, why would anyone choose PHP when they can get the same results with JSP, but have the added upshot of keeping everything together in the same basic syntactic setup? Java code is easier to create and maintain than PHP code, and it's faster.

There's no real need to use a different system unless you get a benefit from it. You claim the benefit is in using PHP for presentation in web applications. Fine, but I don't see it. Now, if you suggested something along the lines of Zope's Page Templates, I might agree. But if you're at the point of using Zope for your presentation, there's no reason to use a different platform for the logic, as Zope is written in Python, and Python is an outstanding programming language, easily heads and shoulders above Java in every respect except raw number-crunching performance and IDE availabilty. At least, IMO. :)

But the question is Java vs. PHP. In that case, the answer is Java.

Re:JSP/PHP Compare and Contrast

[Randolpho]

Arg. Missed a
tag in there. Please forgive the formatting. :)

Re:JSP/PHP Compare and Contrast

[Anonymous Coward]

"Benchmarks I saw recently"

Let's see. Apache 1.3.9, php 4.0b2. So 1999 was recently?

Re:JSP/PHP Compare and Contrast

[Randolpho]

Er... no, I saw the benchmarks recently. I was actually looking for zope vs. php benchmarks, and stumbled on those. :)

Re:JSP/PHP Compare and Contrast

[dismayed]

Regarding not having Zope page templates in PHP or Java...
There are implementations for both:

• PHPTAL
• JavaZPT

Re:JSP/PHP Compare and Contrast

[Randolpho]

Damn, now I wish I hadn't posted so I could mod you up! Thanks for the links. Daddy like.

Re:JSP/PHP Compare and Contrast

[tpv]

Python is an outstanding programming language, easily heads and shoulders above Java in every respect except raw number-crunching performance and IDE availabilty

There's a large set of "enterprise" features in java (e.g. JTA, JMS) that python doesn't do.
It's not relevant to everyone, but for those that need it, java is way ahead of python.

Re:JSP/PHP Compare and Contrast

[Randolpho]

JTA and JMS are both libraries, not part of the core technology. You might as well say that OpenGL is part of the C language.

Re:JSP/PHP Compare and Contrast

[whois]

> 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.

Obviously this is a troll, but I'll poke at it anyway.

So you're saying that your ISP wouldn't enable a builtin feature of PHP that would make things faster for you, so you switched development languages?

Wouldn't you have to get them to install tomcat?

Why not switch ISP's? Seems just as easy, if not easier than switching languages. Or hell, a linux-capable PC can be had for $100 now. Why not install PHP at home and benchmark it with all the options turned on.

Re:JSP/PHP Compare and Contrast

[Anonymous Coward]

I dont know who you are but Visual Basic is amazing.

Scale is such a broad word...

[quinkin]

I think "scale" is a slightly misleading term.

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.

Re:Scale is such a broad word...

[Hemi Rodner]

Hmm.. does ASP, or ASP.NET, scale better than PHP?

Re:Scale is such a broad word...

[Anonymous Coward]

asp.net most definitely does.

Re:Scale is such a broad word...

[Anonymous Coward]

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...

Them 'er fightin' words. OO stinks for business modeling. It might be okay for systems infrastructure, but not for business modeling. Otherwise, show me evidence it is better.

Suffice to say that PHP may not shine under YOUR design methodologies. I doubt any one language shines under all methodologies.

Thus, yes. If you believe in heavy OO, then PHP is probably not for you. But that does not mean that it does not give decent performance under other design methodologies.

The slow and the fast of it!

[nonewshere]

Come on, why whould you want to slow down a very fast interpreted language by combining it with a very slow bytecode based language with function.calls.that.are.like.this.out();

Avoid when possible

[one9nine]

Also, Sun released Servlet API and JSP specifications for development of the web based applications. And this combination was proved to be a real hit in enterprise development domain. But developers didn't have all the freedom that the PHP (and other script language) developers had and the web development in Java was very time consuming. Many MVC frameworks like Struts and template engines such as Velocity were created but again the problem remained.

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.

Re:Avoid when possible

[mobosplash]

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 ;-) ).

I completely agree with this statement. I am a longterm PHP user and still used it over Java when I needed to build small projects quickly. The JSTL (Java Standard Tag Library) has completely changed my mind on this. It makes simple web apps as easy as PHP or even Cold Fusion yet you can always move things out into Java Classes or Servlets if things need to scale up.

OOGG CONFUSED!

[OOGG_THE_CAVEMAN]

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.

Re:OOGG CONFUSED!

[ProfKyne]

Oogg head hurt more when implementation details and "private" methods refactored between v.1.0 and v.2.0, and has to re-code application to use public API after all, as Oogg should have done in first place.

Nothing forcing Oogg to use private/protected in Oogg's own code.

Re:OOGG CONFUSED!

[clearcache]

That was the funniest post I've read in a long time.

OOGG right.

Re:OOGG CONFUSED!

[OOGG_THE_CAVEMAN]

OOGG recognize possibility of refactoring, and understand tradeoff involved. Software engineers, however, not changed since stone age. 1.0 API brain-dead anyway, implementor always take advantage of "major version" to "upgrade" API incompatibly, so OOGG change his code in any case. In meantime, OOGG need deliver his app before next ice age start.

OOGG may be caveman, but can read API header comment, see what is internal or not. No need to crack OOGG head with private/protected club.

Re:OOGG CONFUSED!

[ProfKyne]

Oogg have point. Make profkyne laugh.

Re:OOGG CONFUSED!

[drugdealer]

What if the public API does not provide the needed functionality - but a private method or a manipulation of a private variable does?

Options:
1) Request change to public API, then wait for the owner of the code to change it.
2) Add a new method to the public API yourself - then try to merge it in if you are not the owner of the code.
3) Access private method or variable (after changing some keywords).

I think a lot depends on the accessibility and responsiveness of the owner of the public API.

Re:OOGG CONFUSED!

[quinkin]

Hehe - nice one OOGG :)

No need to run to far with the ball on this one - I grabbed a few examples of limitations that have indeed bitten me on the arse before (on several projects of varying sized teams under _others_ specified methodology - ack).

I should point out that I refused to use Java after my experience with 1.0, so I am only familiar with Java 2.

That said - most of it was fair criticism.

My basic tenet, which I continue to stand by, is that PHP does not allow enough OO _freedom_ (yes freedom - I am not requesting the forcing of these options, that is one of the greatest strengths of PHP).

Yes, yes, I know that not everyone will agree that they need/want this functionality - but I can tell you right now that many of us do.

"OOGG may be caveman, but can read API header comment, see what is internal or not."
OOGG... and I'd been agreeing with so much of what you said.... I don't know, maybe cavemen have better memories or more time to continually re-read (and update) API header comments.....

Q.

Re:OOGG CONFUSED!

[ProfKyne]

In that case one idea is that you wrap the code with the Adapter design pattern so that if the original author of the code does eventually provide a public interface, you can just adjust your adapter to use the public API and all of the places where you called the Adapter code will be updated too.

Enterprise Coding

[mnmn]

Object Oriented design has always given the illusion of ease. Simple C or perl based structured programming can get the job done in a far more intuitive way, especially in enterprises.

In an enterprise there might be many departments located in different places with different needs. There will be varying levels of security and many coders working on various modules and expecting them to interconnect stably. Many customized clients will connect to the same centralized databases and perform standard transactions after being authenticated. The authentication structure itself will be distributed (LDAP?).

So a set of standards should be made and well-documented on how the clients will authenticate and how the transactions will be made. Sample clients would be developed and distributed with their sources among the departments/branches which they will alter and customize. They could do all this with Java, C, C++ or anything else. Now since the universities are spewing out tonnes of low-cost Java developers, thats the language of choice. Quite unfortunate if you ask me.

Re:Enterprise Coding

[Tablizer]

Object Oriented design has always given the illusion of ease.

I never even got to see the illusion. For me, it was a pain in the ass from the very beggining :-)

Re:Enterprise Coding

[Anonymous Coward]

Object Oriented design has always given the illusion of ease. Simple C or perl based structured programming can get the job done in a far more intuitive way, especially in enterprises.

Sounds like something someone who doesn't understand OOP would say...

A reason for Java

[djweis]

One thing I like about Java compared to PHP is that I never have to recompile my servlet engine to add features. For example, I spend too much time getting pdflib to compile/install itself into php, but adding similar features to java requires dropping a single jar file in the correct directory. Same with imap support or anything else. It gets even better when you develop on your x86 desktop and deploy to a Sun machine or something else. The same jar file works everywhere, instead of figuring out how to compile on two platforms instead of one.
Database independence is already there also, you don't need to choose from 4 wrapper layers like PHP has.

Re:A reason for Java

[forsetti]

Database independence is already there also, you don't need to choose from 4 wrapper layers like PHP has.

You mean like JDBC, JNDI, JDO, EJB, .... ?

Re:A reason for Java

[dhodell]

Well, you know you can make dynamic libraries and NOT compile them into the core language. Then you drop a .so file into the correct directory. And when you want to use it, you type dl('some_extension.so').

Java has many different DBI possibilities, at least as many as PHP has.

Yes you do have more problems with "portability" but that's expected, I guess. However, I don't know any widely used extensions that don't have binaries available for win32, linux, and bsd. Many even are packaged for Solaris on SPARC.

I won't comment on Java's performance, but you really do need a lot of nice hardware to run Java things well. It has lots of overhead.

Scriptiing?

[Thing 1]

Do the editors have a spell checker? Do they have bosses who care?

Re:Scriptiing?

[/dev/trash]

See this http://ads.osdn.com/

That's all the bosses at /. care about.

JSP vs. PHP

[inertia187]

I know this article is about combining Java and PHP, but has anyone noticed that JSP has overtaken PHP at least from the standpoint of session cookie default names. It didn't used to be like that. PHP always points out the mod_php numbers, but there is no direct JSP Apache module, only mod_jk which is for any servlet container. I think that's interesting.

Re:JSP vs. PHP

[Tablizer]

I know this article is about combining Java and PHP, but has anyone noticed that JSP has overtaken PHP at least from the standpoint of ...

Unfortunately, I am not surprised. "Corporate" has always gravitated toward statically-typed languages in the past, and Java is no exception. I like dynamic languages in general, but they never seem to "catch on" as "corporate" languages. For example, COBOL and LISP were born roughly at the same time, yet corporate ignored LISP for the most part.

Static fans will probably say that compile-time checking reduces errors, but I don't find that to be the case, at least not for me. The extra code and formality they need introduces problems of its own.

Re:JSP vs. PHP

[__past__]

I think it's not really about static typing only. "Corporate" doesn't like too much power and flexibility, probably thinking that it makes it harder to maintain the code once they fired the incompetent code monkey that wrote it.

It is really interesting to read some of the early Java papers. It was explicitly designed as a language for huge teams of mediocre programmers, while languages like Lisp expect programmers to know what they are doing (for example, like in Python, it will make it visible if you access a function you are not supposed to, but will not prevent you from doing so).

Re:JSP vs. PHP

[Anonymous Coward]

It is really interesting to read some of the early Java papers. It was explicitly designed as a language for huge teams of mediocre programmers

Well, they acheived it alright.

Re:JSP vs. PHP

[Anonymous Coward]

What this chart shows is that ~50% of ASP programmers don't know how to change the default session cookie name, followed by ~10% of JSP programmers and ~5% of PHP programmers. It follows that PHP programmers are smarter.

Re:JSP vs. PHP

[Anonymous Coward]

You could look at it that way. But 99% of all IIS servers are set to the default whether they use ASP or not.

I disagree with their characterization of PHP

[Tablizer]

but PHP was designed for page centric architecture

So? The "separation of presentation from logic" is often overdone in my opinion. 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. The application needs to be repartitioned for such often. People often get such "mantralets" in their head and have to be slapped out of it.

with very limited support for object-oriented programming

Some of us think that OOP is oversold. I have yet to see a convincing example or argument. OO fans cannot even agree exactly on why OO is allegedly better. For certain network protocols I suppose it makes it easier to swap implementation with another vendor, but only if both vendors use the same exposed protocol, which they often don't anyhow. You can wrap them in functions just as easily as in classes in order to provide the same interface.

Also, there was no system support for transactions,

Isn't that the database's job?

[no support for] software components

Huh? PHP is full of existing "components". The component model is often not appropriate for business logic/modeling anyhow IMO.

PHP does not scale well and there is no easy and standard way to make a cluster to achieve better scalability.

Tell that to Yahoo, who adopted PHP.

So, if you are PHP developer and your project is getting larger and larger every day, and the scalability is your main issue, try to force MVC

Hasn't MVC been discredited? There are a lot of complaints about it in techie forums.

One thing I really miss about PHP is named parameters. I would like to see the team work on that rather than things like "better" OO.

Re:I disagree with their characterization of PHP

[nicware]

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.

Re:I disagree with their characterization of PHP

[Tablizer]

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).

I find that usually the language used changes also. Often a new GUI fad is used as a justification to start over, for good or bad. Things went from COBOL to VB to Web, etc. Perhaps this is not rational, but that is what is often done. The UI "feel" is often too different to just plug in one-to-one anyhow. Plug-and-play drop in of UI paradigm requires either too much indirection, or too strong a crystal ball.

Thus, to put more indirection (layers) into the code for some distant future change that is likely moot is not worth it. There is the financial concept of Future Discounting that also applies.

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.

Most transactions I face are done by the database. Sure, there are exceptions, but that is the case for anything. Show me that OO works better than procedural for such exceptions.

To sum it all up: Don't forget separation. It is one of the most important things in software development.

In this case, it is oversold IMO.

OO is a lot about encapsulation.

Other OO fans will probably disagree. There is no consensus on what OO is "really about".

Thanks for your feedback.

Re:I disagree with their characterization of PHP

[nicware]

I find that usually the language used changes also. Often a new GUI fad is used as a justification to start over, for good or bad. Things went from COBOL to VB to Web, etc. Perhaps this is not rational, but that is what is often done. The UI "feel" is often too different to just plug in one-to-one anyhow. Plug-and-play drop in of UI paradigm requires either too much indirection, or too strong a crystal ball.

I think (or rather worry) that the reason that they change language often is the reason I gave. Too coupled code made it cheaper to rewrite it all. Using a new language for the presentation and keeping the current working logic is not a problem if there is a separation.

A colleague was working as an architect for a bank. They had running (business critical) systems written in 25 (yes, twenty-five) different languages. Some of these languages was actually unknown to the all the currently employed developers (which to my surprise didn't really hurt them since they could communicate with these systems, get the data they needed from it and continue the processing elsewhere).

But to take a mainstream bank example: When you are internet-banking, the systems that are used are not rewritten. The html producing code communicates with other systems, most of them written in COBOL. More often today, some Java Enterprise middleware seems to end up in the middle of all things, mainly to encapsulate older systems and make it easier to communicate with them. But the COBOL code is still running in the bottom. 24/7. It just has to.

An easy way to see that this is the case is that with the Euro introduction in many European countries, COBOL programmers are (again) back on request.

Most transactions I face are done by the database. Sure, there are exceptions, but that is the case for anything. Show me that OO works better than procedural for such exceptions.

I never said that OO would do that better. And OO per see doesn't. I just answered your question if transaction handling wasn't the databases job. In many systems, it is some (OO or non OO based) middleware products job. And I personally would not go as far as calling the use of these products exceptions.

> OO is a lot about encapsulation.

Other OO fans will probably disagree. There is no consensus on what OO is "really about".

No, there is probably not any consensus (although I think most OO language designers would tell you that there was a good reason they added two or more access levels for the data). There are as many ways of treating OO as there are developers. But there are also as many ways of treating procedural code as there as developers. At least when I was doing all my development in procedural languages, there were huge differences in what things people valued and the practises they used. If that hasn't changed, I guess the situation is the same in both "camps"?

Re:I disagree with their characterization of PHP

[Tablizer]

I think (or rather worry) that the reason that they change language often is the reason I gave. Too coupled code made it cheaper to rewrite it all.

Perhaps, but do you think most places *want* to stick with COBOL forever? (Maybe banks do for whatever reason. I never worked for a bank so far.)

And I personally would not go as far as calling the use of these products exceptions.

Well, OO designs tend to do in app code what database-centric shops do in the database. If you do X alot, then it is no longer an exception by definition. But that does not necessarily make it a "good" practice. Databases take care of a lot of stuff that I would hate to have to code up myself. And, relational is a powerful paradigm if you know how to use it.

Re:I disagree with their characterization of PHP

[nicware]

Perhaps, but do you think most places *want* to stick with COBOL forever?

Developers? Some, but probably not the majority. The ones paying? Yes, as long as it is magnitudes cheaper than rewriting it all.

>And I personally would not go as far as calling the use of these products exceptions.

Well, OO designs tend to do in app code what database-centric shops do in the database. If you do X alot, then it is no longer an exception by definition. But that does not necessarily make it a "good" practice. Databases take care of a lot of stuff that I would hate to have to code up myself. And, relational is a powerful paradigm if you know how to use it.

Hmm, I get the feeling that you're continously try to mix the transaction question with the OO question? Transaction-handling middleware systems have been widely used for 30 years and it is only recently some of them have been based on OO. How can transactions over several databases and/or other systems not been seen as a "good" practice when several systems often are involved in transactions?

As a separate topic: Yes, perfectly correct, some designs sometimes do in app code what others do in database. For repetitive code (such as OO-to-relational mapping) sometimes one buys products to generate that code, much in the same way non OO projects uses certain tools or development environments that do the same stuff. Are you arguing that there is only one "good" way to do this?

The reason for using different approaches may be many. For example: Where do I put my eggs? At the db vendor? Myself? Some third-party product? Different answers for different situations. In systems I've worked with, different databases have been used for different customers depending on the machines they use, their expected transaction volume and the amount of money the customer was willing to put on the db-part of the system. In those cases, you want to keep away from doing neat stuff in the databases since you'll have to adapt or rewrite that code for a handful of products. Not productive.

Of course databases can do a lot of good stuff and I have never questioned that the relational paradigm is highly useful. But there really are several ways to do things and I can't see a reason for not choosing what is most proper for each situation?

Cheers!

Re:I disagree with their characterization of PHP

[Tablizer]

Perhaps the company(s) you work for have a different culture than those I am used to. Many of the companies I worked for are often "remaking" themselves. New management, new projects, etc., such that they are often tearing out old stuff and putting in new stuff every decade or so to "remain competative". Banks may be different. They must be veeeery careful with money, and so do things walking on egg shells perhaps.

Because I don't work in banks, I guess I cannot really question your choice of the tradeoffs you focus on. You know your customers/users better than I do.

Say it, brothuh!

[Anonymous Coward]

And in my opinion everbody who reads Design Patterns should be aware that most of them are really bandaids for symptoms of limited and limiting languages like C++ and Java. Learn Common Lisp CLOS and discover just how much Java sucks.

Amen! GOF Design Patterns are for people who either use shitty languages, or don't know how to use relational properly, or both.

Jython

[ProfKyne]

After describing two ways that one can (somewhat inelegantly) bridge PHP with Java using current technologies, the author of this article then mentions Erik Hatcher's weblog lamenting something to the effect of 'it would be nice if this were not limited to serverside app development'. I find this interesting, because there is a great scripting language (Python) which already has a Java-compatible implementation (Jython) -- so compatible that the language is actually written in Java and runs in a JVM! Yes this means you can access just about any Java class from a Python script, and not only that, the final Python scripts are Java executables.

Re:Jython

[d-rock]

Actually, not just Jython, but IBM created the Bean Scripting Framework, which will let you host a number of different scripting languages, Python, Tcl, etc. Either your java classes can call out to scripts, or your scripts can run and use java classes. Sadly, it looks like it's been a while since anyone updated this, so I don't know what the current status is.

Derek

I wouldn't know.

[E_elven]

I write all my webpages in C++.

Are you insane???

[quinkin]

"OO stinks for business modeling"

Are you insane???

"Suffice to say that PHP may not shine under YOUR design methodologies."

Ummm, well actually I have used to create several major sites - but I am not blinkered to it's limitations (and kudos to Rasmus and Co. for creating such a kick-ass OSS scripting language).

"I doubt any one language shines under all methodologies."

I don't know - they all seem to work OK in machine code... but thanks for stating the obvious...

"...that does not mean that it does not give decent performance under other design methodologies."

*SIGH* If you bothered to read my quote rather than just cutting and pasting it you would have noted that it was not referring to the performance of PHP but rather it's maintability.

I would have posted that drivel as an AC too...

Q.

Re:OOGG CONFUSING!

[quinkin]

Way to prove my point OOGG :)

Note: I should probably have used the term "incomplete" (set theory, not opinion) OO implementation, instead of "restrictive OO model". So fair criticism Cavey.

"Some programmer say that hole "protected implementation detail" - indeed as they have another obtuse use for that hole that you in your particular cave of the woods has no idea about.

So instead of determining the reason for this restriction (if arbitrary it should be removed) you go ahead and f*ck with the hole on your "wheel".

Unfortunately, that wheel is part of a cart that is used to haul (lets say) Mastadon meat back to your tribe. The hole of the wheel has been enlarged by OOGG and continually falls off the carts axle.

The rest of the tribe beats OOGG senseless with his wheel, repair it's hole, and return home.

Not to indulge in your fantasy to far Cavey, but it seemed such a nice analogy to maintenance of a large body of code (neadertals roaming the forest, scratching their heads, clubbing the sales department and grunting occasionaly - perfect).

Q.