IDE کے بغیر جاوا کو مرتب کرنا اور چلانا

ایک وقت میں reddit.com پر، IDE کے بغیر جاوا کو مرتب کرنا اور چلانا کے عنوان میں ، سوال پوچھا گیا: کیا کوئی ایسی کمانڈ ہے جو جاوا فائلوں کے ایک گروپ کو مرتب کرتی ہے جو ایک پیکج کے اندر ایک الگ فولڈر میں ہے (آئیے اسے bin کہتے ہیں ) ، اور میں نئی ​​کلاس فائلیں شروع کرنے کے بارے میں کیسے جاؤں گا؟ " موضوع کے مصنف، کائیلو لنک ، بتاتے ہیں: "جب میں نے جاوا کا استعمال شروع کیا، تو میں نے اپنے لیے تمام تالیف کرنے کے لیے Eclipse پر انحصار کیا اور صرف کوڈ لکھنے کے بارے میں فکر مند تھا۔" میں نے یہ سوال کئی بار دیکھا ہے، اور درحقیقت یہ مجھے کس چیز نے GPS سسٹم اور IDEs بلاگ پوسٹ کرنے پر آمادہ کیا: اچھا یا برا؟ یہ پوسٹ اس کے بارے میں ہے۔ سادہ ٹیسٹوں کے ساتھ جاوا سیکھنے کے اپنے بلاگ میں، میں نے اس بارے میں لکھا کہ میں کبھی کبھی سادہ ایپلیکیشنز کو لکھنے، بنانے اور چلانے کے لیے سادہ ٹیکسٹ ایڈیٹر اور کمانڈ لائن ٹولز کا استعمال کرنا پسند کرتا ہوں۔ میرے پسندیدہ جاوا IDEs کو کتنا "اوور ہیڈ" درکار ہے اور اس بارے میں ابتدائی فیصلہ کریں کہ کیا فریم ورک کے استعمال سے حاصل ہونے والے فوائد "اوور ہیڈ" کا جواز پیش کرنے کے لیے کافی ہیں یا نہیں۔ زیادہ تر حقیقی ایپلی کیشنز میں، اس میں کوئی شک نہیں کہ VL IDE کی بہت زیادہ قیمت ہے۔ تاہم، سب سے آسان مثال ایپلی کیشنز کے لئے، یہ ہمیشہ کیس نہیں ہے. اس پوسٹ کا باقی حصہ ان حالات کے لیے IDE کے بغیر جاوا کوڈ بنانے اور چلانے کا طریقہ دکھاتا ہے۔

جاوا کوڈ لکھنا اور اس پر عمل کرنا

مثال کو مزید واضح کرنے کے لیے، میں جاوا کی کچھ بہت سادہ کلاسیں استعمال کروں گا جو کہ ایک دوسرے سے مرکب یا وراثت کے ذریعے متعلق ہیں اور اسی پیکیج میں ہیں جسے dustin.examples کہتے ہیں ۔ دو کلاسوں میں ایک فنکشن غائب ہے main؛ تیسری کلاس، Main.java، میں ایک فنکشن ہے mainجو آپ کو یہ دکھانے کی اجازت دیتا ہے کہ IDE کے بغیر کلاس کو کیسے چلایا جائے۔ ذیل میں ان تینوں کلاسوں کا کوڈ ہے: Parent.java

package dustin.examples;

public class Parent
{
   @Override
   public String toString()
   {
      return "I'm the Parent.";
   }
}

بچہ۔جاوا

package dustin.examples;

public class Child extends Parent
{
   @Override
   public String toString()
   {
      return "I'm the Child.";
   }
}

مین۔جاوا

package dustin.examples;

import static java.lang.System.out;

public class Main
{
   private final Parent parent = new Parent();
   private final Child child = new Child();

   public static void main(final String[] arguments)
   {
      final Main instance = new Main();
      out.println(instance.parent);
      out.println(instance.child);
   }
}

مندرجہ ذیل اسکرین شاٹ ان .java کلاسز کے ساتھ ڈائریکٹری کا ڈھانچہ دکھاتا ہے ۔ اسکرین شاٹ سے پتہ چلتا ہے کہ سورس فائلیں ڈائریکٹری کے درجہ بندی میں ہیں جو پیکیج کے نام کی نمائندگی کرتی ہیں ( dustin/examples کیونکہ پیکیج کی معلومات dustin.examples ہے ) اور یہ کہ یہ پیکیج ڈائریکٹری کے درجہ بندی کی عکاسی کرتا ہے۔ ذیلی ڈائرکٹری SRC کے تحت ہے۔ میں نے مرتب کردہ کلاس فائلوں کو رکھنے کے لیے ایک کلاسز سب ڈائرکٹری (جو فی الحال خالی ہے) بھی بنائی ہے تاکہ Javac اس ڈائریکٹری کو اس وقت نہیں بنائے گا جب یہ موجود نہ ہو۔

