Qin - AI 鏃朵唬鐨勫叏鏍堝簲鐢ㄨ瑷€

鐢ㄤ竴濂?Qin 浠ｇ爜鎻忚堪搴旂敤锛岃 AI 鍐欎唬鐮侊紝璁?Qin 璐熻矗杩愯銆佹瀯寤哄拰閮ㄧ讲銆?

馃摉 Qin 鏄粈涔堬紵

Qin 鐨勭洰鏍囦笉鏄啀鍋氫竴涓€滄洿鐜颁唬鐨?Java 鏋勫缓宸ュ叿鈥濓紝鑰屾槸鍋氫竴闂?AI-native 鍏ㄦ爤搴旂敤璇█锛?

• 浣跨敤 ESM 椋庢牸璇硶
• 浠?JVM 浣滀负涓昏鍚庣/杩愯鏃跺唴鏍?- 浠ュ墠绔?JS 鐢熸垚涓虹涓€绫荤洰鏍?- 鐢ㄧ粺涓€鐨勮瑷€妯″瀷瑕嗙洊搴旂敤銆侀〉闈€佹帴鍙ｃ€佹暟鎹笌閮ㄧ讲

瀵圭敤鎴风殑鐞嗘兂浣撻獙鏄細

• 鐢?Qin 鎻忚堪搴旂敤
• 鐢?AI 鐢熸垚鎴栦慨鏀?Qin 浠ｇ爜
• qin dev 鏈湴鍚姩
• qin deploy 涓€閿儴缃? 鐢ㄦ埛涓嶉渶瑕佸厛鍏冲績锛?
• 鍓嶇杩樻槸鍚庣
• controller / service / DTO 鎬庝箞鎷?- Spring / JS / 閮ㄧ讲缁嗚妭鎬庝箞鎺? 杩欎簺搴旇閫愭鐢?Qin 缂栬瘧鍣ㄣ€佽繍琛屾椂銆佸伐鍏烽摼鍜屽钩鍙版潵灏佽銆?

褰撳墠鐜板疄涓庢渶缁堢洰鏍?

褰撳墠 Qin 杩樺鍦ㄢ€滀粠璇█/杩愯鏃跺熀纭€璁炬柦璧板悜浜у搧褰㈡€佲€濈殑闃舵锛?

