Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Java PHP Programming

Scriptiing The Enterprise With Java And PHP 80

Posted by timothy from the dual-nature dept.
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."
This discussion has been archived. No new comments can be posted.

Scriptiing The Enterprise With Java And PHP More

Scriptiing The Enterprise With Java And PHP

Comments Filter:

  • OK, that was not what i was expecting (Score:5, Funny)

    by Rhinobird ( 151521 ) on Tuesday July 29, 2003 @01:06AM (#6556952) Homepage
    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.

  • JSP (Score:4, Insightful)

    by cloudless.net ( 629916 ) on Tuesday July 29, 2003 @01:11AM (#6556962) Homepage
    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.
    • 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.

      • 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 (Score:4, Informative)

        by Anonymous Coward on Tuesday July 29, 2003 @08:56AM (#6558580)
        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.

        • > 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
      • 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 [caucho.com].

        Now.. given the choice of Java over PHP for your presentation, why would anyone choose PHP when they can get the same results with

  • PHP doesn't scale? (Score:2, Insightful)

    by trompete ( 651953 )
    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?
    • 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.

      • Scale is such a broad word... (Score:4, Insightful)

        by quinkin ( 601839 ) on Tuesday July 29, 2003 @02:36AM (#6557193)
        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.

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

        • OOGG CONFUSED! (Score:5, Funny)

          by OOGG_THE_CAVEMAN ( 609069 ) on Tuesday July 29, 2003 @07:55AM (#6558107)
          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.

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

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

              • Oogg have point. Make profkyne laugh.

              • 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

            • Re:OOGG CONFUSED! (Score:2, Interesting)

              by drugdealer ( 608193 )
              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.

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

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

            OOGG right.
          • 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

    • Re:PHP doesn't scale? (Score:5, Insightful)

      by tangi ( 592996 ) on Tuesday July 29, 2003 @06:05AM (#6557711)
      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! [yahoo.com]). 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.

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

        • Re:PHP doesn't scale? (Score:2, Informative)

          by tangi ( 592996 )
          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 optimi

          • 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? (Score:3, Insightful)

              by tangi ( 592996 )
              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 cr

      • Re:PHP doesn't scale? (Score:2, Informative)

        by Tablizer ( 95088 )
        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 thing

  • NoooO! (Score:3, Funny)

    by HaloZero ( 610207 ) <[protodeka] [at] [gmail.com]> on Tuesday July 29, 2003 @01:24AM (#6557012) Homepage
    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...

  • Pffff... overkill? (Score:5, Interesting)

    by ptaff ( 165113 ) on Tuesday July 29, 2003 @01:24AM (#6557014) Homepage
    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)
    • 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.

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


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

  • Avoid when possible (Score:5, Insightful)

    by one9nine ( 526521 ) on Tuesday July 29, 2003 @07:08AM (#6557876) Journal
    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.

    • 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 F


  • 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 transacti
    • 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 :-)

  • A reason for Java (Score:2, Insightful)

    by djweis ( 4792 )
    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 com
    • 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 (Score:2, Insightful)

      by dhodell ( 689263 )
      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 S

  • Scriptiing? (Score:3, Funny)

    by Thing 1 ( 178996 ) on Tuesday July 29, 2003 @11:24AM (#6560374) Journal
    Do the editors have a spell checker? Do they have bosses who care?

  • JSP vs. PHP (Score:3, Interesting)

    by inertia187 ( 156602 ) * on Tuesday July 29, 2003 @11:48AM (#6560692) Homepage Journal
    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 [securityspace.com]. 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.
    • 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 prob
      • 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 acc

  • 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

    • Re:I disagree with their characterization of PHP (Score:5, Insightful)

      by nicware ( 216013 ) on Tuesday July 29, 2003 @04:43PM (#6564543)

      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.

      • 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 justificati
        • 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

          • 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 longe
            • 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. Dat

              • 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

  • 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 [jython.org]) -- so compatible that the language is actually written in Java and runs in a JVM! Yes

    • Actually, not just Jython, but IBM created the Bean Scripting Framework [ibm.com], 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 write all my webpages in C++.

Slashdot Top Deals

If all the world's economists were laid end to end, we wouldn't reach a conclusion. -- William Baumol

Close