JAVAC کے ساتھ تعمیر اور جاوا کے ساتھ چل رہا ہے۔

اس سے کوئی فرق نہیں پڑتا ہے کہ جاوا کوڈ (اینٹ، ماون، گریڈل یا IDE) بنانے کے لیے کوئی کون سا طریقہ استعمال کرتا ہے، یہ بالآخر JAVAC پر آتا ہے۔ Oracle/Sun فراہم کردہ JAVAC کمانڈ لائن ٹول میں معیاری آپشنز کو JAVAC -help چلا کر دیکھا جا سکتا ہے اور JAVAC -help -X کو چلا کر اضافی ایکسٹینشن کے اختیارات دیکھے جا سکتے ہیں۔ ان اختیارات کو استعمال کرنے کے طریقے کے بارے میں مزید تفصیلات ونڈوز یا یونکس/لینکس کے لیے JAVAC ٹول دستاویزات میں مل سکتی ہیں۔ جیسا کہ Javac دستاویزات کہتی ہیں، -sourcepath آپشن کو اس ڈائریکٹری کو ظاہر کرنے کے لیے استعمال کیا جا سکتا ہے جس میں سورس فائلیں موجود ہیں۔ اوپر والے اسکرین شاٹ میں دکھائے گئے میری ڈائرکٹری کے ڈھانچے میں، اس کا مطلب یہ ہے کہ، یہ فرض کرتے ہوئے کہ میں C:\Java\examples\javacAndJava\ ڈائریکٹری سے JAVAC کمانڈ چلا رہا ہوں ، مجھے اپنی کمانڈ میں کچھ ایسا ہونا پڑے گا: Javac -sourcepath src SRC\Dustin\مثالیں\*۔ جاوا _ مندرجہ ذیل اسکرین شاٹ اس کے نتائج کو ظاہر کرتا ہے۔ چونکہ ہم نے .class فائلوں کے لیے کوئی ڈائرکٹری متعین نہیں کی تھی ، اس لیے وہ پہلے سے طے شدہ طور پر اسی ڈائرکٹری میں رکھی گئی تھیں جس میں سورس .java فائلیں بنائی گئی تھیں۔ ہم اس صورت حال کو ٹھیک کرنے کے لیے آپشن استعمال کر سکتے ہیں ۔ ہماری کمانڈ اب چلائی جا سکتی ہے، مثال کے طور پر، Javac -sourcepath src -d کلاسز src\Dustin\examples\*۔ مے ور اپ . جیسا کہ پہلے بتایا گیا ہے، منتخب فولڈر (کلاسز) پہلے سے موجود ہونا چاہیے۔ جب ایسا ہوتا ہے تو، کمانڈ .class فائلوں کو مخصوص فولڈر میں رکھے گی جیسا کہ درج ذیل اسکرین شاٹ میں دکھایا گیا ہے۔ مخصوص ڈائریکٹری میں متعلقہ .class فائلوں میں مرتب کردہ جاوا سورس فائلوں کے ساتھ ، ہم ایپلیکیشن کو فوری لانچ مینو کا استعمال کرتے ہوئے لانچ کر سکتے ہیں۔ جاوا کمانڈ لائن ٹول۔ یہ صرف Java -help یا Java ٹولز کے صفحات پر فراہم کردہ ہدایات پر عمل کرکے اور ( یا ) آپشن کے ساتھ .class فائلوں کے مقام کی وضاحت کرکے کیا جاتا ہے۔ کلاسز ڈائرکٹری کی وضاحت کرنے کے لیے دونوں طریقوں کو استعمال کرتے ہوئے .class فائلوں کو کہاں تلاش کرنا ہے درج ذیل اسکرین شاٹ میں دکھایا گیا ہے۔ آخری دلیل اس کلاس کا مکمل (پورا جاوا پیکیج) نام ہے جس کا مین فنکشن ہونا ہے۔ مندرجہ ذیل اسکرین شاٹ میں دکھائے گئے کمانڈز java classes -cp dustin.examples.Main اور java classes -classpath dustin.examples.Main ہیں۔ -d-classpath-cp

چیونٹی کے ساتھ تعمیر اور دوڑنا

