Azul کا AI Assistant چلتی Java estate دیکھے گا، مگر خودکار discovery مکمل نہیں

Azul نے ۲۳ ستمبر ۲۰۲۶ کی بلاگ پوسٹ میں بتایا کہ اس کا Intelligence Cloud AI Assistant اب صارفین کے لیے دستیاب ہے۔ یہ عام زبان میں پوچھے گئے سوالات کے جواب JVM Inventory اور Code Inventory سے لیتا ہے: ایک ریکارڈ منسلک Java runtimes کا ہے اور دوسرا پیداوار میں چلنے والے کوڈ کا۔ AI سے تیار کردہ جوابات فعال کرنے کے لیے موجودہ Intelligence Cloud صارف کو بھی ایک نئے، بلا معاوضہ معاہدے کی ضرورت ہے۔

Cybersecurity Insiders کے شائع کردہ خبرنامے میں بھی اس سہولت کو قدرتی زبان سے runtime ڈیٹا پوچھنے کا طریقہ بتایا گیا ہے۔ سوال پرانی Java تنصیبات، دوبارہ چلنے والے Oracle runtime یا ایسے کوڈ سے متعلق ہو سکتا ہے جو مشاہدے کے دوران نہیں چلا۔ Assistant خود Java ماحول میں تبدیلی نہیں کرتا؛ اس کا جواب پہلے سے جمع شدہ ریکارڈ کی حد میں رہتا ہے۔ شائع شدہ مواد میں صارفین کی آزاد عملی آزمائش کے نتائج نہیں دیے گئے۔

Assistant کے جواب کی بنیاد کیا ہے؟

JVM Inventory اس Java virtual machine کے بارے میں معلومات رکھتی ہے جس کی سرگرمی Intelligence Cloud تک پہنچی ہو۔ کسی مخصوص vendor کے بارے میں پوچھنے پر جواب میں متعلقہ میزبان مشین، runtime کا vendor اور ورژن سامنے آ سکتے ہیں۔ تاریخی ریکارڈ یہ بھی دکھا سکتا ہے کہ کوئی runtime کب چلا تھا۔ اس طرح سوال صرف موجودہ لمحے تک محدود نہیں رہتا، لیکن اس کی وسعت جمع شدہ سرگرمی اور پوچھی گئی مدت سے طے ہوتی ہے۔

Code Inventory دوسری قسم کا ثبوت فراہم کرتی ہے۔ اس کا موضوع مشین پر Java کی تنصیب نہیں بلکہ ایپلی کیشن کے چلنے کے دوران کلاسز اور methods کا استعمال ہے۔ Assistant دونوں ریکارڈز پر سوال و جواب کی ایک تہہ فراہم کرتا ہے؛ سوال لکھنے سے کوئی نامعلوم مشین، غیر منسلک JVM یا اس کا کوڈ خود بخود ریکارڈ میں شامل نہیں ہو جاتا۔ یہی فرق اس کے جواب کو پوری Java estate کی بلاشرط گنتی سمجھنے سے روکتا ہے۔

سوال میں دی گئی حد بھی نتیجہ بدلتی ہے۔ کسی vendor کے ساتھ مدت بتانے سے اس vendor کے دیکھی گئی runtimes مانگی جا سکتی ہیں، جبکہ AppEnv اور namespace بتانے سے کوڈ کا سوال ایک متعین ایپلی کیشن تک محدود ہوتا ہے۔ کمپنی کے پیش کردہ استعمال میں یہ تفصیل جواب کو زیادہ متعلقہ بناتی ہے۔ قدرتی زبان رپورٹ بنانے کی ضرورت کم کر سکتی ہے، مگر مبہم سوال گمشدہ ڈیٹا کی تلافی نہیں کرتا۔

پرانی JVM اور واپس آنے والا Oracle runtime

سلامتی سے متعلق ایک سوال یہ ہے کہ ریکارڈ میں موجود کون سی JVMs تازہ ترین Java updates استعمال نہیں کر رہیں۔ جواب سے متعلقہ runtime کی تلاش شروع ہو سکتی ہے، خصوصاً جب مختلف میزبان مشینوں پر الگ ورژن چل رہے ہوں۔ تاہم پرانا ورژن نظر آنا خود کسی خاص ایپلی کیشن میں قابلِ استحصال کمزوری ثابت نہیں کرتا۔ Assistant runtime کی حالت کے بارے میں معلومات دیتا ہے؛ مخصوص خطرے کا فیصلہ اس سے وسیع تحقیق مانگتا ہے۔

Software asset management کے لیے Oracle Java کی واپسی زیادہ واضح مثال ہے۔ اگر منتقلی کے بعد کوئی Oracle runtime دوبارہ چلے تو تاریخی اور موجودہ سرگرمی سے اس کی جگہ اور وقت پوچھا جا سکتا ہے۔ ایک پرانی deployment، واپس کی گئی تبدیلی یا بھولا ہوا node اس صورت حال کا ممکنہ سبب ہو سکتا ہے، مگر کسی خاص واقعے کا سبب الگ سے معلوم کرنا ہوگا۔ ریکارڈ میں Oracle کا نام آنا بھی بذاتِ خود لائسنس کی خلاف ورزی کا فیصلہ نہیں؛ استعمال اور معاہدے کی شرائط اس فیصلے کا حصہ ہیں۔

