Megérkezett a GitHub Copilot SDK for Java előzetes kiadása

Frameworkfüggetlen AI-vezérlés Java alkalmazásokból

A GitHub szerint a Copilot SDK for Java az első valóban frameworkfüggetlen megoldás arra, hogy Java alkalmazásokból AI-funkciókat lehessen vezérelni. A bejegyzés ezt a Langchain4j és a Spring AI megközelítésével állítja szembe: előbbinél a Langchain4j, utóbbinál a Spring tervezési döntései jelentenek függőséget.

A könyvtár szerveroldali Java környezetekben működik, köztük Jakarta EE és Spring alatt. A GitHub kiemeli, hogy a Java fejlesztők számára ismerős eszközökre épít, például CompletableFuture, annotációk, lambdák és virtuális szálak is szerepelnek benne.

A blogposzt szerint a név ellenére a GitHub Copilot SDK közvetlen modellproviderrel is használható, például OpenAI, Azure, Anthropic vagy OpenAI-kompatibilis végpontokkal. Ehhez saját baseUrl és apiKey, vagy bearer token adható át egy provider vagy ProviderConfig segítségével. A GitHub azt is írja, hogy ehhez nincs szükség Copilot-előfizetésre, miközben a bemutatott mintaalkalmazás előfeltételei között egy aktív Copilot-előfizetéssel rendelkező GitHub-fiók is szerepel.

Maven-függőség és futtatható Jakarta EE 11 minta

Az SDK Maven-függőségként érhető el, a forrásban szereplő verzió a 1.0.7-preview.1. A bejegyzés előfeltételként JDK 17 vagy 25 környezetet ad meg, a 25-öst ajánlva a virtuális szálak és más modern funkciók miatt. Szükséges továbbá Maven 3.9+, egy GitHub-fiók aktív Copilot-előfizetéssel, valamint helyben telepített Copilot CLI 1.0.71 vagy újabb verzió.

A GitHub egy teljes mintaalkalmazáson mutatja be az SDK-t. A demó Jakarta EE 11-re épül, a szerző indoklása szerint azért, mert ő volt ennek a kiadásnak a vezető release koordinátora, és hisz abban, hogy a nyílt szabványok adják a legjobb módot a fejlesztők támogatására.

A minta futtatásához a GitHub a következő repository klónozását adja meg: microsoft/Build26-BRK206-your-agent-anywhere-multiclient-multidevice-with-github-copilot-sdk. A Java demó futtatókörnyezete Open Liberty 26.0.0.5, platformja Jakarta EE 11, ezen belül Faces 4.1, CDI 4.1, WebSocket 2.2, Data 1.0 és Persistence 3.2. A felület PrimeFaces 15.0.16, az AI-orkesztráció Copilot SDK for Java 1.0.7-preview.1, az adatbázis pedig memóriabeli H2, 10 előre betöltött ingatlanhirdetéssel.

Ingatlanos agent pipeline a bemutatóban

A mintaalkalmazás egy ingatlanos érdeklődéseket kezelő agent pipeline. A felhasználó például ilyen kérést adhat be: „I’m looking for a 3-bedroom house in London under £800,000”. A rendszer ezután egy elkülönített Copilot Agentet indít virtuális szálon, és a kérést feldolgozza a pipeline lépésein keresztül.

Az architektúra Jakarta WebSocketet használ arra, hogy a szerver valós idejű állapotfrissítéseket küldjön a böngészőnek. Így a felhasználó követheti, ahogy az agent fázisokon halad át, miközben a modell eszközöket hív meg.

A GitHub azt is javasolja, hogy a fejlesztők több érdeklődést küldjenek be egyszerre, mert így láthatóvá válik a virtuális szálakon futó párhuzamos agentek működése. A bejegyzés szerint mindegyik érdeklődés önállóan dolgozódik fel, saját Copilot munkamenettel.

Annotációk, lambda eszközök és rendszerüzenet-testreszabás

Az SDK egyik fő API-ja a @CopilotTool annotáció. Ezzel egy Java metódus olyan eszközként deklarálható, amelyet a modell meghívhat. A paramétereket a @CopilotToolParam annotáció írja le, hogy a modell tudja, milyen adatot kell átadnia. A GitHub szerint az SDK kezeli a JSON Schema generálását, az argumentumok feldolgozását és a meghívás továbbítását.

Az annotációalapú eszköz API jelenleg kísérleti funkcióként szerepel a bejegyzésben. A Maven buildben ezért engedélyezni kell a kísérleti API-kat a -Acopilot.experimental.allowed=true compiler argumentummal, és annotation processorként is regisztrálni kell az SDK-t, hogy fordításkor létrejöjjenek a $$CopilotToolMeta osztályok.

Ha egy eszközt közvetlenül a hívás helyén kell megadni, a bejegyzés a ToolDefinition.from(...) lambda stílust mutatja. Az .overridesBuiltInTool(true) beállítás azt jelzi az SDK-nak, hogy az adott eszköz szándékosan felülír egy azonos nevű beépített eszközt. A blog arra is kitér, hogy az eszközök nem feltétlenül ugyanabban az osztályban vannak, mint az agentlogika: a példában a searchProperties egy külön CDI beanben kap helyet.

A rendszerüzenet finomhangolására a SystemMessageMode.CUSTOMIZE szolgál. A példában az IDENTITY szakasz cserélődik ki, miközben a biztonsági korlátok megmaradnak. Egyszerűbb megoldásként a SystemMessageMode.APPEND a meglévő alapértelmezett rendszerüzenet után illeszti be a fejlesztő tartalmát.

Mit jelent ez a Java fejlesztőknek

A bejelentés fő üzenete, hogy a Java fejlesztők meglévő szerveroldali eszköztárukkal építhetnek agent alapú munkafolyamatokat. A GitHub példája Jakarta EE 11-et használ, de a cikk szerint a fejlesztők saját agent harness megoldást is készíthetnek az általuk választott ismert Java frameworkökkel és könyvtárakkal.

A sendAndWait(...) hívás indítja el a teljes agentic loopot: a modell gondolkodik, szükség esetén többször is meghívja a regisztrált eszközöket, majd visszaadja a végső választ. A GitHub szerint virtuális szálon a .get() várakozás olcsó, mert várakozás közben nem foglal platformszálat.

A Java oldali programozhatóság, az annotációkkal leírható eszközök, a lambda alapú eszközdefiníciók és a rendszerüzenetek szakaszokra bontott testreszabása együtt azt célozzák, hogy vállalati Java alkalmazásokból közvetlenül lehessen AI-agent munkameneteket vezérelni. A forrás alapján ez különösen azoknak lehet fontos, akik Jakarta EE vagy Spring környezetben szeretnének eszközhívásokkal dolgozó AI-folyamatokat építeni.