آسان ترین Java ایپلیکیشنز کے لیے، بالترتیب ایپلیکیشن بنانے اور چلانے کے لیے JAVAC اور Java کا استعمال کرنا کافی آسان ہے، جیسا کہ ابھی دکھایا گیا ہے۔ چونکہ ایپلیکیشنز قدرے پیچیدہ ہو جاتی ہیں (مثال کے طور پر، ایک سے زیادہ پیکیج/ڈائریکٹری میں موجود کوڈ یا تھرڈ پارٹی لائبریریوں اور فریم ورک پر زیادہ پیچیدہ انحصاری کلاسز)، یہ نقطہ نظر ناقابل برداشت ہو سکتا ہے۔ Apache Ant "بڑے تین" جاوا بنانے والے ٹولز میں سب سے قدیم ہے اور ہزاروں ایپلی کیشنز اور تعیناتیوں میں استعمال ہوتا رہا ہے۔ جیسا کہ میں نے پچھلی بلاگ پوسٹ میں کہا تھا، ایک بہت ہی آسان Ant build فائل بنانا آسان ہے، خاص طور پر اگر یہ کسی ٹیمپلیٹ سے شروع ہوتی ہے جیسا کہ میں نے اس پوسٹ میں بیان کیا ہے۔ درج ذیل کوڈ کی فہرست Ant's build.xml فائل کے لیے ہے ، جس کا استعمال .java فائلوں کو .class فائلوں میں کمپوز کرنے اور پھر کلاس dustin.examples.Main کو چلانے کے لیے کیا جا سکتا ہے جیسا کہ اوپر JAVAC اور Java کے ساتھ کیا گیا تھا۔ build.xml

<?xml version="1.0" encoding="UTF-8"?>
<project name="BuildingSansIDE" default="run" basedir=".">
   <description>Building Simple Java Applications Without An IDE</description>

   <target name="compile"
           description="Compile the Java code.">
      <javac srcdir="src"
             destdir="classes"
             debug="true"
      includeantruntime="false" />
   </target>

   <target name="run" depends="compile"
           description="Run the Java application.">
      <java classname="dustin.examples.Main" fork="true">
         <classpath>
           <pathelement path="classes"/>
         </classpath>
      </java>
   </target>
</project>

میں نے چیونٹی کی خصوصیات کا استعمال نہیں کیا اور عام مقاصد کو شامل نہیں کیا جو میں عام طور پر شامل کرتا ہوں (جیسے "خالص" اور "جاواڈاک") تاکہ اس مثال کو ممکن حد تک آسان بنایا جا سکے اور اسے JAVAC اور Java کا استعمال کرتے ہوئے پچھلی مثال کے قریب رکھا جا سکے۔ . یہ بھی نوٹ کریں کہ میں نے JAVAC Ant ٹاسک کے لیے "debug" کو "true" پر سیٹ کر دیا ہے کیونکہ یہ Ant کی ناکامی کی صورت میں درست نہیں ہے، لیکن JAVAC کے ڈیفالٹ کے ساتھ درست ہے۔ حیرت کی بات نہیں، جاواک ٹاسک اور جاوا اینٹ ٹاسک JAVAC کمانڈ ٹولز اور جاوا سے ملتے جلتے ہیں۔ کیونکہ میں نے پہلے سے طے شدہ نام کا استعمال کیا ہے چیونٹی ایک بلڈ فائل کی توقع کرتی ہے جب اس کی واضح طور پر وضاحت نہیں کی گئی ہے (build.xml) اور اس وجہ سے کہ میں نے "چلائیں" کا ہدف اس تعمیر کے لئے "ڈیفالٹ" کے طور پر فراہم کیا ہے اور اس وجہ سے کہ میں نے "کمپائل" کو بطور انحصار رن شامل کیا ہے۔ "رن" کا ہدف اور چونکہ Ant میرے ماحول کے راستے پر تھا، مجھے کمانڈ لائن پر صرف یہ کرنا تھا کہ Ant کو build.xml فائل کے ساتھ ڈائرکٹری میں ant کی مثال مرتب کرنے اور چلانے کے لیے حاصل کرنا تھا ۔ یہ مندرجہ ذیل اسکرین شاٹ میں دکھایا گیا ہے۔ اگرچہ میں نے Ant کے ساتھ ایک سادہ جاوا ایپلیکیشن کو مرتب کرنے اور چلانے کا مظاہرہ کیا ہے، لیکن میں صرف Ant کے ساتھ کمپائل کرتا ہوں اور جاوا کے ساتھ چلاتا ہوں (یا ایک اسکرپٹ جو جاوا کہتا ہے اگر کلاس پاتھ بھاری ہو)۔

Maven کے ساتھ تعمیر اور چل رہا ہے

