> And as Dave mentioned, as far as the stability of java APIs goes, the xml > ones are a pretty safe bet. :)
yeah, I'll pay that but it's still not a 100% guarentee. > You still have to change code to match > the new features if CF changes behavior awww, don't undersell the quality control that the CF engineers have been able to maintain over the years. I'm having trouble thinking of any examples ** of CF4.5 code wholesale breaking on a CF7 install (apart from bad practices like CFBreak in a CFSWITCH statement, new features and replacements to things that just sucked like the old cfchart). Hell, even Microsoft hasn't got *that* track record (ever tried migrating VB4 code to VB6 or VB6 to VB.NET? - it's not as straightforward as MS makes out) I still think it's pretty amazing that Alaire changed the underlying codebase from C++ to java and pulled it off so well. That sort of long term relationship with a product is pretty priceless IMHO (moreso if you're writing turn-key apps, a dead issue if the development is more "fluid") ...which is why I'd prefer to eat my java with a CF spoon, palm some of the risk off to someone else (iText libraries and CFDOCUMENT, anyone?) Roland I see your point and I don't disagree but can you see mine that CF is a great java abstraction layer and is there anything wrong with wanting more of it? it makes a good selling point... ** rats! just thought of one example...dynamic datasources. But IIRC, they had no choice with the JDBC drivers. The exception proves the rule, perhaps? ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
