Как удержать Apache CXF от преобразования примитивов в типы объектов?

Question

Я оцениваю Apache CXF для проекта, поэтому я написал небольшое демонстрационное приложение, чтобы попробовать несколько вещей. Следуя руководству пользователя CXF, я смог довольно быстро запустить и запустить мое приложение.

Одна вещь, которую я хотел проверить, это то, насколько хорошо CXF способен обрабатывать метод, который возвращает большой массив примитивов. Поэтому я определил метод 'float[] getRandFloats(int count)', который просто возвращает массив указанной длины, заполненный случайными числами. Глядя на WSDL, сгенерированный java2wsdl, я вижу, что метод правильно указывает тип возвращаемого значения float[]. Осматривая клиентскую часть, я также вижу, что (в конечном итоге) получаю float[].

Я заметил, что при увеличении количества элементов в моем массиве снижается производительность клиента. Я запустил профилировщик на стороне клиента и увидел, что для каждого элемента в возвращаемом массиве создается Float объектов. Кажется, это происходит, когда CXF вызывает JAXB во время анализа ответа.

Я оцениваю CXF для использования с приложением, которое потенциально отправляет обратно миллионы чисел с плавающей запятой, поэтому создание этого объекта крайне нежелательно. Чтобы использовать CXF, мне нужно найти способ предотвратить создание этого объекта. Я просмотрел документацию и список рассылки, но не нашел способа обойти это.

Кто-нибудь сталкивался с подобной проблемой при использовании CXF? Если да, то как ты справился с этим?

Answer 1

Это определенно ничего не может сделать CXF. Это больше проблема JAXB. Я считаю, что внутренне JAXB обрабатывает все случаи "maxOccurs! = 1" как коллекцию Java, а не как массив. Он просто преобразуется в массив как последний шаг процесса, если это необходимо. Поскольку коллекции Java не могут содержать примитивы, это будут объекты Float.

В любом случае, это должно быть решено с людьми JAXB. : - (

Answer 2

Вы говорите, что производительность клиента снижается при увеличении количества элементов в массиве. Это звучит разумно для меня - больше данных, меньше производительности. Чего ты там ожидал? Пока это линейная деградация, она ведет себя нормально.

Что касается создания миллионов объектов, современная JVM сделает это, не потревожив. Я подозреваю, что дизайнеры CXF хорошо знают об этом. У старых JVM были плохие алгоритмы GC, и миллионы объектов, возникающих вокруг, действительно вызывали проблему, но это больше не так, особенно с очень короткоживущими объектами, как у вас здесь.

Итак, с одной стороны, мы имеем снижение производительности из-за большого количества данных и того факта, что создаются миллионы объектов. Тем не менее, нет никаких доказательств того, что два наблюдения связаны между собой.