اگرچہ چیونٹی جاوا بنانے کا پہلا بنیادی ٹول تھا، اپاچی ماون نے بالآخر اپنی شہرت بڑی حد تک کنونشن پر مبنی کنفیگریشن کو اپنانے اور مشترکہ لائبریری کے ذخیروں کے لیے تعاون کی وجہ سے حاصل کی۔ Maven استعمال کرنا آسان ہے جب کوڈ اور تیار کردہ اشیاء اس کی معیاری ڈائرکٹری لے آؤٹ کی پیروی کرتے ہیں۔ بدقسمتی سے، میری مثال اس ڈائریکٹری ڈھانچے کی پیروی نہیں کرتی ہے، لیکن ماون ہمیں متوقع ڈیفالٹ ڈائریکٹری ڈھانچے کو اوور رائڈ کرنے کی اجازت دیتا ہے۔ ذیل میں Maven POM فائل کے لیے کوڈ کی فہرست ہے جو ماخذ اور ہدف ڈائریکٹریز کی جگہ استعمال ہوتی ہے اور Maven 3.2.1 کا استعمال کرتے ہوئے Maven کی تعمیر کے لیے دیگر کم از کم مطلوبہ عناصر فراہم کرتی ہے۔ pom.xml

<project>
   <modelVersion>4.0.0</modelVersion>
   <groupId>dustin.examples</groupId>
   <artifactId>CompilingAndRunningWithoutIDE</artifactId>
   <version>1</version>

   <build>
      <defaultGoal>compile</defaultGoal>
      <sourceDirectory>src</sourceDirectory>
      <outputDirectory>classes</outputDirectory>
      <finalName>${project.artifactId}-${project.version}</finalName>
   </build>
</project>

چونکہ اوپر دی گئی pom.xml فائل "compile" کے "defaultGoal" کی وضاحت کرتی ہے اور کیونکہ pom.xml فائلیں پہلے سے طے شدہ POM کسٹم ہیں جسے Maven executable (MVN) تلاش کرتا ہے اور کیونکہ Maven انسٹالیشن بن ڈائرکٹری میرے راستے پر ہے، صرف مجھے کلاس فائلوں کو مرتب کرنے کے لیے "MVN" چلانے کی ضرورت ہے جیسا کہ درج ذیل اسکرین شاٹ میں بتایا گیا ہے۔ میں Mvn Exec کمانڈ کا استعمال کرتے ہوئے Maven سے مرتب کردہ ایپلیکیشن بھی چلا سکتا ہوں : Java -Dexec.mainClass = dustin.examples.Main ، جس کا مشاہدہ درج ذیل اسکرین شاٹ میں کیا گیا ہے۔ چیونٹی کی طرح، میں اپنی سادہ جاوا ایپلیکیشن کو چلانے کے لیے ماون کا استعمال نہیں کرتا ہوں، بلکہ اس کے بجائے جاوا کو مرتب شدہ کوڈ پر استعمال کرتا ہوں (یا اسکرپٹ کا استعمال کرتا ہوں جو جاوا کو لمبی کلاسوں پر براہ راست کال کرتا ہے)۔

گریڈل کے ساتھ تعمیر اور چل رہا ہے۔

Gradle تین بڑے جاوا بنانے والے ٹولز میں جدید ترین، جدید ترین، اور سجیلا ہے۔ مجھے کبھی کبھی اس بات کے بارے میں شک ہوتا ہے کہ کیا رجحان ہے، لیکن مجھے گریڈل کے بارے میں پسند کرنے کے لیے بہت سی چیزیں ملی ہیں (XML کی بجائے گرووی میں لکھی گئی، بلٹ ان اینٹ سپورٹ، بلٹ ان آئیوی سپورٹ، کنونشن کے ذریعے کنفیگریشن جو آسان ہے دوبارہ ترتیب دینے کے لیے، ماون ریپوزٹری سپورٹ، اور وغیرہ)۔ مندرجہ ذیل مثال ایک گریڈل کی تعمیر کو ظاہر کرتی ہے جسے ایک سادہ ایپلیکیشن کو مرتب کرنے اور چلانے کے لیے استعمال کیا جا سکتا ہے، جو کہ اس پوسٹ کے لیے بنیادی نمونہ کوڈ ہے۔ میں نے اس موافقت پذیر مثال کو سادہ گریڈل جاوا پلگ ان حسب ضرورت بلاگ پر پیش کیا۔ build.gradle

apply plugin: 'java'
apply plugin: 'application'

// Redefine where Gradle should expect Java source files (*.java)
sourceSets {
    main {
        java {
            srcDirs 'src'
        }
    }
}

// Redefine where .class files are written
sourceSets.main.output.classesDir = file("classes")

