> That's one more point I forgot. > total 6 out of 5. Uh-oh, looks like you've got a boundary condition error there.
> > CF runs on Windows, Solaris, Linux and HP/UX now, and the > > next release will probably run on everything that JRun runs > > on now. You can only get it from Macromedia, though, as you > > point out. > > You can't run a CF application on TomCat. You can run the > same J2EE app on Jrun, J2EE Reference Implentation, Bea, IBM, > JBoss, Orion .......... CF doesn't run on IBM AIX - yet. That's why I gave you .5 on this one. You can run CF on most commonly used server OSs, but not all. With CF 5, you don't need to use Tomcat or any other Java application server, of course; you need the CF server product. > > > speed, > > > > I have seen no reason to believe that J2EE is inherently > > faster, yet. > > I have. The code is note being precompiled before it is executed. Well, that sounds really good and all, but have you done any comparative testing? Compilation sounds good, but hasn't provided much noticeable speed increase in my own (admittedly relatively simple) testing, using load-testing tools. It's worth noting that, while CF code isn't compiled, after a page has been run the instruction set for that page is stored in memory. > > > security, > > > > Huh? How is J2EE more secure? > > Java is not typeless which in some cases be a security > hole...(Dropping tables over the URL, a minor example) You know, no one really drops tables over the URL in my experience; that's kind of a "forced" example. Truly effective (and common) SQL injection attacks are much more subtle than that. In a well-designed CF application, all data from the browser is filtered before being sent to the database, not just expected integer values. In any well-designed web application, the application should have limited rights within the database, and shouldn't be able to drop tables or execute system stored procedures or anything else like that. In a poorly-designed Java application, on the other hand, I'd guess that you could execute an SQL injection attack just as easily as a poorly-designed CF application - after all, strings are just as vulnerable to this sort of attack, and form data is just as vulnerable as URL data. It's a fallacy to think that, because Java is "secure", your applications are secure. They're probably not, unless you keep security in mind during the application design, partition your applications and their rights/privileges appropriately, and always filter your input. > > > scalabilty. > > > > CF is plenty scalable, if done right, just like everything > > else. > > The problem is that it isn't done right often enough. Most > people have an idea and go, and ColdFusion lends itself well > to that. That's not a good thing in my opinion. The more you > plan the less you program and the more mantainable the app is. So, you're saying that, because CF allows you to do bad things, that's a strike against it? I've seen some scarily bad Java implementations, for what that's worth. I agree that, because it's harder to do anything in Java, the average Java programmer requires a higher level of knowledge than the average CF developer. Of course, by that argument, if you did everything in assembler, that would be the ideal solution, because you'd really have to know a lot to make that happen. This strikes me as a variation of the old argument that "real programmers use C++, not [insert the language you want to denigrate here]". As I see it, an easier to use platform is, all other things being equal, better than another platform. You can spend that planning time just as fruitfully developing CF solutions, and spend even less time implementing those solutions. I do agree that using an object-oriented language may help to force you to think about the problem you're trying to solve, and that using an application partitioning scheme like Jakarta Struts may help you to better organize your code, but they're not going to guarantee quality software. > Session Management in a Clustered enviroment. Yes, you can do that in Java but can't in CF. So far, that hasn't been much of a limitation in my experience. It's very easy to set up a useful shared data repository; it's just not memory-resident. > Building distributed applications. Ever write a Custom Tag > and have it called from a none Web-Based Application? You can > develop an EJB and have it used from a Web Container or a > Client Application, you can send the bean out into the world > and have it run in any compliant EJB Container. Yes, you can do that in Java. On the other hand, you can do that with CF today, as well - I've done it with COM on the Windows platform, for example. CF will let you talk to all kinds of stuff, and doesn't limit you to building extensions in CFML or the CFXAPI. You can interact with COM, CORBA, EJB and so on (although I haven't used the last two within a CF app, myself). > > On the other hand, there are some great arguments for > > sticking with CF, such as ease of maintenance and comparative > > labor costs. > > A well designed Jave Application is also easy to maintain. It > may take longer to develop then in CF, but there are advantages. "Easy to maintain" is a relative measurement. It may be easier than something done in, let's say, Perl, but it's not likely to be as easy as CF. It will take longer to develop, and maintenance will take longer as well. > Java is an industry standard and therefore I could imagine > that a company willing to spend a million or two on an > Inter/Extra/Intranet project is more likly to choose the J2EE > platform. Yes, I agree that Java has momentum in that respect. That's hardly an argument that it's better, or more suitable for web applications. Given the thrust of Neo, though, it'll be interesting to see how many people find it a way to "choose the J2EE platform" without giving up the ease of use that CF provides. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