یہ سہولت وقفے وقفے سے بننے والی فہرست کے مقابلے میں ایک مختلف منظر دیتی ہے: منسلک runtime دوبارہ فعال ہو تو اس کی نئی سرگرمی ریکارڈ میں آ سکتی ہے۔ اس سے پہلے ہٹائے گئے runtime کی واپسی کا سوال معنی خیز بنتا ہے۔ جواب کی درست تشریح پھر بھی اس بات سے جڑی ہے کہ متعلقہ JVM منسلک تھی، اس کی سرگرمی پہنچی تھی اور سوال نے درست مدت مانگی تھی۔

«غیر استعمال شدہ کوڈ» کا مطلب کیا ہے؟

Code Inventory سے کسی متعین AppEnv اور namespace میں ان packages کے بارے میں پوچھا جا سکتا ہے جہاں مشاہدے کے دوران نہ چلنے والا کوڈ زیادہ دکھائی دیتا ہے۔ کمپنی کی مثال میں Assistant ایسے packages کو ترجیحی ترتیب میں پیش کرتا ہے تاکہ جائزے کا دائرہ چھوٹا ہو۔ یہ نتیجہ source code میں موجود ہر ممکن راستے کی فہرست نہیں؛ اس کی بنیاد پیداوار میں دیکھی گئی execution ہے۔

یہ فرق static analysis سے موازنہ کرتے وقت اہم ہے۔ کوئی method کوڈ میں موجود ہو سکتا ہے مگر منتخب مدت میں نہ چلا ہو۔ اس کے برعکس بعض راستے framework یا dynamic invocation کے ذریعے چلتے ہیں، جنہیں محض متن کی بنیاد پر سمجھنا مشکل ہو سکتا ہے۔ Runtime ریکارڈ اس سوال کا مضبوط جواب دیتا ہے کہ مشاہدے میں کیا چلا؛ یہ اس سے مختلف سوال ہے کہ مستقبل میں کیا چل سکتا ہے۔

کسی class یا method کا مشاہدے میں نہ آنا اسے حذف کرنے کی خودکار اجازت نہیں دیتا۔ موسمی کام، کم استعمال ہونے والا انتظامی راستہ یا ہنگامی عمل منتخب مدت میں فعال نہ ہوا ہو۔ اس لیے «غیر استعمال شدہ» کو ایپلی کیشن، مدت اور جمع شدہ execution ڈیٹا کے ساتھ پڑھنا ضروری ہے۔ Assistant جائزے کی جگہ بتا سکتا ہے، لیکن آئندہ ضرورت یا حذف کرنے کی حفاظت کا قطعی ثبوت فراہم نہیں کرتا۔

خودکار discovery کہاں ختم ہوتی ہے؟

Azul کی JVM Inventory دستاویزات کے مطابق فہرست میں وہ JVMs شامل ہیں جو Azul JVM یا Intelligence Cloud Agent کے ذریعے سروس سے منسلک ہوئی ہوں۔ دستاویز صاف کہتی ہے کہ JVM Inventory غیر استعمال شدہ JVMs کی discovery نہیں کرتی۔ کسی مشین پر نصب مگر نہ چلنے والی Java تنصیب، یا ایسی چلتی JVM جس کی سرگرمی سروس تک نہ پہنچے، Assistant کے دستیاب runtime ریکارڈ سے باہر رہ سکتی ہے۔

یہی منتخب عنوان کی اصل حد ہے۔ «کون سی Java واقعی چلی؟» کا جواب runtime سرگرمی سے مل سکتا ہے؛ «ہر مشین پر کون سی Java نصب ہے؟» کا مکمل جواب اس فہرست سے نہیں ملتا۔ اگر کوئی تنصیب جواب میں نظر نہ آئے تو اس سے یہ نتیجہ نہیں نکلتا کہ اس کی فائلیں مشین سے ہٹ چکی ہیں۔ اسی طرح کسی منسلک JVM کی موجودگی دوسری غیر فعال تنصیبات کی تعداد نہیں بتاتی۔

Azul مسلسل discovery کی بات چلنے والی، منسلک JVMs کے لیے کرتی ہے۔ اسے تمام نصب شدہ مگر بند Java runtimes کی تلاش سمجھنے سے اثاثوں کی گنتی غلط ہو سکتی ہے۔ Assistant کی دستیابی اور اسے فعال کرنے کی شرط واضح ہیں؛ کسی خاص ادارے میں اس کے جواب کی مکمل وسعت اس ادارے کی JVM connectivity، جمع شدہ code execution اور سوال کی حد سے متعین ہوگی۔ غیر استعمال شدہ نصب شدہ JVMs کی خودکار دریافت اس اعلان میں شامل نہیں۔

یہ بھی پڑھیں:

• AI coding agents تیز ہیں، مگر productivity کا سیدھا جواب اب بھی نہیں
• YouTube کے ویوز اب پہلے فریم سے شمار، مگر کمائی پرانا پیمانہ دیکھے گی
• Instinct کی valuation $2.5 ارب، مگر AI assistant ابھی private beta میں ہے