• 鐜板湪宸茬粡鏈夌粺涓€璇█妯″瀷銆丣VM/JS backend銆乣.qin + Spring Boot` demo銆乼arget zoning

• 浣嗘渶缁堝舰鎬佷笉搴旇璁╂櫘閫氱敤鎴烽暱鏈熷仠鐣欏湪鈥滄墜鍐欏墠鍚庣鍒嗗眰 + 瀹夸富澹斥€濈殑宸ヤ綔鏂瑰紡閲? 褰撳墠鎵ц浼樺厛绾э細

• 鍏堟妸 Qin 鍋氭垚涓€闂ㄦ櫘閫氬彲鐢ㄧ殑鍏ㄦ爤璇█

• 鍏堝畬鎴?Stage 1 鐨勮瑷€銆佺紪璇戙€佽繍琛屻€佸叏鏍堥摼璺ǔ瀹氭€?- 鏇撮珮灞傜殑 Qin 搴旂敤鎶借薄鐣欏埌 Stage 2 鍐嶇郴缁熸帹杩? 鏇村畬鏁寸殑浜у搧瀹氫綅瑙侊細

• packages/qin-runtime-core/QIN_APP_MODEL.md

• packages/qin-runtime-core/QIN_MISSION_AND_VALUE.md

• packages/qin-runtime-core/QIN_PRODUCT_POSITIONING.md

• packages/qin-runtime-core/QIN_LANGUAGE_TARGET_MODEL.md

• packages/qin-runtime-core/QIN_JS_COMPATIBILITY_MODEL.md

• packages/qin-runtime-core/QIN_CURRENT_SUPPORT_MATRIX.md

• packages/qin-runtime-core/QIN_NPM_COMPATIBILITY_POLICY.md

• packages/qin-runtime-core/QIN_HOST_CAPABILITY_MODEL.md

• packages/qin-runtime-core/QIN_JS_ON_JVM_FEASIBILITY.md

• packages/qin-runtime-core/QIN_CSSTS_INTEGRATION_MODEL.md

鏍稿績鐞嗗康

鎻忚堪搴旂敤锛岃€屼笉鏄厛鎻忚堪鍓嶇/鍚庣鍒嗗眰

鎴戜滑涓轰粈涔堣鍋?Qin

Qin 鐨勬剰涔変笉鍦ㄤ簬鈥滄妸 JavaScript 鐢?Java 閲嶅啓涓€閬嶁€濄€? 濡傛灉 Qin 鏈€缁堝彧鏄細

• 鎺ヨ繎 JS 鐨勮娉?- 鍐嶅姞涓婅兘璋冪敤 Spring Boot / JVM 鐢熸€? 閭ｅ畠鐨勪环鍊兼槸涓嶅澶х殑銆? Qin 鐪熸瑕佽瘉鏄庣殑浠峰€兼槸锛?
• 鐢?AI 鏇寸啛鎮夌殑鐜颁唬璇硶锛岀粺涓€鏇村鍓嶅悗绔紑鍙戝伐浣?- 鐩存帴杩涘叆 JVM / .class / Spring Boot / Java 鐢熸€?- 闄嶄綆澶氳瑷€銆佸杩愯鏃躲€佸鏋勫缓閾捐矾涔嬮棿鐨勮兌姘村鏉傚害
• 鏈€缁堟妸 dev/build/deploy 鏀舵垚鏇翠竴浣撳寲鐨勫叏鏍堜綋楠? 涔熷氨鏄锛孮in 涓嶆槸涓轰簡鈥滃儚 JS鈥濊€屽瓨鍦ㄣ€?Qin 鍙湁鍦ㄥ畠鑳藉甫鏉ユ洿寮虹殑 JVM-centered fullstack workflow 鏃讹紝鎵嶅€煎緱浣滀负涓€闂ㄧ嫭绔嬭瑷€缁х画鍙戝睍銆?

Qin 瑙ｅ喅鐨勯棶棰?

1. *搴旂敤寮€鍙戜粛鐒惰繃搴﹀垎灞?

   • 鐢ㄦ埛鍏堣杩€濊€冨墠绔€佸悗绔€丏TO銆佽矾鐢便€侀儴缃? - Qin 鐨勭洰鏍囨槸鍏堟弿杩板簲鐢ㄦ剰鍥撅紝鍐嶇敱骞冲彴灞曞紑 target 缁嗚妭

2. *AI 鍐欏簲鐢ㄤ唬鐮佹椂涓婁笅鏂囧お纰?

   • 浼犵粺宸ョ▼闇€瑕佽法澶氫釜妗嗘灦灞傛墜宸ュ榻? - Qin 闇€瑕佹彁渚涙洿缁熶竴銆佷綆姝т箟銆佸彲鐢熸垚鐨勫簲鐢ㄦā鍨?

3. *鍏ㄦ爤寮€鍙戠殑杩愯涓庨儴缃查摼璺繃閲?

   • 鏈湴杩愯銆佷緷璧栨嫾瑁呫€佸涓婚泦鎴愩€佸彂甯冧笂绾块兘鍒嗘暎
   • Qin 鐩爣鏄粺涓€涓?dev/build/deploy

4. 搴曞眰骞冲彴宸紓鏆撮湶杩囨棭

   • JVM銆丣S銆丼pring銆佹祻瑙堝櫒鑳藉姏鏈簲鏄钩鍙板睍寮€闂
   • Qin 鐩爣鏄鏅€氬簲鐢ㄤ綔鑰呭敖閲忛殣钘忚繖浜涘疄鐜扮粏鑺?

鏋勫缓宸ュ叿灞備粛鐒堕噸瑕?

Qin 渚濈劧鍖呭惈寰堝己鐨勫伐绋嬪伐鍏烽摼鑳藉姏锛?

• JSON / TypeScript 椋庢牸閰嶇疆
• 鏈湴渚濊禆涓?monorepo 鏀寔
• Java 25 / JVM 宸ュ叿浣撶郴闆嗘垚
• qin run / sync / build

浣嗚繖浜涘睘浜?Qin 浜у搧鐨勪竴閮ㄥ垎锛屼笉鍐嶆槸 Qin 鐨勬渶楂樺眰瀹氫箟銆?

瀵规瘮绀轰緥

Maven pom.xml (30+ 琛?:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>my-app</artifactId>
    <version>1.0.0</version>
    
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>4.0.6</version>
        </dependency>
    </dependencies>
    
    <repositories>
        <repository>
            <id>central</id>
            <url>https://repo1.maven.org/maven2</url>
        </repository>
    </repositories>
</project>

Qin qin.config.js (10 琛?:

{
  "name": "my-app",
  "version": "1.0.0",
  "dependencies": {
    "org.springframework.boot:spring-boot-starter-web": "4.0.6"
  }
}

Qin 閫傚悎璋侊紵

• 鉁?*鍓嶇杞?Java 寮€鍙戣€? - 鐔熸倝鐨?npm 椋庢牸閰嶇疆
• 鉁?*鍘屽€?XML 鐨?Java 寮€鍙戣€? - 绠€娲佺殑 JSON/TypeScript 閰嶇疆
• 鉁?Monorepo 鐢ㄦ埛 - 鍘熺敓澶氶」鐩敮鎸?
• 鉁?*杩芥眰鎬ц兘鐨勫紑鍙戣€? - Java 25 甯︽潵 2-5x 鎬ц兘鎻愬崌
• 鉁?*鍏ㄦ爤寮€鍙戣€? - 鍐呯疆 Qin 鍘熺敓鍓嶇寮€鍙戞湇鍔″櫒锛屼笉渚濊禆 Vite 瀛愯繘绋?

Qin 璇█瀹氫綅锛堝叏鏍堟柟鍚戯級

Qin 鐨勬牳蹇冨畾浣嶏細

• *Qin = JS/ESM 璇硶椋庢牸鐨勭紪璇戝瀷璇█锛圝VM 鍐呮牳锛?
• 涓嶆槸瀹屾暣 JS 寮曟搸锛屼笉鍏煎 Node 涓撴湁 API
• 鐩爣鏄€滀竴濂楄瑷€鍐欏墠鍚庣鈥濓紝鑰屼笉鏄€滃鍒?Node 鐢熸€佲€?

涓轰粈涔堣鍦?Java 渚у疄鐜?JS-SDK锛堝 console / Math / JSON锛夛細

• Qin 鍚庣鐩爣鏄?.class锛岃繍琛屽湪 JVM锛屼笉鏄洿鎺ヨ窇鍦ㄦ祻瑙堝櫒閲?
• 浣嗚瑷€灞傞噰鐢?JS/ESM 璇硶锛屽紑鍙戣€呭ぉ鐒朵細浣跨敤 JS 鍐呭缓鑳藉姏
• 濡傛灉娌℃湁 JS-SDK锛岃娉曡櫧鐒跺儚 JS锛岃繍琛屾椂琛屼负灏变細鏂眰
• 鍥犳闇€瑕佲€滅紪璇戞湡鏄犲皠 + 杩愯鏃跺疄鐜扳€濈殑 JS-SDK 浣滀负璇█鍩虹璁炬柦

Qin 鐨勫垎灞傝璁★細

1. 璇█灞傦細JS/ESM 璇硶瀛愰泦锛坧arser/AST/璇箟妫€鏌ワ級
2. 杩愯鏃跺眰锛氬钩鍙版棤鍏?JS-SDK锛堝 console / Math / JSON / Object锛?
3. 骞冲彴灞傦紙鍚庣锛夛細JVM 杩愯锛堝彲璋冪敤 Java/JDK 鑳藉姏锛?
4. 骞冲彴灞傦紙鍓嶇锛夛細娴忚鍣ㄨ繍琛岋紙Web 骞冲彴鑳藉姏锛?

璁捐鍘熷垯锛?

• 璇硶灏介噺 JS 涓€鑷达紝璇箟淇濇寔鍙帶瀛愰泦
• 骞冲彴鑳藉姏鍒嗗眰闅旂锛屼笉鎶?Node 瑙勫垯寮鸿甯﹀叆 Qin
• 鍏堜繚璇佸墠鍚庣涓€鑷寸殑寮€鍙戜綋楠岋紝鍐嶉€愭鎵╁睍鏍囧噯搴撹鐩栭潰

馃帀 What's New in Java 25 Version

鉁?鏍稿績鍗囩骇

• Java 25 LTS - 鏈€鏂伴暱鏈熸敮鎸佺増鏈紙鏀寔鍒?2033 骞达級
• Flexible Constructor Bodies (JEP 513) - 閰嶇疆楠岃瘉鏇村畨鍏?
• Module Import Declarations (JEP 511) - 浠ｇ爜鏇寸畝娲?
• Primitive Patterns (JEP 507) - 绫诲瀷瀹夊叏鎬у寮?
• Structured Concurrency (JEP 505) - 骞跺彂鎬ц兘鎻愬崌 3-5x
• AOT Method Profiling (JEP 515) - 鍚姩閫熷害鎻愬崌 2-3x
• Compact Object Headers (JEP 519) - 鍐呭瓨鍗犵敤鍑忓皯 20-30%

馃搳 鎬ц兘鎻愬崌

鎸囨爣	Java 17	Java 25	鎻愬崌
CLI 鍚姩鏃堕棿	800ms	300ms	2.7x 鈿?
骞惰缂栬瘧 (10 鏂囦欢)	5.2s	1.8s	2.9x 馃殌
鍐呭瓨鍗犵敤	180MB	135MB	-25% 馃捑
浠ｇ爜閲?	3500 琛?	2100 琛?	-40% 馃摑

馃殌 蹇€熷紑濮?

鍓嶇疆瑕佹眰

• Java 25 or higher (Download)
• Maven 3.8+ (鍙€夛紝鐢ㄤ簬渚濊禆涓嬭浇)

缂栬瘧 Qin

# Windows
.\build-java.bat

# Linux/macOS
./build-java.sh

杩愯 Qin

# 鏌ョ湅甯姪
java -cp ".qin\classes;lib\gson-2.10.1.jar" com.qin.cli.QinCli help

# 缂栬瘧椤圭洰
java -cp ".qin\classes;lib\gson-2.10.1.jar" com.qin.cli.QinCli compile

# 杩愯椤圭洰
java -cp ".qin\classes;lib\gson-2.10.1.jar" com.qin.cli.QinCli run

鍒涘缓蹇嵎鍛戒护锛堟帹鑽愶級

Windows (PowerShell):

# 娣诲姞鍒?PowerShell Profile
function qin { java -cp "D:\path\to\qin\.qin\classes;D:\path\to\qin\lib\gson-2.10.1.jar" com.qin.cli.QinCli $args }

Linux/macOS (Bash):

# 娣诲姞鍒?~/.bashrc or ~/.zshrc
alias qin='java -cp "/path/to/qin/build/classes:/path/to/qin/lib/gson-2.10.1.jar" com.qin.cli.QinCli'

鐒跺悗灏卞彲浠ョ洿鎺ヤ娇鐢細

qin compile
qin run
qin build

Jite Default Dev Runtime

• New package: packages/qin-plugin-jite
• Dev entry class: com.qin.jite.JiteDevMain
• qin dev now prefers Jite runtime for .js projects
• If qin-plugin-jite is not on classpath, CLI falls back to com.qin.runtime.core.QinFullstackMain --dev

Demo Project

• Path: packages/exmaples/jitedemo
• Dependency: com.qin:qin-plugin-jite
• Run inside demo folder:

qin dev

Open http://localhost:18080.

馃摑 閰嶇疆鏂囦欢

qin.config.js

qin.config.js 鏄?Qin 鐨勯」鐩?manifest銆? 瀹冨綋鍓嶅悓鏃舵壙鎷呭洓绫昏亴璐ｏ細

• 鍖呮竻鍗?- 渚濊禆澹版槑鍏ュ彛
• workspace / module root 鎻忚堪
• runtime / build / entry 閰嶇疆闈? entry 褰撳墠鏀寔锛?
• Qin source entry: .qin銆乣.js銆乣.mjs銆乣.ts`
• Java host entry: .java

