Barista извлекает из Javadoc правила использования Java API и оформляет их как спецификации typestate для LiquidJava, чтобы компилятор мог выявлять некоторые нарушения до запуска программы. На странице работы авторы обозначают её как материал ASE 2026; точная дата публикации там не указана. Авторы описывают Barista и результаты своей оценки.
Как Javadoc превращается в автомат состояний
В примере авторов java.net.Socket описан через семь состояний — от несоединённого сокета до закрытого. Например, отправка срочных данных допустима только после подключения; закрытый сокет нельзя повторно подключить или привязать. Barista представляет правила как состояния и переходы, а затем записывает их в аннотации, которые проверяет LiquidJava.
Что показала оценка
Авторы сравнили спецификации Barista со спецификациями двух экспертов для 29 классов JDK. Для каждого класса систему запускали пять раз, а результаты сопоставляли с экспертными тестовыми наборами, включавшими 3 262 тестовых файла. По оценке авторов, precision составила 87,0%: столько вызовов, отмеченных как нарушения, действительно были нарушениями. Recall составила 68,3%: система обнаружила такую долю нарушений в экспертных тестах. Иными словами, в этой оценке Barista чаще пропускала нарушения, чем ошибочно отмечала допустимые вызовы как нарушения.
Скорость и пригодность результата
По данным авторов, создание спецификации занимало в среднем 7,3 минуты и стоило 2,20 доллара на класс; ручное написание экспертом занимало 31 минуту. Пригодность результата оценивали отдельно, по одному запуску на класс: 29% спецификаций можно было использовать без изменений, 46% требовали небольших правок, а 25% признали непригодными. Эти показатели описывают ускорение подготовки черновика, а не гарантированную автоматическую замену экспертной работы.
Где метод теряет точность
В абляционном сравнении полный конвейер показал F1 76,5%, вариант только с документацией — 58,5%, а вариант с автоматом состояний без тестов — 60,9%. Авторы также сообщают, что F1 снижалась с 88% для простых протоколов до 72% для умеренных и 54% для сложных. Частая причина расхождений — переходы, зависящие от значения аргумента: простая модель состояний не всегда может выразить такое условие.
Что это меняет для разработчика
Barista может подготовить проверяемое описание API на основе правил, уже изложенных в Javadoc, и сократить время до первого варианта спецификации. Но recall 68,3% в оценке авторов означает, что часть нарушений остаётся незамеченной, а оценка пригодности показывает, что большинство результатов нуждалось в правках или не подошло для дальнейшей работы без существенной доработки. Страница отдельно описывает бенчмарк из 35 классов JDK 17; это число не следует смешивать с 29 классами, для которых приведено сравнение спецификаций. Метрики, стоимость и время — результаты, сообщённые авторами, а не независимая проверка.
