Безопасно ли вызывать базовый Java-метод для String в ColdFusion? - PullRequest
4 голосов
/ 26 августа 2009

Adobe ColdFusion построен на Java. Почти все простые переменные в CFML / CFSCRIPT имеют значение java.lang.String до тех пор, пока для операции не требуется, чтобы он был определенного типа.

Я всегда хочу использовать startsWith() в String вместо более громоздкого варианта CFML.

left(str,4) EQ "test"

Однако, каково общее мнение об использовании базового метода Java в ColdFusion?

Будет ли безопаснее javacast() вар первым?

javacast("String",x).startsWith("test");

Что если механизм CF не построен поверх Java?

Спасибо

Ответы [ 2 ]

6 голосов
/ 26 августа 2009

Да, вы можете сделать это с помощью Adobe ColdFusion и других механизмов CFML, построенных на Java. Это на самом деле проще, чем вы думали.

<cfset str = "hello what's up" />
#str.startsWith("hello")# <!--- returns "YES" --->
<cfif str.startsWith("h")>
  This text will be output
</cfif>

#str.startsWith("goodbye")# <!--- returns "NO" --->
<cfif str.startsWith("g")>
  This text will NOT be output
</cfif>

Это возможно, потому что строки CFML в ColdFusion такие же, как строки Java. Вы можете использовать любой собственный метод строки (Java.lang.String) для строки CFML.

Если вы еще не догадались, это также работает с массивами CFML (некоторый список, вероятно, java.util.Vector) и структурами (возможно, с java.util.Map). Поэкспериментируйте с типами данных и тегом cfdump, вы найдете много секретов.

Одно предупреждение: это , а не стандарт CFML, поэтому, если ваш базовый движок изменится, в том числе просто перейдет на новую версию, нет никаких гарантий, что он все еще будет работать.

При этом string.startsWith () является родным для Java, а также для .NET, поэтому это также будет работать, если ваш CFML-движок - BlueDragon.NET. Единственные механизмы CFML, на которых он не будет работать, - это ColdFusion 5 и предыдущий.

Безопасно ли использовать? Я бы сказал, да. Пока механизмы CFML работают на Java или .NET, это абсолютно безопасно. Он недокументирован, но его легко понять, поэтому я бы сказал, что пользуйтесь им свободно.

2 голосов
/ 18 ноября 2011

Я обнаружил, что использование встроенных cf-функций в большинстве случаев быстрее, чем использование их Java-аналогов, в основном, потому что это обходится cf-упаковкой java-методов очень дорого.

Если вы используете .startsWith (), помните, что он чувствителен к регистру, а у cf - нет. То же самое относится и к большинству других методов Java String - .endsWith (), .contains () и т. Д.

Если вы не можете связывать большие наборы функциональных возможностей, когда вы катаете свои собственные классы утилит java, смешивание вызовов cf и java кажется медленным. Если вы находитесь в каком-то Java-коде, и у вас есть строка, и вы вызываете ее метод startWith (), он просто выполняется. Готово. В коде cf вы должны javaCast или вслепую надеяться, что переменная имеет правильный тип данных, что рискованно для таких вещей, как полностью числовые строки, и когда вы вызываете .startsWith (), есть куча кода cf, который выполняется до он даже опускается до уровня Java, где и живет медлительность. Например. Динамические аргументы Cf означают, что он должен проверить, существует ли метод в предоставленном объекте с таким количеством аргументов и этих типов данных (или совместимых типов). Есть только целая куча кода, который неизбежно работает, соединяя два языка.

Но не верьте нашему опыту, оцените его сами. например.

<cfscript>
var sys = createObject( 'java', 'java.lang.System' );
var timer = sys.nanoTime();
    // run some code here
timer = sys.nanoTime() - timer;
writeDump( var: timer );
</cfscript>

Если вы используете движок Adobe cf, следите за полностью числовыми строками, они перепрыгивают между двойными и строковыми значениями java, и не заводите меня с serializeJSON () ...

...