qin run 鏃犲弬鏁版椂浼樺厛璇诲彇杩欓噷鐨?entry銆?

{
  "name": "my-app",
  "version": "1.0.0",
  "description": "My awesome Java 25 app",
  "entry": "main/main.qin",
  
  "dependencies": {
    "org.springframework.boot:spring-boot-starter-web": "4.0.6",
    "com.github.ben-manes.caffeine:caffeine": "3.1.8"
  },
  
  "devDependencies": {
    "org.junit.jupiter:junit-jupiter": "5.10.1"
  },
  
  "repositories": [
    {
      "id": "aliyun",
      "url": "https://maven.aliyun.com/repository/public"
    },
    {
      "id": "central",
      "url": "https://repo1.maven.org/maven2"
    }
  ],
  
  "java": {
    "version": "25",
    "sourceDir": "src/main/java",
    "testDir": "src/test/java",
    "outputDir": "target/classes",
    "encoding": "UTF-8"
  },
  
  "output": {
    "dir": "dist",
    "jarName": "my-app.jar",
    "fatJar": true
  }
}

馃洜锔?CLI 鍛戒护

鍛戒护	璇存槑	绀轰緥
compile	缂栬瘧 Java 椤圭洰	qin compile
run	缂栬瘧骞惰繍琛?	qin run / qin run Test.java / qin run main/main.qin
dev	寮€鍙戞ā寮忥紙Qin 鍗曠鍙?+ 鑷姩鍒锋柊锛?	qin dev / qin dev main/main.qin
build	鏋勫缓浜х墿锛圝ava: JAR / Qin: fullstack 浜х墿锛?	qin build / qin build main/main.qin
test	杩愯娴嬭瘯	qin test
sync	鍚屾渚濊禆	qin sync
clean	娓呯悊鏋勫缓浜х墿	qin clean
init	鍒濆鍖栭」鐩?	qin init
env	鐜妫€鏌?	qin env

杩愯鎸囧畾鏂囦欢

# 杩愯椤圭洰鍏ュ彛锛坬in.config.json 涓殑 entry锛?
qin run

# 杩愯鎸囧畾鐨?Java 鏂囦欢
qin run src/main/java/com/example/Test.java

# 杩愯鎸囧畾鐨?Qin 鏂囦欢
qin run main/main.qin

# 杩愯鎸囧畾鏂囦欢骞朵紶閫掑弬鏁?
qin run MyTest.java arg1 arg2

杩愯鍒嗗彂瑙勫垯锛堢粺涓€锛夛細

• 浼犲叆鐩爣鍙傛暟鏃讹細浼樺厛鎻掍欢瑙ｆ瀽锛屽叾娆?.js锛屾渶鍚庢寜 Java 鍏ュ彛澶勭悊銆?

• 涓嶄紶鍙傛暟鏃讹細浼樺厛璇诲彇 qin.config.js 鐨?entry锛涜嫢涓?.qin/.js/.mjs/.ts 璧?Qin 杩愯鏃讹紝鍚﹀垯鎸?Java host 鍏ュ彛澶勭悊銆? run / dev 鍖哄埆锛?

• qin run锛氫竴娆℃瀯寤哄悗鍚姩锛屼笉鐩戝惉鏂囦欢鍙樺寲銆?

• qin dev锛氬崟绔彛寮€鍙戞湇鍔★紙榛樿鍚岀鍙ｆ彁渚?API + 闈欐€侀〉闈級锛岀洃鍚?.js/.html/.css 鍙樻洿骞惰嚜鍔ㄩ噸缂栬瘧涓庢祻瑙堝櫒鍒锋柊銆?

• 璇?MVP 鐨勬牳蹇冮摼璺互 Qin + Java 杩愯鏃朵负涓伙紝鍓嶇鐢?Qin 鍘熺敓 dev server 鍜?Qin frontend pipeline 鎵胯浇锛屼笉閫氳繃 Node/Vite 瀛愯繘绋嬫ˉ鎺ャ€? 鏋勫缓鍒嗗彂瑙勫垯锛堢粺涓€锛夛細

• qin build 鍦ㄦ娴嬪埌 .js 鍏ュ彛鏃讹紝浼氳蛋 Qin fullstack build-only 娴佺▼銆?

• 榛樿杈撳嚭鐩綍锛歚dist/fullstack锛屽叾涓?server-classes/瀛樻斁鍚庣.class锛宍web/ 瀛樻斁鍓嶇鏋勫缓浜х墿锛堝惈 app.js锛夈€?

• 鍙敤 -o/--output 瑕嗙洊杈撳嚭鏍圭洰褰曘€?

馃殌 楂樼骇鐗规€?

1. 澧為噺缂栬瘧

Qin 浣跨敤 *javax.tools API + 鏃堕棿鎴虫瘮杈? 瀹炵幇鏅鸿兘澧為噺缂栬瘧锛?

• 鉁?*鏅鸿兘妫€娴? - 鍙紪璇戜慨鏀硅繃鐨勬枃浠讹紙姣旇緝 .java 鍜?.class 鐨勪慨鏀规椂闂达級
• 鉁?鑷姩渚濊禆 - javac 鑷姩澶勭悊渚濊禆鏂囦欢鐨勭紪璇?
• 鉁?*闆堕厤缃? - 鏃犻渶棰濆閰嶇疆锛屽紑绠卞嵆鐢?
• 鉁?*蹇€熷搷搴? - 鏃犱慨鏀规椂璺宠繃缂栬瘧锛岀珛鍗宠繍琛?

*瀹炵幇鍘熺悊锛?

// 姣旇緝姣忎釜 .java 鏂囦欢鍜屽搴?.class 鏂囦欢鐨勬椂闂存埑
private boolean isModified(String javaFilePath) {
    Path classFile = getClassFilePath(javaFilePath);
    if (!Files.exists(classFile)) return true;
    return Files.getLastModifiedTime(javaFile) > Files.getLastModifiedTime(classFile);
}

// 浣跨敤 javax.tools API 缂栬瘧
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
compiler.getTask(...).call();

*鎬ц兘鎻愬崌锛?

鍦烘櫙	鍏ㄩ噺缂栬瘧	澧為噺缂栬瘧	鎻愬崌
鏃犱慨鏀?	3.2s	0.1s	32x 鈿?
淇敼 1 涓枃浠?	3.2s	0.5s	6.4x 馃殌
淇敼 10 涓枃浠?	3.2s	1.8s	1.8x 鈿?