// Specify main class to be executed
mainClassName = "dustin.examples.Main"

defaultTasks 'compileJava', 'run'

build.gradle فائل کی پہلی دو لائنیں جاوا پلگ ان اور ایپلیکیشن پلگ ان کے استعمال کی نشاندہی کرتی ہیں، جس کے نتیجے میں فعالیت کا ایک گروپ خود بخود اس تعمیر میں بن جاتا ہے۔ "sourceSets" اور "sourceSets.main.output.classesDir" کی تعریف آپ کو بالترتیب جاوا سورس کوڈ اور مرتب شدہ بائنری کلاسز کے لیے گریڈل پلگ ان کی ڈیفالٹ جاوا ڈائریکٹریز کو اوور رائیڈ کرنے کی اجازت دیتی ہے۔ "MainClassName" آپ کو واضح طور پر یہ بتانے کی اجازت دیتا ہے کہ کس کلاس کے اندر چلنا چاہیے۔ ایپلیکیشن پلگ ان۔ لائن "ڈیفالٹ ٹاسک" ان کاموں کی وضاحت کرتی ہے جو صرف کمانڈ لائن پر "گریڈل" ٹائپ کرنے سے چلیں گے: 'کمپائل جاوا' جاوا پلگ ان کے ذریعہ فراہم کردہ ڈیفالٹ ٹاسک ہے اور 'رن' ایپلیکیشن پلگ ان کے ذریعہ فراہم کردہ ڈیفالٹ ٹاسک ہے۔ کیونکہ میں نے اسمبلیوں کو build.gradle کا نام دیا ہے اور اسی وجہ سے میں نے پہلے سے طے شدہ کاموں کو 'compileJava' اور 'Run' کے طور پر مخصوص کیا ہے اور چونکہ میرے راستے میں گریڈل انسٹالیشن بن ڈائرکٹری موجود ہے، مجھے مثالیں بنانے اور چلانے کے لیے بس ٹائپ کرنا تھا۔ 'گریڈل' اور یہ مندرجہ ذیل اسکرین شاٹ میں ظاہر ہوا ہے۔ یہاں تک کہ سب سے بڑے شکی کو بھی تسلیم کرنا چاہیے کہ اس سادہ مثال کے لیے گریڈل کی تعمیرات بہت پھسلتی ہیں۔ یہ بعض کنونشنوں اور مفروضوں پر انحصار کرنے کی جامعیت کو ایک بہت ہی آسان طریقہ کار کے ساتھ جوڑتا ہے جب ضروری ہو ڈیفالٹس کو اوور رائیڈ کرنے کے لیے۔ حقیقت یہ ہے کہ یہ XML کے بجائے گرووی میں ہے بھی بہت دلکش ہے! جیسا کہ چیونٹی اور ماون کے ساتھ ہے، میں صرف ان ٹولز کے ساتھ بنانے کا رجحان رکھتا ہوں اور جاوا سے براہ راست مرتب شدہ کلاس فائلوں کو چلانے کا رجحان رکھتا ہوں یا اسکرپٹ جو جاوا کو کال کرتا ہے۔ ویسے، میں ان کلاسز کو بھی لانچ کرنے کے لیے ایک جار میں محفوظ کرتا ہوں، لیکن یہ اس مضمون کے دائرہ کار سے باہر ہے۔

نتیجہ

سادہ ایپلیکیشنز اور مثالیں بنانے کے لیے ایک IDE اکثر ضروری نہیں ہوتا ہے اور سادہ مثالیں بنانے میں جو لاگت آتی ہے اس سے بھی زیادہ مہنگی ہو سکتی ہے۔ ایسی صورت میں، براہ راست مثالوں کو بنانے اور چلانے کے لیے JAVAC اور Java کا استعمال کرنا کافی آسان ہے۔ زیادہ شامل ہونے کی مثالوں کے طور پر، ایک تعمیراتی ٹول جیسے کہ چیونٹی، ماون، یا گریڈل زیادہ پرکشش ہو جاتا ہے۔ حقیقت یہ ہے کہ بہت سے ترقیاتی ماحول ان تعمیراتی افادیت کو سپورٹ کرتے ہیں اس کا مطلب یہ ہے کہ ایک ڈویلپر اس عمل میں پہلے بنائے گئے ایک بلٹ ان ٹول کا استعمال کرتے ہوئے IDE میں منتقل ہو سکتا ہے اگر یہ طے کیا گیا ہو کہ IDE سپورٹ کی ضرورت تھی کیونکہ ایک سادہ ایپلیکیشن ایک مکمل پراجیکٹ میں بڑھ گئی تھی۔ .