2. 渚濊禆缂撳瓨鏈哄埗

Qin 鍦ㄦ瘡涓」鐩殑 .qin/classpath.json 涓紦瀛樹緷璧栬В鏋愮粨鏋滐細

{
  "classpath": [
    "D:/project/subhuti-java/build/classes",
    "C:/Users/qinky/.qin/libs/com.google.code.gson/gson-2.10.1/gson-2.10.1.jar"
  ],
  "lastUpdated": "2025-12-30T07:10:32Z"
}

*宸ヤ綔娴佺▼锛?

qin run/sync
  鈫?
妫€鏌?.qin/classpath.json 鏄惁瀛樺湪
  鈫?
姣旇緝缂撳瓨鏃堕棿 vs qin.config.js 淇敼鏃堕棿
  鈫?
缂撳瓨鏈夋晥 鈫?鐩存帴浣跨敤锛堝揩閫熷惎鍔級
缂撳瓨鏃犳晥 鈫?閲嶆柊瑙ｆ瀽渚濊禆骞舵洿鏂扮紦瀛?

*浼樺娍锛?

• 鈿?棣栨杩愯 - 瑙ｆ瀽渚濊禆 + 鐢熸垚缂撳瓨
• 馃殌 鍚庣画杩愯 - 鐩存帴璇荤紦瀛橈紝绉掔骇鍚姩
• 馃攧 鑷姩鍒锋柊 - 淇敼 qin.config.js 鍚庤嚜鍔ㄩ噸鏂拌В鏋?

3. 鏈湴渚濊禆浼樺厛瑙ｆ瀽

Qin 鑷姩鍙戠幇骞朵紭鍏堜娇鐢ㄦ湰鍦伴」鐩緷璧栵紝閬垮厤浠?Maven 涓嬭浇锛?

*鑷姩鍙戠幇绛栫暐锛?

1. 浠庡綋鍓嶇洰褰曞悜涓婃煡鎵炬墍鏈夊寘鍚?qin.config.js 鐨勭洰褰?
2. 鎵弿姣忎釜鐩綍鐨勫悓绾ч」鐩?
3. 鍖归厤渚濊禆鐨?groupId:artifactId
4. 灏辫繎浼樺厛锛堣繎鐨勯」鐩鐩栬繙鐨勫悓鍚嶉」鐩級

*绀轰緥锛?

d:/project/
鈹溾攢鈹€ slime-java/
鈹?  鈹溾攢鈹€ subhuti-java/         # com.subhuti:subhuti-java
鈹?  鈹?  鈹溾攢鈹€ qin.config.js
鈹?  鈹?  鈹斺攢鈹€ build/classes/    鈫?鏈湴渚濊禆璺緞
鈹?  鈹溾攢鈹€ slime-token/          # com.slime:slime-token
鈹?  鈹?  鈹斺攢鈹€ build/classes/
鈹?  鈹斺攢鈹€ slime-parser/         # 渚濊禆涓婇潰涓や釜椤圭洰
鈹?      鈹斺攢鈹€ qin.config.js

鍦?slime-parser 涓細

{
  "dependencies": {
    "com.subhuti:subhuti-java": "1.0.0-SNAPSHOT",
    "com.slime:slime-token": "1.0.0"
  }
}

鎵ц qin sync 杈撳嚭锛?

鈫?Syncing dependencies...
  鈫?Found 2 local dependencies
鉁?Dependencies synced (2 local, 0 remote)
  Cache: .qin/classpath.json

*浼樺娍锛?

• 馃殌 鏃犻渶鍙戝竷 - 鏈湴寮€鍙戞棤闇€鍙戝竷鍒?Maven
• 馃攧 瀹炴椂鏇存柊 - 淇敼渚濊禆椤圭洰绔嬪嵆鐢熸晥
• 馃捑 鑺傜渷甯﹀ - 涓嶄笅杞芥湰鍦板凡鏈夌殑椤圭洰
• 馃幆 Monorepo 鍙嬪ソ - 澶╃劧鏀寔澶氶」鐩伐浣滃尯

4. 渚濊禆瑙ｆ瀽娴佺▼

qin run / qin sync
  鈫?
妫€鏌ヤ緷璧栫紦瀛?(.qin/classpath.json)
  鈫?
[缂撳瓨鏈夋晥]鈹€鈹€鈹€鈹€鈹€鈹€鈹€鈹€鈹€鈹€鈹€鈹€鈹€鈹€鈹€鈹?
  鈫?                    鈫?
[缂撳瓨鏃犳晥]          浣跨敤缂撳瓨
  鈫?                    鈫?
鏈湴渚濊禆瑙ｆ瀽          鐩存帴杩愯
(LocalProjectResolver)
  鈫?
鎵惧埌 鈫?浣跨敤 build/classes 璺緞
鏈壘鍒?鈫?鏍囪涓鸿繙绋嬩緷璧?
  鈫?
杩滅▼渚濊禆瑙ｆ瀽
(DependencyResolver + Coursier)
  鈫?
鍚堝苟鏈湴+杩滅▼ classpath
  鈫?
鍐欏叆 .qin/classpath.json
  鈫?
杩愯绋嬪簭

5. 浠ｇ爜澶嶇敤璁捐

run 鍛戒护鍜?sync 鍛戒护鍏变韩鏍稿績渚濊禆瑙ｆ瀽閫昏緫锛?

// run 鍛戒护
private static void runProject(String[] args) {
    String classpath = ensureDependenciesSynced(config);  // 澶嶇敤
    runner.compileAndRun(classpath);
}

// sync 鍛戒护  
private static void syncDependencies() {
    syncDependenciesCore(config);  // 鏍稿績閫昏緫
}

// 鍏变韩鐨勬牳蹇冮€昏緫
private static String syncDependenciesCore(QinConfig config) {
    // 1. 鏈湴渚濊禆瑙ｆ瀽
    LocalProjectResolver.ResolutionResult localResult = ...;
    
    // 2. 杩滅▼渚濊禆瑙ｆ瀽锛堜粎鏈湪鏈湴鎵惧埌鐨勶級
    if (!localResult.remoteDependencies.isEmpty()) {
        DependencyResolver resolver = ...;
    }
    
    // 3. 鐢熸垚骞剁紦瀛?classpath
    return classpath;
}

6. IDEA 闆嗘垚

Qin 鎻愪緵 IntelliJ IDEA 鎻掍欢锛屽疄鐜?IDE 鏃犵紳闆嗘垚锛?

*鑷姩鍔熻兘锛?

• 鉁?鑷姩鍚屾 - 鎵撳紑椤圭洰鏃惰嚜鍔ㄦ墽琛?qin sync
• 鉁?*搴撻厤缃敓鎴? - 鑷姩鐢熸垚 .idea/libraries/*.xml
• 鉁?缂栬瘧杈撳嚭閰嶇疆 - 鑷姩浣跨敤 build/classes锛堜笌 qin 涓€鑷达級
• 鉁?Monorepo 鏀寔 - 鑷姩鎵弿鎵€鏈夊瓙椤圭洰

*瀹夎锛?

# 鏋勫缓鎻掍欢
cd packages/qin-idea-plugin-debug
./gradlew buildPlugin

# 瀹夎锛欼DEA 鈫?Settings 鈫?Plugins 鈫?鈿欙笍 鈫?Install from Disk
# 閫夋嫨 build/distributions/qin-idea-plugin-debug-x.x.x.zip

*宸ヤ綔鍘熺悊锛?

IDEA 鎵撳紑椤圭洰
     鈫?
鍚戜笂鏌ユ壘 workspace root锛?idea/.vscode/.git锛?
     鈫?
鍚戜笅閫掑綊鎵弿鎵€鏈?qin.config.js锛堟渶澶?5 灞傦級
     鈫?
涓烘瘡涓」鐩墽琛?qin sync
     鈫?
鐢熸垚 .idea/libraries/*.xml
     鈫?
鏇存柊 .iml 鏂囦欢锛堟坊鍔犲簱寮曠敤 + 閰嶇疆杈撳嚭璺緞锛?
     鈫?
鍒锋柊 IDEA 椤圭洰妯″瀷

7. Monorepo 鏀寔

Qin 鍘熺敓鏀寔 Monorepo锛堝崟浠撳簱澶氶」鐩級妯″紡锛?

*鐩綍缁撴瀯锛?

workspace/
鈹溾攢鈹€ .git/
鈹溾攢鈹€ .idea/             # IDEA 椤圭洰鏍囧織
鈹溾攢鈹€ project-a/
鈹?  鈹斺攢鈹€ qin.config.js
鈹溾攢鈹€ project-b/
鈹?  鈹斺攢鈹€ qin.config.js
鈹溾攢鈹€ packages/
鈹?  鈹溾攢鈹€ lib-1/
鈹?  鈹?  鈹斺攢鈹€ qin.config.js
鈹?  鈹斺攢鈹€ lib-2/
鈹?      鈹斺攢鈹€ qin.config.js
鈹斺攢鈹€ apps/
    鈹斺攢鈹€ app-1/
        鈹斺攢鈹€ qin.config.js

*鏈湴渚濊禆瑙ｆ瀽绛栫暐锛?

1. 浠庡綋鍓嶇洰褰曞悜涓婃煡鎵炬墍鏈?qin.config.js
2. 鎵弿鍚岀骇鐩綍鐨勫叾浠栭」鐩?
3. 灏辫繎浼樺厛锛氳繎鐨勯」鐩鐩栬繙鐨勫悓鍚嶉」鐩?

*IDEA 鎻掍欢鎵弿绛栫暐锛?

1. 鍚戜笂鎵惧埌 workspace root锛堟渶椤跺眰鐨?.idea/.vscode/.git 鐩綍锛?
2. 浠?workspace root 鍚戜笅閫掑綊鎵弿鎵€鏈?qin.config.js
3. 涓烘瘡涓彂鐜扮殑椤圭洰鑷姩鎵ц sync

*閰嶇疆绀轰緥锛?

// project-a/qin.config.js
{
  "name": "com.example:project-a",
  "version": "1.0.0",
  "dependencies": {
    "com.example:lib-1": "1.0.0",  // 鑷姩浣跨敤鏈湴 ../packages/lib-1
    "com.example:lib-2": "1.0.0"   // 鑷姩浣跨敤鏈湴 ../packages/lib-2
  }
}

馃幆 Java 25 鐗规€у睍绀?

1. Flexible Constructor Bodies

// 鉁?Java 25 鏂扮壒鎬?
public record QinConfig(String name, String version, Map<String, String> dependencies) {
    public QinConfig {
        // 鍙互鍦?super() 鍓嶉獙璇佸弬鏁帮紒
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("name cannot be blank");
        }
        
        // 鎻愪緵榛樿鍊?
        dependencies = dependencies != null ? Map.copyOf(dependencies) : Map.of();
    }
}

2. Primitive Patterns in Switch

// 鉁?Java 25 - 鍩烘湰绫诲瀷妯″紡鍖归厤
String result = switch (value) {
    case int i when i > 0 -> "positive: " + i;
    case long l -> "long value: " + l;
    case double d -> "double value: " + d;
    default -> "other";
};

3. Structured Concurrency

// 鉁?Java 25 - 缁撴瀯鍖栧苟鍙?
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var task1 = scope.fork(() -> downloadDependency("lib1"));
    var task2 = scope.fork(() -> downloadDependency("lib2"));
    
    scope.join().throwIfFailed();  // 缁熶竴寮傚父澶勭悊
    
    return List.of(task1.get(), task2.get());
}

馃摝 椤圭洰缁撴瀯

鐢ㄦ埛椤圭洰缁撴瀯

my-project/
鈹溾攢鈹€ qin.config.js          # Qin 閰嶇疆
鈹溾攢鈹€ src/
鈹?  鈹溾攢鈹€ main/java/           # 婧愮爜
鈹?  鈹?  鈹斺攢鈹€ com/myapp/
鈹?  鈹?      鈹斺攢鈹€ Main.java
鈹?  鈹斺攢鈹€ test/java/           # 娴嬭瘯
鈹溾攢鈹€ build/
鈹?  鈹斺攢鈹€ classes/             # 缂栬瘧杈撳嚭 (OUTPUT_DIR)
鈹溾攢鈹€ .qin/                    # Qin 閰嶇疆鐩綍
鈹?  鈹溾攢鈹€ classpath.json       # 渚濊禆缂撳瓨 (CLASSPATH_CACHE)
鈹?  鈹斺攢鈹€ libs/                # 鏈湴渚濊禆閾炬帴 (LIBS_DIR)
鈹?      鈹斺攢鈹€ com.google.code.gson/
鈹?          鈹斺攢鈹€ gson-2.10.1/ -> ~/.qin/libs/.../
鈹斺攢鈹€ dist/
    鈹斺攢鈹€ my-app.jar           # Fat JAR

鍏ㄥ眬鐩綍缁撴瀯

~/.qin/
鈹斺攢鈹€ libs/                    # 鍏ㄥ眬渚濊禆缂撳瓨 (GLOBAL_LIBS_DIR)
    鈹斺攢鈹€ com.google.code.gson/
        鈹斺攢鈹€ gson-2.10.1/
            鈹斺攢鈹€ gson-2.10.1.jar

璺緞甯搁噺閰嶇疆 (QinPaths.java)

甯搁噺	鍊?	璇存槑
OUTPUT_DIR	build/classes	缂栬瘧杈撳嚭鐩綍
QIN_DIR	.qin	Qin閰嶇疆鐩綍
CLASSPATH_CACHE	.qin/classpath.json	渚濊禆缂撳瓨鏂囦欢
LIBS_DIR	.qin/libs	渚濊禆搴撶洰褰?

馃敡 寮€鍙?

椤圭洰缁撴瀯

qin/
鈹溾攢鈹€ src/java-rewrite/        # Java 25 婧愮爜
鈹?  鈹斺攢鈹€ com/qin/
鈹?      鈹溾攢鈹€ types/           # 閰嶇疆绫诲瀷锛圧ecords锛?
鈹?      鈹溾攢鈹€ core/            # 鏍稿績妯″潡
鈹?      鈹溾攢鈹€ commands/        # 鍛戒护瀹炵幇
鈹?      鈹溾攢鈹€ cli/             # CLI 鍏ュ彛
鈹?      鈹斺攢鈹€ java/            # Java 宸ュ叿
鈹溾攢鈹€ .qin/
鈹?  鈹斺攢鈹€ classes/             # 缂栬瘧杈撳嚭
鈹溾攢鈹€ lib/
鈹?  鈹斺攢鈹€ gson-2.10.1.jar      # 鍞竴渚濊禆
鈹斺攢鈹€ build-java.bat           # 鏋勫缓鑴氭湰

鏍稿績妯″潡鏋舵瀯

1. 璺緞绠＄悊 - QinPaths.java

鍔熻兘: 缁熶竴绠＄悊鎵€鏈夎矾寰勫父閲?

public static final String OUTPUT_DIR = "build/classes";
public static final String LIBS_DIR = ".qin/libs";

**涓轰粈涔堥渶瑕?*: 閬垮厤纭紪鐮侊紝缁熶竴璺緞閰嶇疆锛屾柟渚跨淮鎶ゅ拰淇敼

2. 缂栬瘧绯荤粺 - 鑱岃矗鍒嗙璁捐

ClasspathBuilder - classpath鏋勫缓

鍔熻兘: 鏋勫缓缂栬瘧鍜岃繍琛屾椂鐨刢lasspath

• buildCompileClasspath() - 缂栬瘧鏃禼lasspath锛堝寘鍚湰鍦伴」鐩?杩滅▼渚濊禆锛?
• buildRuntimeClasspath() - 杩愯鏃禼lasspath

**涓轰粈涔堥渶瑕?*: classpath鏋勫缓閫昏緫澶嶆潅锛堟湰鍦伴」鐩彂鐜般€佷緷璧栬В鏋愶級锛岀嫭绔嬪嚭鏉ユ彁楂樺彲缁存姢鎬?

Compiler - 缂栬瘧閫昏緫

鍔熻兘: Java婧愭枃浠剁紪璇?

• compile() - 浣跨敤javax.tools API缂栬瘧
• filterModifiedFiles() - 澧為噺缂栬瘧锛堝彧缂栬瘧淇敼鐨勬枃浠讹級
• findJavaFiles() - 鏌ユ壘Java鏂囦欢

**涓轰粈涔堥渶瑕?*: 灏佽澶嶆潅鐨勭紪璇戦€昏緫锛屾敮鎸佸閲忕紪璇戞彁鍗囨€ц兘

ResourceCopier - 璧勬簮澶嶅埗

鍔熻兘: 澶嶅埗璧勬簮鏂囦欢鍒拌緭鍑虹洰褰?

• 鏌ユ壘澶氫釜鍙兘鐨勮祫婧愮洰褰曪紙src/resources, src/main/resources锛?
• 閫掑綊澶嶅埗鐩綍

**涓轰粈涔堥渶瑕?*: 璧勬簮鏂囦欢澶勭悊鏄嫭绔嬬殑鍔熻兘锛屼笌缂栬瘧閫昏緫鍒嗙

Runner - 绋嬪簭杩愯

鍔熻兘: 杩愯缂栬瘧鍚庣殑Java绋嬪簭

• run() - 杩愯鎸囧畾绫?
• runFile() - 杩愯鎸囧畾Java鏂囦欢
• javaFilePathToClassName() - 璺緞杞被鍚?

**涓轰粈涔堥渶瑕?*: 杩愯閫昏緫鐙珛锛屾敮鎸佸绉嶈繍琛屾柟寮?

JavaRunner - 闂ㄩ潰鍗忚皟鍣?

鍔熻兘: 鍗忚皟涓婅堪4涓被锛屾彁渚涚粺涓€鎺ュ彛

public CompileResult compile() {
    // 1. 缂栬瘧渚濊禆
    // 2. 鏌ユ壘Java鏂囦欢
    // 3. 澶嶅埗璧勬簮
    // 4. 澧為噺缂栬瘧
}

**涓轰粈涔堥渶瑕?*: 淇濇寔绠€鍗曠殑璋冪敤鎺ュ彛锛岄殣钘忓唴閮ㄥ鏉傛€?

3. 渚濊禆绠＄悊

LocalProjectResolver - 鏈湴椤圭洰鍙戠幇

鍔熻兘: 鑷姩鍙戠幇鏈湴椤圭洰渚濊禆

• 鍚戜笂鏌ユ壘鎵€鏈塹in.config.json
• 鍖归厤groupId:artifactId
• 灏辫繎浼樺厛

**涓轰粈涔堥渶瑕?*: Monorepo鏀寔锛岄伩鍏嶅彂甯冨埌Maven浠撳簱

DependencyResolver - 杩滅▼渚濊禆瑙ｆ瀽

鍔熻兘: 浣跨敤Coursier瑙ｆ瀽Maven渚濊禆

• 涓嬭浇jar鍒皛/.qin/libs
• 缂撳瓨渚濊禆瑙ｆ瀽缁撴灉

**涓轰粈涔堥渶瑕?*: 鑷姩涓嬭浇鍜岀鐞嗚繙绋嬩緷璧?

4. 閰嶇疆绯荤粺 - types/

浣跨敤Java 25 Records瀹氫箟閰嶇疆绫诲瀷锛?

public record QinConfig(
    String name,
    String version,
    Map<String, String> dependencies
) {}

**涓轰粈涔堥渶瑕?*: 涓嶅彲鍙橀厤缃紝绫诲瀷瀹夊叏锛屼唬鐮佺畝娲?

5. CLI绯荤粺 - QinCli.java

鍔熻兘: 鍛戒护琛屽叆鍙ｏ紝瑙ｆ瀽鍛戒护鍜屽弬鏁?

qin compile 鈫?CompileCommand
qin run     鈫?RunCommand
qin build   鈫?BuildCommand

**涓轰粈涔堥渶瑕?*: 缁熶竴鐨勫懡浠よ鎺ュ彛锛岀敤鎴峰弸濂?

---

璁捐鍘熷垯

1. 鑱岃矗鍗曚竴: 姣忎釜绫诲彧璐熻矗涓€浠朵簨
2. 渚濊禆娉ㄥ叆: 閫氳繃鏋勯€犲嚱鏁颁紶閫掍緷璧?
3. 闈㈠悜鎺ュ彛: 浣跨敤鎶借薄绫诲瀷锛屼究浜庢祴璇曞拰鎵╁睍
4. 甯搁噺绠＄悊: 鎵€鏈夎矾寰勯€氳繃QinPaths缁熶竴绠＄悊

### 缂栬瘧

```bash
# 缂栬瘧 Qin 鏈韩
.\build-java.bat

# 杈撳嚭锛歜uild/classes/

娴嬭瘯

# 浣跨敤 Qin 缂栬瘧娴嬭瘯椤圭洰
cd examples/hello-java
..\..\qin.bat compile
..\..\qin.bat run

馃専 鐗规€?

鉁?鏍稿績鍔熻兘

• JSON 閰嶇疆 - 鍛婂埆 XML锛屾嫢鎶?JSON
• 渚濊禆绠＄悊 - npm 椋庢牸鐨勪緷璧栬娉?
• 澧為噺缂栬瘧 - javax.tools API + 鏃堕棿鎴筹紝32x 鎬ц兘鎻愬崌
• 渚濊禆缂撳瓨 - .qin/classpath.json 鑷姩缂撳瓨锛岀绾у惎鍔?
• 鏈湴渚濊禆浼樺厛 - 鑷姩鍙戠幇鏈湴椤圭洰锛屾棤闇€鍙戝竷鍒?Maven
• Fat JAR 鏋勫缓 - 涓€閿敓鎴愬彲鎵ц JAR
• 杩愯鎸囧畾鏂囦欢 - qin run Test.java / qin run main/main.qin
• 骞惰缂栬瘧 - Virtual Threads 鍔犻€?
• *鐑噸杞? - 寮€鍙戞ā寮忚嚜鍔ㄩ噸鏂扮紪璇?
• Monorepo 鏀寔 - 澶氶」鐩鐞?

鉁?Java 25 浼樺寲

• Records 浠ｆ浛 POJO - 浠ｇ爜鍑忓皯 60%
• Flexible Constructors - 鏇村畨鍏ㄧ殑楠岃瘉
• Pattern Matching - 鏇翠紭闆呯殑绫诲瀷澶勭悊
• Virtual Threads - 3-5x 骞跺彂鎬ц兘
• Structured Concurrency - 鏇村彲闈犵殑寮傛
• AOT Profiling - 2-3x 鍚姩閫熷害
• Compact Headers - 20-30% 鍐呭瓨鑺傜渷

馃摎 鏂囨。

• Java 25 閲嶅啓璁″垝
• [Java 25 鐗规€ц瑙(./docs/JAVA25_FEATURES.md)
• [閰嶇疆鍙傝€僝(./docs/CONFIG_REFERENCE.md)
• [鎻掍欢寮€鍙慮(./docs/PLUGIN_DEVELOPMENT.md)

馃 璐＄尞

娆㈣繋璐＄尞浠ｇ爜銆佹姤鍛?Bug 鎴栨彁鍑哄缓璁紒

馃搫 License

MIT License - 鏌ョ湅 LICENSE 鏂囦欢

---

Built with 鉂わ笍 using Java 25
Powered by Flexible Constructors, Virtual Threads, and Structured Concurrency

Qin Language Positioning (v0.2)

Qin is an ESM-first language/runtime implemented on Java/JVM. It is designed as a new language platform, not a Node.js compatibility layer.

More precisely:

• Qin borrows ESM as a source-language and module-design inspiration.
• Qin does not treat Node.js as its platform standard.
• Qin defines its own runtime boundary on top of Java/JVM.

Official Project Positioning

Qin should be understood as:

• a Qin-owned programming language
• whose source experience is based on ESM / modern JavaScript-style syntax
• with Qin-specific syntax and semantic extensions
• with JVM as the primary backend/runtime kernel
• with fullstack targets across frontend and backend

In practical terms:

• backend Qin code compiles to JVM .class
• frontend Qin code can compile to JS for web targets
• Java is the host platform and ecosystem carrier
• Qin is the business language, not "Java source with different syntax"

So the most accurate short definition is:

• Qin is a fullstack, ESM-style, JVM language.

Design Direction (Current)

• ESM-first: Qin source uses ES-style syntax and ESM import/export as the primary module model.
• Java/JVM kernel: backend compiles to JVM .class (and can also emit JS for web targets).
• Mixed-source Qin input: Qin accepts .ts, .js, and .qin in the same workspace graph.
• .java remains host/interoperability code for backend projects, not a Qin source suffix.
• Node compatibility is optional and incremental: it is a compatibility layer for third-party packages, not the platform definition.
• Java-backed stdlib: runtime capabilities are implemented on top of Java standard library.
• Fullstack orientation: one language across shared/, frontend, and backend, with target-specific backends.
• Qin-owned standard: language/runtime semantics are defined by Qin itself, while Node-adjacent behavior can be added when needed.

Backend architecture note:

• Qin user-facing application model is documented in packages/qin-runtime-core/QIN_APP_MODEL.md.
• Qin server-side code is intended to stand on JVM + .class ecosystem support.
• Node is not the backend foundation of Qin.
• Parsing ownership should belong to a Qin-owned parser layer (qin-parser) built on top of shared java-slime infrastructure.
• Qin language/target zoning is documented in packages/qin-runtime-core/QIN_LANGUAGE_TARGET_MODEL.md.
• JS/TS compatibility boundary is documented in packages/qin-runtime-core/QIN_JS_COMPATIBILITY_MODEL.md.
• npm compatibility grading is documented in packages/qin-runtime-core/QIN_NPM_COMPATIBILITY_POLICY.md.
• host/runtime capability boundary is documented in packages/qin-runtime-core/QIN_HOST_CAPABILITY_MODEL.md.
• JS-on-JVM support priority and deferred-feature policy is documented in packages/qin-runtime-core/QIN_JS_ON_JVM_FEASIBILITY.md.
• Qin frontend lifecycle policy is Qin-owned; Vite can be studied as prior art, but Qin does not use it as a bridge or fallback.
• CSSTS integration policy is documented in packages/qin-runtime-core/QIN_CSSTS_INTEGRATION_MODEL.md.
• See packages/qin-runtime-core/QIN_BACKEND_MODEL.md.
• Builtin object strategy is documented in packages/qin-runtime-core/QIN_BUILTINS_STRATEGY.md.
• Async/concurrency model is documented in packages/qin-runtime-core/QIN_ASYNC_MODEL.md.

Scope and Non-Goals

• Phase 1: selected ES syntax + stable ESM core semantics + Java-backed runtime APIs.
• Phase 1 non-goal: full ECMAScript and full ESM edge-case compatibility.
• Phase 1 non-goal: pretending Node compatibility is the platform standard.
• Reason: this is an engineering phasing strategy, not a JVM limitation. We prioritize a stable core first, then expand compatibility incrementally where real packages require it.

Qin vs JS Runtime / Bun / Kotlin

Dimension	Browser/Node JS	Bun	Kotlin/JVM	Qin
Source language	JavaScript / TypeScript	JavaScript / TypeScript	Kotlin	ESM-style Qin
Primary goal	Run JS	Run JS faster and provide toolchain	Modern JVM language	Modern ESM-style JVM language
Runtime foundation	JS engine + host runtime	JavaScriptCore + Zig host runtime	JVM	JVM
Backend ecosystem	Node/npm	Node/npm	.class / Java ecosystem	.class / Java ecosystem
Node compatibility pressure	High	High	None	None by default
Output artifact	interpreted / bundled JS	interpreted / bundled JS	.class	.class
Spring integration model	indirect bridges	indirect bridges	native	native target
Language semantics owner	ECMAScript + host	ECMAScript + Bun host	Kotlin	Qin

Operationally:

• Bun is best understood as a JS runtime/toolchain implemented largely in Zig.
• Qin is best understood as an ESM-style source language compiled onto the JVM.
• So Qin is not "Java-written Bun" and not "JVM-hosted Node".
• Qin is closer to "ESM-syntax Kotlin-like language for the JVM" than to a JS engine.

Similar Projects In The Industry

There is no mainstream language today that is exactly the same as Qin.

The closest comparisons are split across different dimensions:

• Kotlin: closest on backend platform strategy
• Scala / Groovy: similar on "new language on JVM" category
• TypeScript: closest on source authoring familiarity
• ClojureScript / ReScript / Elm: similar in "source language compiles to JS" direction
• Bun / Deno / Node: useful comparison targets, but not the same category

Kotlin is closest on backend platform strategy: independent language, compiles to JVM .class, integrates naturally with Spring / Java ecosystem, but it is not ESM-style at the source language level.

Scala / Groovy are close in the "new language on JVM" category: JVM-native backend language position, strong .class ecosystem integration, but not designed around ESM-style fullstack authoring.

TypeScript is closest on source authoring familiarity: modern JS/ESM-style code organization and decorator-oriented developer expectations, but it normally targets JS runtimes rather than JVM .class.

ClojureScript / ReScript / Elm are similar in the "source language compiles to JS" direction, but they are not trying to make JVM .class the primary backend artifact.

Bun / Deno / Node are useful comparison targets mainly for what Qin is not: they are JS runtimes/toolchains, while Qin is a new language platform with its own runtime boundary.

So the best mental model is:

• backend category: closer to Kotlin than to Node
• source-language feel: closer to ESM/TypeScript than to Kotlin syntax
• product shape: a fullstack language with target-specific backends, not a JS runtime clone

What Qin Keeps From ESM, And What It Does Not

Qin intentionally keeps:

• ES-style module authoring with import / export
• modern JS-like expression syntax
• decorators as the source-level annotation model
• familiar builtin names such as console, JSON, Math, Array, Object
• frontend/backend authoring style convergence

Qin intentionally does not promise, at least in the current architecture phase:

• full ECMAScript engine parity
• full Node runtime compatibility
• full prototype-chain edge-case fidelity
• CommonJS behavior
• "any npm package should just run" without adaptation
• browser or Node loader behavior as the definition of correctness
• Promise-first / async-viral programming model for backend code

The design intent is:

• keep the productive parts of ESM authoring experience
• keep Qin semantics stable and documentable
• map backend execution cleanly to JVM + .class
• avoid being trapped by Node compatibility as the platform definition
• preserve Java/Kotlin-like synchronous backend ergonomics by default
• add Node-adjacent compatibility only as an incremental layer when ecosystem pressure makes it worthwhile

Convention Folders (Current Project Rule)

These folders are current normative technical architecture. They are not the final preferred primary end-user mental model for Qin application authoring. See packages/qin-runtime-core/QIN_APP_MODEL.md.

• shared/: shared code and shared contracts
• app/: frontend static assets root (/index resolves to app/index or app/index.html)
• backend entry: Java defaults to src/Main.java (with compatibility candidates), Qin defaults use main/main.qin and other built-in candidates

Import Policy by Zone (Current Rule)

• app/ (frontend): can import JS modules, cannot import java: modules
• main/ (backend): can import java: and JS modules
• shared/ (shared): cannot import java: or JS modules
• Violations fail at compile time with policy error codes

Runtime Package Plan

• Location: qin/packages/qin-runtime-core
• Name: qin-runtime-core
• Purpose: Qin runtime orchestration layer (Java runtime semantics, ES-style syntax)

Why this package

• Keep slime-java parser frontend as shared infrastructure.
• Keep compiler backends (qin-lang-backend-jvm and qin-lang-backend-js) as independent modules.
• Put project-level orchestration (layout conventions, bootstrap CLI) in a dedicated runtime package.

Stage 0 Entry

Use com.qin.runtime.core.QinRuntimeMain to parse .ts, .js, and .qin Qin source inputs through the Qin pipeline and emit .class/.js outputs.

Qin Language Design (Normative)

Qin is a JS/ESM-syntax, JVM-kernel compiled language.

• Qin is not a full JavaScript engine.
• Qin does not aim for Node compatibility.
• Qin does not treat Node semantics as normative for language or runtime behavior.
• Qin uses Class-File API to emit JVM .class artifacts.
• Qin defines its own backend/runtime standard on the JVM.

Module Semantics (Strict Rule)

• ESM-only module model in this phase.
• Supported module syntax baseline: import / export (ESM).
• Not supported as language spec: CommonJS (require, module.exports, exports.*).
• Any accidental CJS behavior seen during experiments is non-normative and not a compatibility promise.
• If source depends on CJS semantics, Qin may fail at parse/semantic/lowering/runtime stages.

Runtime Boundary (Strict Rule)

• Node runtime APIs are out of scope in this phase (process, Buffer, __dirname, fs, path, node:*, etc.).
• qin install can fetch npm packages, but "can install" != "can run".
• Runtime compatibility depends on whether package code stays inside Qin-supported ESM + syntax/runtime subset.
• npm ecosystem behavior is never the normative definition of Qin semantics.

npm Packages As Qin Compile Inputs

Qin should treat npm as a package source, not as the definition of the runtime.

That means:

• compatible npm packages may enter the Qin compile graph
• .ts/.js/.qin package sources may be compiled by Qin
• backend-compatible packages may be lowered into the JVM target and participate in .class outputs
• frontend-compatible packages may be lowered into JS outputs

Important boundary:

• this does not mean every npm package is supported
• support is source-compatibility-based, not registry-based
• packages that depend on CJS, Node-only APIs, native addons, or unsupported JS runtime behavior may still fail by design

So the correct rule is:

• Qin aims to compile compatible npm packages, not to promise blind npm ecosystem parity

Runtime Function Model (No Shim Path)

• Qin runtime uses a single function-construction entrypoint: Global.__qin_make_function__.
• Frontend lowers supported JS function AST into a runtime function definition object, then routes through that entrypoint.
• Runtime decides whether to instantiate:
  • interpreted JS function (AST-driven, generic semantics path), or
  • fallback callable (for unsupported/over-budget shapes).
• This is a structural design, not package-specific behavior:
  • no npm package hardcode,
  • no library shim mapping,
  • no package-name condition branches in parser/lowering/runtime.

Safety guard for large modules:

• Qin applies a lowering budget for runtime function definitions.
• For very large source units, function-model lowering is automatically disabled to prevent JVM bytecode method-size overflow.
• This keeps pipeline stability while preserving the same architecture and entrypoint.

Project zoning rules (compile-time hard rules):

• app/ (frontend): JS/ESM imports allowed, java: imports denied.
• main/ (backend): java: and JS imports allowed.
• shared/: platform-specific imports denied (java: and JS package imports).

Run model:

• qin run without args follows qin.config.js and convention candidates.
• .js entries run through Qin runtime (qin-runtime-core).
• .java entries run through Java compile/run flow.

ESM diagnostics:

• Link and semantic diagnostics: ESM2xxx
• Runtime feature gates: ESM3xxx

Reference implementation details live in:

• packages/qin-lang-module-policy/README.md
• packages/qin-lang-sema-esm/README.md
• packages/qin-runtime-core/README.md

Dependency Install Design (qin install)

qin install now supports mixed dependency sources in one workflow:

1. npm-first resolution (Node-free installer implemented in Java)
2. Maven fallback when npm package cannot be resolved
3. Automatic write-back to qin.config.js

qin.config.js as manifest and module root

qin.config.js should be treated as the canonical Qin project manifest, not only as a loose config file.

In the current architecture it defines:

• project/package identity: name, version, description
• source/runtime entry selection: entry
• dependency surface: dependencies, devDependencies, repositories
• workspace shape: packages
• target/runtime/build knobs: java, graalvm, frontend, output, port

So Qin is converging on one manifest for:

• package identity
• mixed npm + Maven dependency declaration
• workspace package discovery
• module-root and runtime/build coordination

Command behavior (no options)

• qin install <pkg...>

  • For bare package names (for example mitt, lodash-es), Qin tries npm first.
  • If npm cannot resolve that package, Qin falls back to Maven Central lookup.
  • Installed dependencies are recorded into qin.config.js.

• qin install org.example:artifact[:version]

  • Explicit Maven coordinates go directly to Maven resolution.
  • Added to qin.config.js, then resolved by qin sync logic.

• qin install (no package names)

  • Executes install using dependencies already declared in qin.config.js.
  • npm-style entries are installed to node_modules by Qin's Java npm installer.
  • Maven-style entries are resolved using the existing sync pipeline.
  • This is the unified update path for main/ backend JS + Java dependency environment.

qin.config.js dependency shape

• npm dependencies: key is npm package name, value is npm version
  • Example: "mitt": "3.0.1"
• Maven dependencies: key is Maven coordinate (groupId:artifactId), value is Maven version
  • Example: "org.jsoup:jsoup": "1.18.1"

This allows Qin projects to manage npm + Maven dependencies together while keeping runtime constraints explicit (Node APIs are still out of scope unless Qin runtime explicitly supports them).

Dependency vs Runtime Clarification (Normative)

• qin install is a dependency acquisition and lock/write-back workflow.
• Runtime execution still follows Qin language/runtime constraints above (ESM-first, no CJS guarantee, no Node API guarantee).
• If an npm package requires CJS or Node-only APIs, install may succeed but compile/run can still fail by design.
• Package-manager convenience must not be confused with platform compatibility goals.

Notes:

• app/ frontend package behavior is intentionally not changed in this phase.
• main/ backend JS and Java now follow one dependency update entrypoint: qin install.