Technology for Myanmar http://tech4mm.com Our Technology is for Our People Sun, 05 Feb 2012 02:26:43 +0000 en hourly 1 http://wordpress.org/?v=3.3.2 Windows 8 http://tech4mm.com/2012/02/windows-8/ http://tech4mm.com/2012/02/windows-8/#comments Sun, 05 Feb 2012 02:26:43 +0000 MinLwin http://tech4mm.com/?p=366

၂၀၁၂ခုကိုရောက်ပြီ။ ဘာပြောပြော ဒီနှစ်ဟာ ဝင်းဒိုး၈ ထွက်မည့်နှစ်ဖြစ်၏။ စောင့်နေသူလည်း အတော်များမည် ထင်၏။ ဘာလို့လဲဆိုတော့ မိုက်ခရိုဆော့ဖ်က ဝင်းဒိုးကို ၃နှစ်တစ်ကြိမ် မေဂျာ အပ်ဒိတ် လုပ်မည်ဟု အတိအလင်း ပြောထားခဲ့၏။ ဝင်းဒိုး၇ ထွက်ခဲ့တာက ၂၀၀၉ခုနှစ်ဆိုတော့ ဒီနှစ်ထဲမှာ ဝင်းဒိုး၈ ထွက်မည် ဆိုသည်မှာ ကလေးမေးတောင်သိနိုင်၏။ Developing သတင်းများကို ကြည့်ရင်ဖြင့် ပြဿနာမရှိ ဟုထင်ဖွယ်ရာရှိသော်လည်း ကျွှန်တော့်အမြင်ပြောရလျှင်တော့ ကြည့်ရတာ သိပ်ပြီး မခေဟု ထင်သည်။

ဦးစွာ စကယ်ဂျူးကို ကြည့်ပါ။ ဝင်းဒိုး၇တုန်းက ဦးစွာ ၁လပိုင်းတွင်ကျင်းပလေ့ရှိသော CES (Consumer Electronics Show) နှင့် အမှီ ဘီတာဗားရှင်းကို ထုတ်ပြန်ခဲ့ပြီး၊ ၄လပိုင်းနဲ့ ၅လပိုင်းတွင် နမှုနာ ဗားရှင်းကို ထုတ်ပြန်နိုင်ခဲ့၏။ တဖန် ၇လပိုင်းတွင် Developing ပြီးပြီး၊ ၈လပိုင်းတွင် Developer Version ကို ထုတ်ပြန်ခဲ့၏။ ၉လပိုင်းတွင် Volume Licence User အတွက်၊ ၁၀လပိုင်းမှာတော့ Package Version နဲ့ Pre Install Version ကို ထုတ်ပြန်နိုင်ခဲ့ပါသည်။

ဒီတစ်ခေါက်တွင် ၁လပိုင်းတွင်ကျင်းပခဲ့သော CES တွင် ဘီတာဗားရှင်းကို ထုတ်ပြန်နိုင်ခြင်းမရှိခဲ့ပဲ၊ ၂လပိုင်းမှစ၍ ဘီတာဗားရှင်းကို ထုတ်ပြန်မည် ဟုဆိုသည်။ ဤအချက်ကို ကြည့်ခြင်းအားဖြင့် ဝင်းဒိုး၇နှင့် ယှဉ်လျှင် ၁လ၂လ ခန့် နောက်ကျနေပါသည်။ ဤအချက်ကို ကြည့်ခြင်းအားဖြင့် ဝင်းဒိုး၈သည်လည်း ဝင်းဒိုး၇ အတိုင်း စကယ်ဂျူးကို လုပ်ဆောင်နိုင်သည်ထားဦးတော့ Package Ver နဲ့ PreinstallVer ထွက်နိုင်မည်မှာ ၂၀၁၂ခု ၁၂လပိုင်းကို ရောက်သွားမည် ဖြစ်၏။ ပြောရမည်ဆိုလျှင် ၂၀၁၂ရောက်ခါစဖြစ်သော်လည်း၊ ဒီနှစ်အတွင်း ထုတ်ပြန်နိုင်ရန်မှာ တကယ့်ကို အချိန်ပိုမရှိပေ။

ပြန်ကြည့်မည်ဆိုလျှင် ဝင်းဒိုး၈၏ အဓိကတာဝန်ခံဖြစ်သူ Mr. Steven Sinofsky က အရည်အသွေးကို ဦးစားပေးသူဖြစ်သည့်အတွက်၊ အချိန်စာရင်း ဆိုသည်ကို ခေါင်းထဲကို ထည့်မည့်သူမဟုတ်။ သို့ရာတွင် အထွက်နောက်ကျခဲ့သောကြောင့် ဝင်းဒိုး ဗီစတာကြောင့် မက်ခဲ့ရသော အိမ်မက်ဆိုးများကလည်း ပျောက်သေးမည် မဟုတ်သောကြောင့်၊ ဘာပဲပြောပြော ဒီနှစ်အကုန်ကို မှီအောင် ကြိုးစားပြီး ထုတ်မည်ဟု ထင်ရပါသည်။

သို့ရာတွင် ပို၍ စိတ်ထင့်စရာကောင်းသည်မှာ ARM Version Developing ဘက် ဖြစ်ပါသည်။ ဝင်းဒိုး၈ တွင် Internet Explore 10နှင့် ဖိုင်ပမာဏ 18E byteနှင့် 1 Volume တွင် 256 Zbyte ဆိုသည့် ဧရာမအချက်အလက်ခေတ်၏ ဖိုင်စစ္စတမ်အသစ်ကို ထည့်သွင်းမည်ဟူသည့် သတင်းကလည်း အပိုင်းအစရှာ၍မတွေ့ပေ။ ထိုကဲ့သို့ OS အနေဖြင့် ကြိုးပမ်းမှု့မှာလည်း အဓိကကျသော်လည်း Tablet အစရှိသည့် မိုဘိုင်း ကရိယာများ၏ OS အနေဖြင့်လည်း ဦးတည်နေသည်ကို တွေ့ရပါသည်။

Post Personal Computer ခေတ်ဟု ပြောနေသလောက်ပင် ယနေ့တိုင် လုပ်ငန်းသုံး Client စက်များတွင် Personal Computer များက လက်ဝါးကြီးအုပ်ထားရာမှ၊ Android နှင့် iPad များကဲ့သို့ Tablet များလည်း နေရာယူဝင်ရောက်လာခဲ့ပါသည်။ ထို့အတွက် Windows 8 တွင် Client ပတ်ဝင်းကျင်၏ ဈေးကွက်ကို Windows ၏ လက်အောက်သို့ ပြန်လည်သိမ်းသွင်းနိုင်ရန်လည်း တာဝန်ရှိလေသည်။ အဲ့ဒီအတွက် ပြီးခဲ့တဲ့နှစ် CES တွင် Windows 8 အား ARM အာကီတက်ချာသုံး စက်များအတွက်လည်း ထုတ်လုပ်သွားမည် ဖြစ်ကြောင်း ထုတ်ပြန်ခဲ့ခြင်းဖြစ်၏။ ယနေ့တိုင် Windows သုံး Tablet အချို့ကို ထုတ်လုပ်ခဲ့သော်လည်း၊ iPad နှင့် Android Tablet များနှင့် ကွာခြားချက်မှာ၊ ဓာတ်ခဲ၏ အသုံးခံနိုင်ချိန်နှင့်၊ အထူအပါးဖြစ်၏။ Windows သုံး Tablet များမှာ x86 အာကီတက်ချာသုံး CPU များကို အသုံးပြုထားပါသဖြင့်၊ ဓာတ်အားစားပြီး၊ ထူထဲလေ့ရှိ၏။ ထို့အတွက် ဓာတ်ခဲအားစားသက်သာသော ARM အာကီတက်ချာသုံး စက်များတွင် အသုံးပြုနိုင်ရန် လိုအပ်လာခဲ့၏။

သို့ရာတွင် ARM သုံး Windows 8 နှင့်ပတ်သက်၍ ယနေ့တိုင် အသေးစိတ်အချက်အလက်များမှာ ထုတ်ပြန်လာနိုင်ခြင်းမရှိသေးပေ။ အဓိကမှာ ယနေ့တိုင်အသုံးပြုလာခဲ့သော x86 အာကီတက်ချာသုံး ဆော့ဖ်ဝဲများကို ARM သုံး Windows တွင် မည်မျှအသုံးပြုနိုင်မည် ဆိုသည့်အချက်သည် ယနေ့တိုင် ထုတ်ပြန်နိုင်ခြင်း မရှိသေးပေ။

အစပိုင်းတွင်ဖော်ပြခဲ့သည့်အတိုင်း Windows 8 အား 2012 ခုအတွင်း ထုတ်ပြန်နိုင်ရန်မှာ၊ တကယ့်ကို အချိန်မရှိတော့ပေ။ 2012 ခုနှစ်ကတော့ Microsoft ၏ Windows 8 ကို စောင့်ကြည့်သွားချင်ပါသည်။

လေးစားစွာဖြင့်
မင်းလွင်

]]> http://tech4mm.com/2012/02/windows-8/feed/ 0 Java 7 ဖြင့် အနာဂတ်ကို ကြည့်မြင်ခြင်း http://tech4mm.com/2012/01/java-7-%e1%80%96%e1%80%bc%e1%80%84%e1%80%b7%e1%80%ba-%e1%80%a1%e1%80%94%e1%80%ac%e1%80%82%e1%80%90%e1%80%ba%e1%80%80%e1%80%ad%e1%80%af-%e1%80%80%e1%80%bc%e1%80%8a%e1%80%b7%e1%80%ba%e1%80%99%e1%80%bc/ http://tech4mm.com/2012/01/java-7-%e1%80%96%e1%80%bc%e1%80%84%e1%80%b7%e1%80%ba-%e1%80%a1%e1%80%94%e1%80%ac%e1%80%82%e1%80%90%e1%80%ba%e1%80%80%e1%80%ad%e1%80%af-%e1%80%80%e1%80%bc%e1%80%8a%e1%80%b7%e1%80%ba%e1%80%99%e1%80%bc/#comments Wed, 04 Jan 2012 16:27:01 +0000 MinLwin http://tech4mm.com/?p=341

ယနေ့ခေတ် ပရိုဂရမ်မင်းဘာသာရပ် Java သည်၊ လုပ်ငန်းသုံး စစ္စတမ်မှအစ cloud စစ္စတမ် နှင့် စမတ်ဖုန်း အပလီကေးရှင်းတွေအထိ နယ်ပယ်ကျယ်ပြန့်စွာ အသုံးပြုနေသည်ကို တွေ့ရ၏။ နယ်ပယ် တော်တော်များများတွင် အသုံးပြုနေပါ သောကြောင့် ပရိုဂရမ်မာများအတွက် ရင်းနှီးပြီးဖြစ်သော ဘာသာရပ် တစ်ခုဆိုလည်း မှာမယ်မထင်ပါ။

ထို့အပြင် ၂၀၁၁ခုနှစ် ၇လပိုင်းတွင် မထွက်တာ ၅ နှစ်တာကြာပြီဖြစ်သော ဗားရှင်း အသစ်ဖြစ်သော Java 7 ကို လည်းထုတ်ပြန်ခဲ့ပြီး၊ အရင်ကထက်စာလျှင် လွန်စွာမှ အသုံးလွယ်စေခဲ့ပါသည်။ ဤဘလောဂ်တွင် လက်ရှိ Java ၏ အနေအထားနှင့် ဆက်လက်ပြီး မည်ကဲ့သို့ တိုးတက်ပြောင်းလည်းရန် ပြင်ဆင်ထားကြောင်းကို သုံးသပ်လေ့လာသွားပါမည်။

Java သည် ပင်မ ၃ ခုကို အခြေခံ၍ ပြုပြင်ပြောင်းလည်းမှု့များကိုပြုလုပ်နေ၏

ယနေ့တိုင် Java ၏ ပြုပြင်ပြောင်းလည်းမှု့များကို လေ့လာရာတွင် အခြေခံ နယ်မြေ ၃ခုကို အဓိကထား၍ ပြောင်းလည်းလာသည်ကို တွေ့ရ၏။

  1. Java ၏ ဘာသာရပ်ပိုင်းဆိုင်ရာ အသုံးပြုပုံများ
  2. Application Programming Interface (API)
  3. Java ဒြပ်မဲ့စက် (JVM)

ယခုတစ်ခေါက် Java 7 တွင်လည်း အထက်ပါ အခြေခံ ၃ ခုအပေါ်မှုတည်၍ ပြောင်းလည်းလာသည်ကို တွေ့နိုင်ပါသည်။ ဘာသာရပ်ပိုင်းဆိုင်ရာ ပြုပြင်ပြောင်းလည်းမှု့များဖြင့် Java ဘာသာရပ်အား ရေးသားရာတွင် ယခင်ကထက် ပိုမိုလွယ်ကူစေခဲ့ပါသည်။ တဖန် API များအား ပြုပြင်ပြောင်းလည်းမှု့ဖြင့် အပလီကေးရှင်းများအား ပြင်တူအလုပ်လုပ်စေနိုင်သော (Parallel Application) အထောက်အကူဖြစ်စေပါသည်။ Java ဒြပ်မဲ့စက်၏ ပြုပြင်ပြောင်းလည်းမှု့ကြောင့် Java 7 တွင် ဒိုင်းနမစ်ကိန်းရှင် ဘာသာရပ်များဖြစ်ကြသော Ruby၊ Python နှင့် Javascript အစရှိသည့် စကရစ်ဘာသာရပ်များကို အသုံးပြုလာနိုင်ခဲ့၏။

Java ၏ အခက်အခဲများ

Java ဖြင့် ပရိုဂရမ်များကို ရေးသားရာတွင် “ဘာလို့များ ဒီလောက် ကုဒ်တွေ အများကြီးရေစရာ လိုရပါလိမ့်” ဟု တွေမိသူများလည်းရှိပါလိမ့်မည်။ Ruby နှင့် Python ဖြင့် ရေးသားရာတွင် ဒီလောက် ရှုပ်ရှုပ်ရှက်ရှက် ရေးသားစရာမလိုပဲ၊ ရှင်းလင်းစွာရေးသားနိုင်ပြီး၊ Java ကို ရေးရတာ အတော်ရှုပ်တာပဲ” ဟု တွေးမိသူများလည်း နည်းမည်မဟုတ်ပေ။ Java သည် Strong Type ပရိုဂရမ်မင်း ဘာသာရပ် တစ်ခု ဖြစ်သည့် အတွက် အသုံးပြုသော ကိန်းရှင်များအား အတိအကျ သတ်မှတ်နေရခြင်းသည်လည်း Java ဖြင့် ပရိုဂရမ်ကိုရေသားရာတွင် ခက်ခဲရှုပ်ထွေးစေသော အကြောင်းတစ်ခုပင် ဖြစ်၏။

Java သည် ဤကဲ့သို့ ပုံစံများကို အတိအကျ သတ်မှတ်စေခြင်းအားဖြင့်၊ မတိကျမှု့များကြောင့် ဖြစ်ပွားတတ်သော Bugs များကို ကြိုတင် ကာကွယ် နိုင်၏။ ဤသည်မှာ ကွန်ပိုင်းဘာသာရပ်များ၏ ထူးခြားချက် တစ်ခုဖြစ်ပြီး၊ Java ဘာသာရပ်၏ အားသာချက် တစ်ခုလည်း ဖြစ်၏။

သို့ရာတွင် ယနေ့ခေတ် ပရိုဂရမ်မင်း ဘာသာရပ်များသည် လွယ်ကူစွာရေးသားနိုင်ရေးကို အားစိုက်လာခဲ့၏။ လွန်ခဲ့သော လေးငါးနှစ်အတွင်း Ruby ဘာသာရပ်သည် လူသုံးများ ကျော်ကြားလာရခြင်းမှာ Ruby On The Rails Framework ကြောင့်ဟု အပြောများကြ၏။ သို့သော်လည်း၊ Ruby ဘာသာရပ်၏ ရေးသားရ လွယ်ကူခြင်းသည် Ruby အားအသုံးများရခြင်း အဓိက အကြောင်းတစ်ခု ဖြစ်ပါသည်။

ဤသို့ဖြင့် Java အသုံးပြုသူများ အကြားတွင်လည်း လွယ်ကူ ရှင်းလင်းစွာ ရေးသားနိုင်ရေး သည်လည်း Java User များအတွက် လိုအပ်ချက်တစ်ခု ဖြစ်လာပါသည်။ သို့ရာတွင် Java ကဲ့သို့ အသုံးများသော ဘာသာရပ်မျိုးတွင် အသုံးပြုပုံကို လွယ်လင့်တကူ ပြောင်းလည်း၍ မဖြစ်နိုင်ပေ။ Java ကို အသုံးပြုထားသော လက်ရှိ လုပ်ငန်းသုံးစစ္စတမ်များသည် Java ၏ ဘာသာရပ် ပြောင်းလည်းမှု့ကြောင့် မလိုလားအပ်သော ပြဿနာများကို မဖြစ်ပွားစေလိုကြပါ။ အသုံးပြုရလွယ်ကူခြင်းထက် စိတ်ချရခြင်းကို ဦးစားပေးလို ကြ၏။

ဤနည်းအားဖြင့် Java သည် ဘာသာရပ်ပိုင်းဆိုင်ရာ ပြုပြင်ပြောင်းလည်းမှု့များကိ ပြုလုပ်ရာတွင်၊ ယခင်ရှိပြီးသား ဗားရှင်းအဟောင်းများတွင် ပါအသုံးပြုနိုင်စေရန် စီမံနေရပြီး၊ မလိုလားအပ်သော ကုဒ်များဖြင့် ပိုမိုရှုပ်ထွေးစေခြင်းကို ဖြစ်ပွားစေခဲ့ပါသည်။ အထူးသဖြင့် Enterprise ဘက်ပိုင်းဆိုင်ရာ Java သည်၊ အသုံးပြုပုံမှာ ရှုပ်ထွေးများပြား လွန်းပါသဖြင့် နည်းပညာအသစ်များကို ဖြည့်စွက်ရန် မလွယ်ကူခဲ့ပေ။

နောက်ဆုံးတွင် ပြုပြင်ပြောင်းလည်းမှု့ကို လိုလားသူများနှင့်၊ ပြောင်းလည်းမှု့ထက်စာလျှင် လက်ရှိစစ္စတမ်၏ တည်ငြိမ်မှု့ကို ဦးစားပေးလိုသူများကြားတွင် Java သည် ဖြည်းဖြည်းခြင်း ပြုပြင်ပြောင်းလည်းနေသော ပရိုဂရမ်မင်းဘာသာရပ် တစ်ခုဖြစ်လာခဲ့ပါသည်။

လွယ်ကူရှင်းလင်းစွာရေးသားနိုင်ရန် ပြောင်းလည်းမှု့

Java SE 7 ၏ အသစ်ဖြည့်စွက်လာမှု့များကို လေ့လာကြည့်ရှုရာတွင် ရှင်းလင်းစွာရေးသားနိုင်ရေးကို ဦးစားပေးလာသည်ကို တွေ့မြင်နိုင်၏။ ဘာသာရပ်ပိုင်းဆိုင်ရာ Java 7 ၏ ပြုပြင်မှု့များကို Project Coin ဖြင့် ရေးသားနေပြီး Java 7 တွင် ထုတ်ပြန်လာခဲ့သည်မှာ အောက်ပါအတိုင်းဖြစ်၏။

  1. switch ဝါကျတွင် String ကို အသုံးပြုနိုင်ခြင်း
  2. Exception များအား တစ်ပြိုင်နက်တည်း Catch လုပ်နိုင်ခြင်း (Multi Catch)
  3. Resource များအား အလိုအလျှောက် Close လုပ်ပေးနိုင်ခြင်း (try-with-resources)
  4. Generics များ၏ ပုံစံအား ခန့်မှန်းပေးနိုင်ခြင်း (Diamond)
  5. Varargs ကိုအသုံးပြုသော မက်သတ်များအား အသုံးပြုရာ၌ ပြုပြင်ပြောင်းလည်းမှု့
  6. ကိန်းဂဏာန်းများအား ဖော်ပြရာတွင် Underscore ကို ကြားဖြည့်စွက် အသုံးပြုနိုင်ခြင်း

အထက်ပါ ပြောင်းလည်းမှု့များကို ကြည့်ခြင်းအားဖြင့်၊ Java 6 အထိ ရှည်ရှားစွာ ရေးသားရန် လိုအပ်ခဲ့သည်ကို Java 7 တွင် ရှင်းလင်းပြတ်သားစွာ ရေးသားနိုင်မည်ကို ကြည့်မြင်နိုင်ပေသည်။

Project Coin ၏ ပြုပြင်မှု့များအထဲတွင် ကျွှန်တော်သဘောအကျဆုံးမှာ try-with-resources ဖြစ်၏။ အတော်လေးကို အသုံးဝင်သော ပြောင်းလည်းမှု့ တစ်ခုဖြစ်၏။ Java Application များမှ၊ ဖိုင်၊ Stream ၊ ဆိုကက် နှင့် ဒေတာဘေစ်များအား ဆက်သွယ်အသုံးပြုရာတွင် Exception များအား ထိမ်းသိမ်းရန် ရေးသားရသည်မှာ အတော်လေးကို ဦးနှောက်စားလေ့ရှိ၏။ Java အားလေ့လာရာတွင် Stream များအား အသုံးပြုရာတွင် နောက်ဆုံးတွင် မလုပ်မဖြစ် Close လုပ်ရန် သင်ကြားခဲ့ကြရမည် ဖြစ်၏။

Close လုပ်ခြင်းသည် ပြောရလွယ်သလောက် အလုပ်ရှုပ်ပါသည်။ Exception ၏ catch ဝါကျအတွင်းတွင် close ကို ရေးခါမှ၊ တဖန် Exception အတွက် ပြန်ပြီး catch လုပ်နေရပြန်သည်။ တကယ်တမ်း စဉ်းစားကြည့်မည် ဆိုပါက Close လုပ်ခြင်းသည် ရေးသားချင်သော အပလီကေးရှင်းနှင့် ပတ်သက်သောအရာ မဟုတ်ပေ။ ဤကဲ့သို့ မလိုအပ်သော အရာများအတွက် Close တွေရေးရင်း ကုဒ်တွေဟာ ရှုပ်ထွေးပြီး ရှည်လျားသွားတတ်၏။ ထို့အပြင် မှန်မှန်ကန်ကန် Close လုပ်နိုင်ခြင်းမရှိပါက မလိုလားအပ်သော ပြဿနာများလည်း ဖြစ်ပွားနိုင်ပြီး၊ အဆိုဆုံးမှာ အပလီကေးရှင်းဆာဗာ ကိုပင် ပိတ်ပြီးပြန်ရမ်းရန် လိုအပ်တက်ပေသည်။

Java 7 အရောက်တွင် လုပ်ဆောင်ချက်များ ပြီးဆုံးပါက အလိုအလျှောက် Close လုပ်ပေးနိုင်သော အင်တာဖေစ်ကို အသုံးပြုလာခဲ့ပါသည်။ ထိုအင်တာဖေစ်မှာ AutoClosable ပင်ဖြစ်၏။ Resource များကို ဆက်သွယ်အသုံးပြုသော API များသည် AutoClosable အင်တာဖေစ်ကို ပံ့ပိုးလာခဲ့ကြပါသည်။

အထက်ပါ အသုံးပြုပုံမှာ C# ၏ using ဝါကျနှင့် ခပ်ဆင်ဆင်ရှိသည် ဟုထင်ရပါသည်။ ထူးခြားသည်မှာ C# ၏ using သည် Object တစ်ခုကိုသာ သတ်မှတ်ရေးသားနိုင်ပြီး၊ Java 7 တွင်မှု အသုံးပြုလိုသော Object များကို တနေရာတည်းတွင် သတ်မှတ် ရေးသားနိုင်ပါသည်။

နောက်တစ်ခု အသုံးဝင်သည်မှာException များ၏ Multi Catch ပင်ဖြစ်၏။ Exception များအား တစ်နေရာတည်းကပင် စုပေါင်း၍ Catch လုပ်လာနိုင်ပါသည်။ ဤကဲ့သို့ရေးသားနိုင်ခြင်းအားဖြင့် လော့ဂျစ်အတွင်း catch တွေ များစွာရေးသားနေသည်ကို နည်းပါးစေနိုင်ပါသည်။

Diamond ရေးသားပုံနှင့်၊ ကိန်းဂဏာန်းများ၏ ရေးသားပုံ ပြောင်းလည်းမှု့သည်လည်း ဆို့ကုဒ်များကို အမြင်ရှင်းလင်းစေရန် အထောက် အကူဖြစ်စေနိုင်ပါသည်။ တဖန် Varargs ကို အသုံးပြုသော မက်သတ်များအား အသုံးပြုပုံ ပြောင်းလည်းခြင်းသည် ယခင် မက်သတ်များအားခေါ်ယူသည့် နေရာတွင် Warning များကို ဖော်ပြနေရာမှ၊ ခေါ်ယူသည့် နေရာတွင် Warning ကို ပြောင်းလည်းစေခြင်းဖြစ်ပြီး၊ ယနေ့တိုင် ဟိုနေရာဒီနေရာ အမှားများဖော်ပြနေရာမှ၊ တစ်နေရာတည်းတွင် ဖော်ပြခြင်းအားဖြင့် ပြုပြင်စေလိုသည့်နေရာကို တိုက်ရိုက်ရှာဖွေသိရှိ စေပါသည်။

နောက်ဆုံးတွင် Java 7 ၏ ဘာသာရပ်ပိုင်းဆိုင်ရာ ပြောင်းလည်းချက်များအား သုံးသပ်ကြည့်ရာတွင် အဓိကအားဖြင့် ဆို့ကုဒ်များကို ရှင်းလင်းလွယ်ကူစွာ ရေးသားနိုင်ရေးဘက်ကို အားစိုက်လာသည်ဟု တွေ့မြင်နိုင်ပါသည်။

API အသစ်နှင့် Frameworks များ

Java ၏ ဒုတိယမြောက် ပင်မအစိတ်အပိုင်းတစ်ခုဖြစ်သော၊ API နှင့် ပတ်သက်၍ ဆက်လက် လေ့လာသွားပါမည်။

ဖိုင် API အသစ်

ဤတစ်ခေါက် ဖြည့်စွက်လာခဲ့သော File API အသစ်သည် Java အသုံးပြုသူများအတွက် အားရဖွယ်ဖန်ရှင်များဖြင့် အားဖြည့်လာခဲ့သည်ကို တွေ့ရမည် ဖြစ်သည်။ အထက်ပါ API ကို NIO2 ဟု ခေါ်ဆိုပါသည်။ NIO2 သည် J2SE 1.4 တွင် ထုတ်ပြန်ခဲ့သည် NIO ၏ နောက်ဆက်တွဲ API ဖြစ်သည်ဟု ဆိုနိုင်ပြီး၊ Input Output များနှင့် ပတ်သက်သော API များကို စုစည်းထားသော API အသစ်တစ်ခု ဖြစ်ပါသည်။

ယနေ့တိုင် အသုံးပြုခဲ့ကြသော Java ၏ File IO သည် လွန်စွာမှ သုံးရခက်ခဲခဲ့၏။ ထို့အပြင် အသုံးလိုသည့်ဖန်ရှင်များလည်း သုံး၍မရခဲ့ပေ။ NIO2 မှာတော့ ဖိုင်နှင့် Directory များ၏ အမည်ကိုပြောင်းလည်းနိုင်သော၊ တဖန် ပိုင်ဆိုင်မှု့ အချက်အလက်များကို ရယူနိုင်သော API ကို ဖြည့်စွက်လာပြီး၊ ဖိုင်နှင့် Directory ကို အသုံးပြုသည့် API အသစ်များကိုလည်း ဖြည့်စွက်လာခဲ့၏။

  • ဖိုင်နှင့် Directory များ၏ နေရာကို ဖော်ပြနိုင်သော Path အင်တာဖေစ်
  • ဖိုင်နှင့်Path များအား ကိုးကားနိုင်သော FileReference/PathReference အင်တာဖေစ်
  • ဖိုင်များကို အသုံးပြုနင်သော Files ကလပ်စ်
  • ဖိုင်များအား ပြုပြင်ပြောင်းလည်းခြင်းကို သိရှိနိုင်သော WatchService အင်တာဖေစ်

Fork And Join Framework

ယခုတစ်ခေါက် ဖြည့်စွက်လာသည့် အရာထဲတွင် စိတ်ဝင်စားစရာကောင်းသည်မှာ Fork and Join Framework လည်း အပါအဝင်ဖြစ်၏။ လေးလံသော အလုပ်များအား၊ အသေးစိတ်ခွဲခြားရင်း၊ အပြိုင်အလုပ်လုပ်စေခြင်း ဖြစ်၏။

ယနေ့ခေတ် CPU များ၏ အာကီတက်ချာသည် CPU တစ်ခုအတွင်းတွင် Multi Core ကို အသုံးပြုလာသည်နှင့် အမျှ၊ ထို Core များအားလုံး၏ စွမ်းအားကို အပြည့်အဝအသုံးပြုနိုင်စေရန် Parallel Processing အပလီကေးရှင်းများသည် အာရုံစိုက်စရာ အချက်များဖြစ်လာခဲ့၏။ Fork and Join Framework ကို အသုံးပြုခြင်းအားဖြင့်၊ Parallel Processing အပလီကေးရှင်းများကို လွယ်ကူစွာ အသုံးပြုလာနိုင် ပါသည်။

Fork and Join Framework ကို အသုံးပြုရန် အတွက် Task များကို အသေးစိတ်ခွဲချမ်းရန် လိုအပ်၏။ သို့ရာတွင် ယနေ့တိုင်းရေးသားပုံအတိုင်း Task များအား ခွဲစိတ်ပါက ရေးသားပုံမှာ ရှုပ်ထွေးသွားလေ့ရှိ၏။ ထိုအတွက် Java 7 တွင် ထုတ်ပြန်ရန် စီစဉ်ခဲ့သော်လည်း၊ အကြောင်းကြောင်းကြောင့် Java 8 ဆီသို့ ရောက်ရှိသွားသော closure ရေးသားပုံစနစ်ကို အသုံးပြုပါက ရှင်းလင်းစွာရေးသားနိုင် လိမ့်မည် ဖြစ်၏။

Fork and Join ၏ အနှစ်သာရကို အပြည့်အဝ အသုံးပြုနိုင်ရန်မှာ 64 bit OS နှင့် Multi Core CPU ကို မရှိမဖြစ်လိုအပ်ပြီး၊ Java 8 ၏ Closure ကို အသုံးပြုနိုင်ပါမှ ပြီးပြည့်စုံမည်ဟု ဆိုနိုင်ပေမည်။

Closure ရေးသားပုံနှင့် Fork and Join အကြောင်းကို နောက်အခန်းဆက်များဖြင့် ဆက်လက်၍ ဖော်ပြသွားပါဦးမည်။

Script ဘာသာရပ်များလည်း Java ဒြပ်မဲ့စက်ပေါ်တွင်

ဆက်လက်၍ Java ဒြပ်မဲ့စက်၏ ပြောင်းလည်းချက်များကို ဆက်လက်၍ လေ့လာသွားပါမည်။ Java 6 မှစ၍ Java ဒြပ်မဲ့စက် အပေါ်တွင် Java ဘာသာရပ်ဖြင့် ရေးသားထားသော ပရိုဂရမ်များသာမက၊ အခြားသော Script ဘာသာရပ်ဖြင့် ရေးသားထားသော ပရိုဂရမ်များကိုလည်း အလုပ်လုပ်စေနိုင် ပါသည်။ Java ဒြပ်မဲ့စက် တစ်ခုတည်းအပေါ်တွင် အလုပ်လုပ်နေခြင်းကြောင့်၊ Java အပလီကေးရှင်းများနှင့်၊ Script အပလီကေးရှင်းများ အကြားတွင် အပြန်အလှန် ဆက်သွယ် အသုံးပြုလာနိုင်ခဲ့၏။ ဥပမာအားဖြင့် JRuby ဘာသာရပ်ကို အသုံးပြုခြင်းအားဖြင့်၊ Java နှင့် Ruby ကုဒ်များကြားတွင် အပြန်အလှန် ခေါ်ယူ အသုံးပြုနိုင်ပါသည်။

သို့ရာတွင် Java သည် ကွန်ပိုင်းလုပ်စရာလိုသော Strong Type Language တစ်ခုဖြစ်ပြီး၊ Ruby နှင့် Python အစရှိသည့် Script ဘာသာရပ်များသည် ကွန်ပိုင်းလုပ်စရာ မလိုအပ်သော Dynamic Type ဘာသာရပ်များ ဖြစ်ကြ၏။ အဆိုပါ ဘာသာရပ်များသည် အလုပ်စလုပ်သည့် အချိန်အထိ Type ကို မသိရှိနိုင်ပဲ၊ Java ဒြပ်မဲ့စက်ပေါ်တွင် အလုပ်လုပ်စေရာတွင် အလိုအလျှောက် ပုံစံကို သတ်မှတ်ပေးနိုင်သော မက်သတ်ကို ခေါ်ယူရန်လိုအပ်ခဲ့၏။ လက်ရှိတွင်မှု အထက်ပါ Script ဘာသာရပ်များအား Java ဒြပ်မဲ့စက်အပေါ်တွင် အလုပ်လုပ်စေနိုင်ရန် Ruby ဆိုပါက JRuby၊ Python ဆိုပါက Jython အစရှိသည့် အင်တာပရက်တာများကိ အသုံးပြုရန် လိုအပ်ခဲ့၏။

အဆိုပါ အင်တာပရက်တာများကြောင့် Java နှင့် အခြားသော Script ဘာသာရပ်များကြားတွင် အပြန်အလှန် မက်သတ်များကို ခေါ်ယူအသုံးပြုနိုင်ခဲ့ပါသဖြင့်၊ အစဉ်ပြေသရောင်ရှိခဲ့၏။ သို့ရာတွင် အစဉ်ပြေသည်မှာ ရှိသော်လည်း Performance ပိုင်းဆိုင်ရာတွင် သဘာဝဘာသာရပ်တွေနဲ့ စာလျှင် ပြောစရာဖြစ်နေခဲ့၏။ အရှိန်မှာနှေးသကဲ့သို့ မံမိုရီလည်း စားခဲ့ပါသည်။ ဤနေရာတွင် Java 7 ရောက်မှ ထွက်ပေါ် လာသည်မှာ InvokeDynamic ဖြစ်ပြီး၊ Dynamic Type မက်သတ်များအား ပံ့ပိုးလာနိုင်ခဲ့ပါသည်။

လက်ရှိ အင်တာပရက်တာ ဖြင့်လည်း Java ဒြပ်မဲ့စက်ပေါ်တွင် Dynamic Type ဘာသာရပ်များကို အလုပ် လုပ်နိုင်စေသော်လည်း InvokeDynamic ၏ Byte Code နှင့် Method Handle ကိုအသုံးပြုခြင်းအားဖြင့် Dynamic Type ဘာသာရပ်များကို Java ဒြပ်မဲ့စက်ပေါ်တွင် Native ဘာသာရပ်များကဲ့သို့ လျှင်မြန်စွာ အလုပ်လုပ်စေနိုင်မည် ဖြစ်၏။

Java 7 ဖြင့် အနာဂတ် Java ကို ခန့်မှန်းကြည့်ခြင်း
  • ဤတစ်ခေါက် Java 7 ၏ အသစ်ပြုပြင်ပြောင်းလည်းလာမှု့များကို လေ့လာကြည့်ခြင်း အားဖြင့်၊ Java သည် ရေးသားရလွယ်ကူစေမှု့ကို ဦးစားပေးလာသည်ကို တွေ့ရ၏။
  • တဖန် Multi Core ခေတ်နှင့်အညီ Parallel Processing ကို အသုံးပြုနိုင်စေရန် ပြုပြင်လာပြီး၊ လက်တွေ ထိထိရောက်ရောက် သုံးပြုနိုင်မည်မှာ Java 8 လက်ထက်တွင်ဖြစ်၏။
  • J2SE 1.4 လက်ထက်က ပြင်ဆင်လာခဲ့သော New IO API မှာ ယခု Java 7 ရောက်မှ ပြည့်စုံလာပြီး၊ ရှေ့လျှောက် Java File အသုံးပြုရာတွင် လက်တွေ့ အသုံးများလာမည် ဆိုသည်မှာ မလွဲပေ။
  • Java Swing ဘက်တွင်လည်း JLayer ၊ Transparent Frame နှင့် Nimbus Look and Feel ကို ဖြည့်စွက်လာခဲ့ပါသော်လည်း၊ ထင်သလောက် ပြောင်းလည်းခြင်း မရှိပါသဖြင့် Client ပိုင်းဆိုင်ရာဘက်တွင် သိပ်ပြီး စိုက်ထုတ်လာသည်ဟု မဆိုနိုင်ပေ။
  • JVM အပေါ်တွင် အသုံးပြုသည့် Dynamic Type ဘာသာရပ်များအတွက်မှု၊ InvokeDynamic ကို ပံ့ပိုးပေးလာခဲ့သော်လည်း၊ Java ဘက်မှ ခေါ်ယူသည့်ဘက်ကိုမူ ပြုပြင်ခဲ့ခြင်းမရှိ။ ဤအချက်ကို ကြည့်ခြင်းအားဖြင့် Java ဘက်မှ Script ဘာသာရပ်ဘက်ကို ခေါ်ယူခြင်းကို သိပ်ပြီးမတွေ့ရသည်ကို သိနိုင်ပေသည်။

၂၀၁၁ရက် ၁၂လ ၃၁ရက်နေ့ တွင်လေ့လာခဲ့သော Java 7 နှင့် ပတ်သက်သောအကြောင်းများကို ပြန်လည်ဖော်ပြထားခြင်းဖြစ်ပြီး၊ နောက်အခန်းများတွင်လည်း Java 7 ၏ အသစ် ဖြည့်စွက်မှု့များကို ဆက်လက်၍ လေ့လာသွားပါဦးမည်။

လေးစားစွာဖြင့်

မင်းလွင်

]]> http://tech4mm.com/2012/01/java-7-%e1%80%96%e1%80%bc%e1%80%84%e1%80%b7%e1%80%ba-%e1%80%a1%e1%80%94%e1%80%ac%e1%80%82%e1%80%90%e1%80%ba%e1%80%80%e1%80%ad%e1%80%af-%e1%80%80%e1%80%bc%e1%80%8a%e1%80%b7%e1%80%ba%e1%80%99%e1%80%bc/feed/ 0 Oh My Frameworks! http://tech4mm.com/2012/01/oh-my-frameworks/ http://tech4mm.com/2012/01/oh-my-frameworks/#comments Wed, 04 Jan 2012 15:53:38 +0000 MinLwin http://tech4mm.com/?p=338

ကျွှန်တော်သည် ဒီအိုင်တီလောက ထဲကို ရောက်တာ ၆နှစ်ကျော် ၇နှစ် နီးပါးရှိပါပြီ။ အစကတည်းက Enterprise အပလီများနဲ့ အကျိုးပေးသည်ဟုထင်သည်၊ တောက်လျှောက် Enterprise အပလီများနှင့်သာ ကြုံရ၏။ အစမှစရေးသည့် ပရိုဂျက်မှအစ၊ ရှိပြီးသား စစ္စတမ်ကို ပြုပြင်ရေးသည့် နေရာအထိကြုံဖူးပါသည်။ တဖန် အပြောများသည့် Waterfall မှအစ Spiral နှင့် Agile ရေးသားပုံ တို့အထိ မျိုးစုံတွေ့ဘူးခဲ့ပါသည်။

စာအုပ်ရေးတဲ့သူတွေက တော်ကြပါသည်။ Waterfall မကောင်းဘူး၊ ခေတ်နောက်ကျနေပြီ၊ စရေးတဲ့အချိန်ကနေ့ ပြီးတဲ့အချိန်မှာ သုံးတဲ့ လိုအပ်ချက်တွေက ကွာဟလွန်းနေတယ်၊ ဘာညာဆိုပြီး Agile က အကောင်းဆုံးလို့ ထင်ရောင်ထင်မှားဖြစ်အောင် ရေးတတ်ကြပါသည်။ ရှင်းရှင်းပြောရင် Spiral နဲ့ Agile နဲ့ ဘာကွာလို့လဲလို့မေးရင် တိတိကျကျ အဖြေရှိမည်မဟုတ်ပေ။ ဒါပေမယ့် Agile ဆိုတဲ့ စကားလုံးက သစ်တော့အတော်များများက Agile ကို လုပ်ပါတော့သည်။

ကျွှန်တော်ကြုံဘူးသမျှထဲမှာ Agile လောက်ရွဲတာ တစ်ခုမှမရှိ။ အာရှလူမျိုးမှာနှင့် Agileဟာ လိုက်ဖက်မည် မထင်။ အနောက်တိုင်းသားများ၏ လုပ်ပုံကိုင်ပုံနှင့် အရှေ့တိုင်းသားများ၏ လုပ်ပုံကိုင်ပုံသည် ကွာမည် ဟုထင်ပါသည်။ ထားတော့ထားတော့၊ ဒီနေ့က ဒီကိစ္စကို ပြောချင်တာမဟုတ်ပါ။

framework

Framework ဟုကြားလျှင် လူတိုင်းစိတ်ချထားကြပေ လိမ့်မည်။ သူပြောတဲ့အတိုင်း ထရေးရင် တော်ရုံတန်ရုံ အလုပ်တန်းလုပ်နိုင်မည် ဖြစ်၏။ သို့ရာတွင် အတွင်းပိုင်းတွင် လုပ်နေသည်တို့ကို ကျွှန်တော်တို့ စဉ်းစားမိမည် မဟုတ်ပေ။ ကျွှန်တော်တို့ သုံးချင်တာနဲ့ တကယ်ပဲ ကိုက်ရဲ့လား။ ကျွှန်တော်တို့ လုပ်ချင်တဲ့ ပုံစံမျိုးကို တကယ်ပဲ လုပ်ပေးနိုင်လို့လား ဆိုတာ စဉ်းစားရန် အချိန်ပင် ရှိမည်မဟုတ်။

ရေးဟရေးဟ၊ ဆိုပြီး ဘာသံသယ မှမရှိပဲ ထရေးကြမည်ဟု ထင်ပါသည်။ နောက်ဆုံး လုပ်ချင်တာထက်၊ လုပ်လို့ရသည်ကိုသာ လုပ်သွားရသည်ကများမည် ဖြစ်၏။ ကျွှန်တော်တို့ ငယ်ငယ်က ကြားဖူးတဲ့ အရက်သမား အကြောင်းကို ပြန်ကြားမိပါသည်။

လမ်းထိပ်က ငဇော်ပေါ့ကွာ၊ ဒီကောင် အစက အပျော်အပါးနဲ့ သောက်တဲ့ အရက်က အခုတော့ အရက်က သူ့ကိုပြန်သောက်သွားပြီပေါ့ တဲ့။

Framework အသုံးပြုသူများလည်း ဤကဲ့သို့ပင်၊ အစကတော့ သုံးရလွယ်သားဆိုပြီး သုံးရာက နောက်ဆုံးတော့ ဘုမသိဘမသိ Framework ပြောရာ ယုံရတဲ့ ဘဝကို ရောက်မှာကိုယ် ရင်လေးမိပါသည်။ ကျွှန်တော်ကိုယ်တိုင်လည်း လက်တွေ့ကြုံပါတော့သည်။

ကျွှန်တော်တို့ အလုပ်လုပ်ပေးနေသော ဘဏ်ပရိုဂျက်တစ်ခုတွင် ထိုဘဏ်၏ နှစ်ရှည်လများ အသုံးပြုနေသော Framework တစ်ခုရှိပါသည်။ ကျွှန်တော်တို့ ပရိုဂျက်တွင်လည်း ထိုFramework ကို မသုံးမနေ သုံးရန်ဖြစ်လာပါသည်။ အကြောင်းမှာ လက်ရှိ အသုံးပြုနေသည့် ပရိုဂျက်များလည်း အများအပြားရှိခြင်းကြောင့် အယုံအကြည်ရှိခြင်းက အဓိက အချက်ဖြစ်ပါသည်။

လက်ရှိ သုံးနေတဲ့ Framework ဆိုတဲ့ အချက်ဟာ ငြင်းလို့မရအောင် ခိုင်လုံတဲ့ အကြောင်းပြချက် တစ်ခုဖြစ်ပါသည်။ အိုကေ၊ စပြီ။ ရေးကြရေးကြ အားလုံးဝိုင်းရေးကြပါသည်။

ပြီးခါမှ အချို့သော နေရာများမှာ လုပ်ချင်တဲ့ပုံစံ အတိုင်းဖြစ်မနေသည်ကို တွေ့ရပါသည်။

ဟင်ဘယ်လိုဖြစ်တာလဲ?

Document တွေထဲမှာ ဒီလိုရေးရင်ရတယ်ဆို။

အဲ့ဒီအတိုင်းရေးထားတာပဲ။ မှားစရာမှမရှိတာ။ ဒီလိုပဲနေမှာပါပဲ။

အားလုံးလက်လျှော့သွားကြပါသည်။ အဲ့ဒီမှာ မနေနိုင်တဲ့ ကျွှန်တော်က၊ နေဦးလေ၊ ငါတို့ လုပ်ချင်တာ ဒီလိုမှမဟုတ်တာ။ လို့မေးတော့

Framework က ပြောတဲ့အတိုင်းရေးထားတာလေ၊ မှားစရာမရှိဘူး။ ဒီလိုပဲ နေမှာပေါ့တဲ့။

အရီးလေး၊ ငိုရတော့မလို၊ ရယ်ရတော့မလို။

Asynchronous Process က ဘယ်လိုကြည့်ကြည့် Synchronous နဲ့ အလုပ်ထလုပ်နေတယ်။ Framework ကလည်း အဲ့ဒီအတိုင်းရေးရမယ်လို့ ပြောထားတယ်။ ယုံပြီပေါ့။

အဲ့ဒီတော့ ဒီကောင်တွေနဲ့ ဆက်မပြောတော့။ ဆက်ပြောရင်လည်းထူးမည် မဟုတ်။

စုပါသည်။ Tools များကို။ Framework က Source မရနိုင်တဲ့အတွက် Class ကနေ Decompile လုပ်နိုင်တဲ့ Jade၊ ပြီးတော့ ကျွှန်တော်အကြိုက်ဆုံး Text Editor Hidemaru။

အခြားလူတွေများနေရင် နားငြီးတာနဲ့ ဒီကနေ့ ဘယ်သူမှအလုပ်မလာတဲ့ အချိန် တစ်နာရီလောက် စောသွားပြီး ရှာပါတော့သည်။ XML Setting တွင် ရေးထားသော ပါရာမီတာက မှားနေပါသည်။ လူအသုံးမများသော Function ဖြစ်သောကြောင့် အကြိမ်ကြိမ် Maintenance လုပ်ရင်း လွဲသွားပုံရ၏။ ပြောပြလိုက်တော့မှ ပြဿနာက ကြီးသွားပါတော့သည်။ လက်ရှိ အမှားကို အမှန်ထင်ပြီး အသုံးပြုနေတဲ့ စစ္စတမ်တွေက မနည်းတော့။ ဒါတောင် နမှုနာတစ်ခု ဖြစ်ပါသည်။

ဒါကြောင့် Framework ဆိုတာနဲ့ အေးဟအေးဟ ဆိုပြီး မယုံကြည်သင့်ကြောင်း သတိပေးလိုပါသည်။

လူသားအားလုံး အမှားနဲ့မကင်းပေ။

Framework သည်လည်း ထိုနည်း၎င်း။

လေးစားစွာဖြင့်

မင်းလွင်

]]> http://tech4mm.com/2012/01/oh-my-frameworks/feed/ 0 Armadillo Developer များနှင့် အင်တာဗျူး http://tech4mm.com/2011/12/interview-with-armadillo-developer/ http://tech4mm.com/2011/12/interview-with-armadillo-developer/#comments Sun, 04 Dec 2011 03:42:19 +0000 Armadillo http://tech4mm.com/?p=332

အင်တာဗျူးမေးမြန်းသူ၏ မှတ်ချက်။  ယခုအင်တာဗျူးသည် အဆင့်မြင့်တန်းကျမ်းပြုအတွက် ရည်ရွယ်ခြင်း ဖြစ်ပါသည်။ မူလတော့ပစ်ခေါင်းစဉ်သည် အလွန်ကျယ်ပြန့်သောကြောင့် အကြောင်းအရာကို ခြုံငုံမိစေရန်အတွက် ခေါင်းစဉ်ပြောင်းလိုက်သည်။  ထို့အတွက်ကြောင့် အင်တာဗျူး မပီသတော့ပေ။ အင်တာဗျူးကို လွန်ခဲ့သော တစ်နှစ်ကတည်းက ပြုလုပ်ခဲ့သော်လည်း လုံခြုံရေးနှင့် reversing အဖွဲ့အစည်းများအတွက်မူ စိတ်၀င်စားစရာဖြစ်ဆဲဟု ထင်ပါသည်။ အင်တာဗျူးဖြေကြားသူ နှစ်ဦးမှာ Armadillo Team မှ မန်ဘာနှစ်ဦး ဖြစ်သောကြောင့်  တစ်ချို့နေရာများတွင် အဖြေနှစ်ခု ဖြစ်နေသည်ကို တွေ့ကြရမည် ဖြစ်ပါသည်။ အချိန်ပေးပြီး ဖြေကြားခဲ့ကြသော ထိုသူနှစ်ယောက်ကို အလွန်ကျေးဇူးတင်မိသလို ရရှိသမျှ သတင်းအချက်အလက်များကို ကျမ်းတွင် ထည့်သွင်းရေးသားခြင်း မပြုနိုင်သည့်အတွက်မူ စိတ်မကောင်းဖြစ်မိသည်။  ထို့ပြင် သူတို့နှစ်ဦး ဖြေကြားသော အဖြေများသည် reversing အဖွဲ့အစည်းများအတွက် ဆွေးနွေးချက်တစ်စုံတရာ ဖြစ်ပေါ်စေဖို့ မှ ေမှျာ်လင့်မိပါသည်။

၁။ လုံခြုံရေးစနစ်တစ်ခုကို ကိုယ်တိုင် တည်ဆောက်တာနဲ့ third party ကို လိုင်စင်ချပေးလိုက်တာ ဘယ်ဟာပိုကောင်းလဲ။
- လုံခြုံရေးစနစ်ကောင်းတစ်ခုကို ကိုယ့် ဆော့ဖ်၀ဲလ် team က တည်ဆောက်တာက အများကြီး ဗဟုသုတရှိဖို့လိုသလို cracker တွေရဲ နောက်ဆုံးပေါ် နည်းစနစ်တွေကိုလည်း အမြဲလေ့လာနေဖို့လိုပါတယ်။ ကောင်းတဲ့အချက်ကတော့ ကျွန်တော်တို့က အချိန်ပြည့်အားထုတ်လို့ ပြီးပြည့်စုံတဲ့စနစ်တစ်ခုကို တည်ဆောက်နိုင်ပြီး၊ အသုံးပြုခွင့်လိုင်စင် ချပေးလိုက်မယ်ဆိုရင် လက်ရှိ Third party ကို အသုံးပြုနေတဲ့သူတွေအနေနဲ့ တစ်၀က်တစ်ပျက် လုံခြုံရေးစနစ်တွေကို တည်ဆောက်နေမယ့်အစား သူတို့ရဲ့အချိန်တွေကို သူတို့လုပ်ချင်တဲ့ အပိုင်းတွေမှာ ြမုပ်နှံနိုင်ပါတယ်။
- ဆော့ဖ်၀ဲလ်လုံခြုံရေးဆိုတာ တစ်ရက်နှစ်ရက်နဲ့ လေ့လာလို့ရတဲ့အရာ မဟုတ်ပါဘူး။ ခိုင်ခိုင်မာမာ တည်ဆောက်နိုင်ဖို့ဆိုတာဟာ ဒီနယ်ပယ်မှာ နှစ်ပေါင်းများစွာ အတွေ့အကြုံရှိမှ ဖြစ်တာပါ။ ခင်ဗျားအနေနဲ့ အချိန်အများကြီး ပေးဖို့လိုသလို နောက်ဆုံးပေါ် cracking နည်းပညာတွေ၊ tool တွေ သုံးတတ်ဖို့လည်း လိုပါတယ်။ ခင်ဗျားက ခင်ဗျားရဲ့ product အသစ်အတွက် အားထုတ်လုံးပန်း နေရတယ်ဆိုရင်တော့ ဒီဘက်ကို လှည့်ကြည့်နိုင်မှာ မဟုတ်ဘူးလေ။ ဒါကြောင့် သူတို့အနေနဲ့ လုံခြုံရေးစနစ်တွေအတွက် အချိန်ကုန်ခံစရာ မလိုတော့သလို သူတို့ကျွမ်းကျင်ရာ နယ်ပယ်မဟုတ်တဲ့အတွက် သူတို့ကိုယ်တိုင်ရေးနေရင် crack ခံရဖို့ ကတော့ အနည်းနဲ့အများပဲ။

၂။ ခင်ဗျားတို့ ဆော့ဖ်၀ဲလ်ကို လုံခြုံရေးစနစ်အတွက် သုံးစွဲမယ့်သူတိုင်းရဲ့ လိုအပ်ချက်ဖြစ်လာဖို့ ဘယ်လိုတိုးတက်အောင် လုပ်မလဲ။ ဒါမှမဟုတ် cripple ware တို့၊ Online key valiadation တို့လိုပဲ ဆော့ဖ်၀ဲလ်လုံခြုံမှုစနစ် လောကထဲက အဆင့်တစ်ဆင့်အနေနဲ့ ဆက်လက်ရပ်တည်ပြီး အဲဒီအဆင့်ကိုပဲ ပိုကောင်းအောင်လုပ်မလား။
- အမှန်တော့ ကျွန်တော်တို့ ယုံကြည်တာက သုံးစွဲသူတွေကို ပေးတဲ့ လက်ရှိဆော့ဖ်၀ဲလ်နဲ့ ကုဒ်အကြံပေးချက်တွေက လုံခြုံမှုဘက်က တစ်ခုတည်းပါ။ တကယ်လို့ သူတို့က website တစ်ခုပေါ်ကို သူတို့ product ကိုသွားတင်မယ်ဆိုရင် ကျွန်တော်တို့ဘက်က key validation ဆော့ဖ်၀ဲလ်ပေးနိုင်သလို ဆိုင်အသေးလေးတွေအတွက်ဆိုရင်တော့ Armadillo မှာ Built in လုပ်ပေးထားပါတယ်။
- လုံခြုံရေးစနစ်ဆိုတာ ဆော့ဖ်၀ဲလ်တည်ဆောက်ပုံ ခိုင်မာသလောက် ခိုင်မာတယ်။ ကျွန်တော်တို့က ဆော့ဖ်၀ဲလ်ကို အတိုက်အခိုက်မခံရအောင် ကာကွယ်တဲ့ ပြီးပြည့်စုံသော နည်းစနစ်နဲ့ လုပ်ဆောင်ချက်တွေကို ပံ့ပိုးပေးထားတယ်။ ဒါပေမယ့် လုံး၀အတိုက်အခိုက် မခံရဘူးလို့တော့ မဆိုလိုပါဘူး။ အချိန်အတော်များများမှာ တည်ဆောက်တဲ့ ပုံစံမှားယွင်းမှုကြောင့် ဆော့ဖ်၀ဲလ်ဟာ ဖြစ်သင့်တာထက် အားနည်းသွားတာမျိုး ရှိတတ်တယ်။ ကျွန်တော်ထင်တာကတော့ ပရိုဂရမ်မာတွေက ကျွန်တော်တို့  ပစ်စည်းကိုသုံးတဲ့အပြင်  hidden/subtle check တွေကို ထည့်ပေးသင့်တယ် ထင်တယ်။ သေသေချာချာ လုပ်မယ်ဆိုရင်တော့ ကောင်းကောင်းစိန်ခေါ်နိုင်မှာပဲ။
- အကောင်းဆုံး လုံခြုံရေးစနစ်ဆိုတာက ဆော့ဖ်၀ဲလ်ရဲ့ demo version ပဲပေါ့။ ကုဒ်အချို့ application မှာ တကယ်ကို ချန်လှပ်ထားခံရတာ။ နောက်ပြီး ဖျောက်ထားတဲ့အပိုင်းတွေကလည်း မြင်သာထင်သာ မဖြစ်ရဘူး။ ဥပမာ File save လုပ်တဲ့ Function တို့ ဘာတို့လေ။  ပိုပြိး ခက်ခဲရှုပ်ထွေးတဲ့ အပိုင်းတွေကို ဖျောက်ထားတာက ပိုပြီး သင့်တော်တယ်။

၃။ ခင်ဗျားတို့ SafeDisc တို့လို ကုမ်ပဏီ တွေက SDK ထုတ်လိုက်တော့ developer တွေက ဆော့ဖ်၀ဲလ်ရေးသားတဲ့အဆင့်မှာ လုံခြုံမှုစနစ်ကို တခါတည်း ထည့်ရေးသွားလို့ရတယ်။ ဒါဟာ ခင်ဗျားတို့အတွက် ကောင်းတဲ့ အချက်လား။
- ကောင်းတဲ့အချက်ကတော့ ဆော့ဖ်၀ဲလ်ဖန်တီးသူတွေကို ငါတို့ ကာကွယ်ဖို့လိုအပ်တယ်ဆိုတဲ့ အသိလေး ထည့်ပေးလိုက်သလိုပဲ။ သေသေချာချာ အသေးစိတ် လုပ်ခြင်းအားဖြင့် လုံခြုံရေးအတွက် ပိုကောင်းလာသလို ဆော့ဖ်၀ဲလ် လိုင်စင်ကိုပါ ကာကွယ်ပြီးသား ဖြစ်သွားတယ်။ ထပ်ထပ်တိုးလို့ရတဲ့ လိုင်စင်အမျိုးအစားဖြစ်တဲ့ variable licensing scheme မှာဆိုရင် programmer က exe file တစ်ခု ကိုရမှာဖြစ်ပြီး သူ့ရဲ့ user ၀ယ်ထားတဲ့ လိုင်စင်ပေါ်မှာ မူတည်လို့ license key က လိုင်စင်၀ယ်ထားတဲ့ အပိုင်းတွေကို unlock လုပ်သွားမှာဖြစ်ပါတယ်။

၃.၁။ ဆော့ဖ်၀ဲလ် security ကို နောက်ဆုံးအဆင့်ကျမှ ထည့်သွင်းတာ ပိုများလွယ်မလား။
- ဒါပေါ့။ နောက်ဆုံးအဆင့်ဆိုရင်တော့ ပိုလွယ်တာပေါ့။ ဒါပေမယ့် ပေါ်ပြူလာဖြစ်နေတဲ့ program တွေအတွက်ကတော့
အကောင်းဆုံးအဖြေ ဖြစ်မှာ မဟုတ်ဘူး။ ဒါကြောင့် ကျွန်တော်တို့က developer တွေကို ဆော့ဖ်၀ဲလ်ဖန်တီးတဲ့ အဆင့်မှာကတည်းက ထည့်သွင်းနိုင်ဖို့ Nanomite တို့၊ Secured Section တို့လို SDK တွေ ထုတ်လုပ်ပေးထားတာ။
- ကောင်းကျိုးကတော့ သုံးစွဲသူက ဘယ်နေရာမှာတော့ဖြင့် special protection ထည့်လိုက်မယ်၊ special check တွေထည့်လိုက်မယ် စသည်ဖြင့် ရွေးနိုင်သလို လုံခြုံရေးစနစ်ကို အကောင်းဆုံးဖြစ်အောင် သုံးစွဲနိုင်သွားလိမ့်မယ်။ တချို့ လုပ်ဆောင်ချက်တွေကတော့ application ကို နှေးသွားစေတာပေါ့။ ဒါကြောင့် programmer က application ရဲ့ စွမ်းဆောင်ရည်ကို မထိခိုက်စေဘဲဲ သုံးစွဲနိုင်ရင်တော့ ပိုပြီး ကောင်းလိမ့်မယ် ထင်တယ်။
- SDK တွေက ရည်ရွယ်ချက်အတိုင်း ကာကွယ်မှုပေးနိုင်သလို ဆော့ဖ်၀ဲလ်နဲ့ လုံခြုံရေးစနစ်ကို အချိုးညီညီ ပေါင်းစပ်ပေးပါတယ်။ လုံခြုံရေးစနစ်ကို တိုက်ရိုက်ကြီး မှီခိုနေရခြင်း ကင်းလေလေ ပိုကောင်းလေလေပဲ။

၄။ လုံခြုံရေးရှုထောင့်အပြင် ခင်ဗျားအနေနဲ့ ဖိုင်အရွယ်အစား၊ တွက်ချက်မှုကြာချိန်၊ အခြား ဆော့ဖ်၀ဲလ်တွေနဲ့ သဟဇာတဖြစ်မှု၊ အလွယ်တကူ အသုံးပြုနိုုင်မှုစတဲ့ အချက်တွေကို တွေးပူရမှာပေါ့။ အဲဒါတွေကို ခင်ဗျား ဘယ်လို ကိုင်တွယ်သလဲ။ အဲဒီအချက်တွေက ခင်ဗျားရဲ့ ဖန်တီးမှုအပေါ် အတားအဆီး ဖြစ်သလား။
ဖိုင်အရွယ်အစား
- အခုခေတ်မှာ ကွန်ပျူတာတိုင်း storage များတဲ့ hard drive တွေရှိကြတာချည်းပဲ။ ဒါကြောင့် file size ကတော့ ဟိုးအရင်ခေတ်တုန်းကလို ပူစရာမလိုပါဘူး။ ဒါပေမယ့် အတတ်နိုင်ဆုံးတော့ အရွယ်အစားသေးငယ် ကျစ်လျစ်အောင် ကြိုးစားထားပါတယ်။
တွက်ချက်မှု အမြန်နှုန်း
- Microprocessor တွေက မြန်သထက် မြန်မြန်လာတော့ ဒါကလည်း ပြဿနာ မဟုတ်တော့ပါဘူး။ ကျွန်တော်ကတော့ ကျွန်တော်တို့ ASM code တွေကို အရွယ်အစားသေးငယ် မြန်ဆန်အောင် အမြဲကြိုးစားခဲ့တာပါပဲ။ Memory တို့၊ disk space တို့ကလည်း အရင်က တန်ဖိုးကြီးခဲ့ပေမယ့် အခု အရမ်းသက်သာနေပါပြီ။
- အခုခေတ်မှာ ကွန်ပျူတာတွေက အရမ်းမြန်လာကြပြီ။ CPU ကလည်း မြန်သထက်ကို မြန်လာတယ်။ ဒါပေမယ့် ကျွန်တော်တို့ကတော့  ခင်ဗျားဆီမှာ ခေတ်မီကွန်ပျူတာ မရှိတောင် system အဟောင်းတွေမှာ သုံးလို့ရအောင် ကြိုးစားထားပါတယ်။ အမြန်နှုန်းဆိုတာ အရေးပါတဲ့အချက်ပါ။ ဒါကြောင့် ကျွန်တာ်တို့ဘက်ကတော့ အတတ်နိုင်ဆုံး မြန်အောင် လုပ်ပေးထားတာပဲ။ တခါတလေတော့လည်း Assembly ကိုသုံးပြီး အမြန်ဆုံးဖြစ်အောင် လုပ်ရတာပေါ့။
သဟဇာတဖြစ်မှု
- ကျွန်တော်တို့ဆီမှာ Rှindow OS အားလုံး ရှိတယ်။ Version အဟောင်းတွေမှာ ၁၀၀ % သဟဇာတ ဖြစ်စေဖို့ ကျွန်တော်တို့ product တွေကို OS အားလုံးမှာ စမ်းသပ်ပါတယ်။
အသုံးပြုရလွယ်ကူမှု
- ဖန်တီးမှု အဟန့်အတားဆိုလို့…. ခင်ဗျားအနေနဲ့ တခြားနည်းလမ်းတွေကနေ ဖန်တီးရမှာပေါ့။
- ပြဿနာ အဖြစ်ဆုံးကတော့ သဟဇာတ ဖြစ်ဖို့ပဲ။ ကျွန်တော်တို့ တခါတလေဆို အတော်ကောင်းတဲ့ ကာကွယ်ရေး နည်းလမ်းကို တွေ့တယ်။ ဒါပေမယ့် အဲဒါက OS အားလုံးနဲ့ မကိုက်ပြန်ဘူး၊ ဒါမှမဟုတ် Virtual Machine ပေါ်မှာ အလုပ်မလုပ်ပြန်ဘူး။ နောက်ဆုံးကျတော့ ဒါကို မသုံးဘဲ နေလိုက်ရရော၊ ဒါအပြင် မစမ်းသပ်ခင် OS version ကို အရင်ကြည့်နေရတယ်။ အဲဒါတွေက လုံခြုံရေးစနစ်ကို အားနည်းစေတာတွေပဲ။ ဒါပေမယ့် ကျွန်တော်တို့ကတော့ ၁၀၀ % သဟဇာဖြစ်မှုကိုပဲ ထိန်းသိမ်းထားပါတယ်။

၅။ အင်တာနက်အသုံးပြုခြင်း တိုးပွားလာတာနဲ့အမျှ online key validation က ပိုပြီး ပေါ်ပြူလာ ဖြစ်လာတယ်။ ဒါကြောင့် Security trend က အဲဒီဘက်ကို သွားမယ်လို့ ထင်လား။ ဒါမှမဟုတ် ဘာရှိသေးလဲ။
- ခင်ဗျားမေးခွန်းကို ကျွန်တော်နားလည်သလောက် ဖြေရရင် လုံခြုံရေးစနစ်က ရှိပြီးသား။ ကျွန်တော်တို့ မိခင်ကုမ်ပဏီဖြစ်တဲ့ Digital River ကနေ လုံခြုံမှုစနစ် ထည့်သွင်းပြီးသား ဆော့ဖ်၀ဲလ်တွေကို အင်တာနက်ကနေပဲ ရောင်းနေတာ။ Protection ကတော့ နည်းပညာကို အမြဲ ထပ်ချပ်မကွာ လိုက်နေရမှာပဲ။ နည်းပညာကိုယ်တိုင် သူ့ကိုယ်သူ ကာကွယ်နိုင်တဲ့ စွမ်းအားရှိတဲ့ အခြေအနေ ရောက်တဲ့အချိန်ထိပေါ့။
- ကျွန်တော်ကတော့ သေသေချာချာ တည်ဆောက်ထားတဲ့ ဆာဗာအခြေခံတဲ့ စစ်ဆေးမှုတွေက အနာဂတ်မှာ ဖြစ်လာနိုင်တယ်။ ပြဿနာတစ်ရပ်ကတော့ အင်တာနက်ဗိုင်းရပ်စ်တွေ၊ spyware တွေ၊ malware တွေ ပွထနေတဲ့ အချိန်မှာ application က အိမ်ကိုဖုန်းဆက်ပြီး license ကို စစ်ဆေးတာမျိုး ဘယ်သုံးစွဲသူကမှ ဒါကို လက်ခံနိုင်မှာ မဟုတ်ဘူး။ Online key validation ကတော့ သေချာ တည်ဆောက်ထားဖို့ လိုတယ်။ နောက်ပြီး validation သက်သက် မဖြစ်သင့်ဘူး။ အင်တာနက်ဆာဗာတွေကို token တစ်ခုအနေနဲ့ အသုံးပြုပြီး လိုအပ်တဲ့အချိန်မှာ ကုဒ်အစိတ်အပိုင်းတွေကို decrypt လုပ်သင့်သလို လိုအပ်တဲ့အချိန်မှာ encrypt လုပ်နိုင်စွမ်းအား ရှိသင့်တယ်။ အနာဂတ်မှာတော့ နည်းစနစ်အမျိုးမျိုး ပေါင်းစပ်လုပ်ကြမယ်လို့ ထင်တာပဲ။ နည်းပညာက နေရာတိုင်း မတွင်ကျယ်သေးတော့ လောလောဆယ်မှာ အများပြည်သူက လက်မခံနိုင်သေးဘူး။ ဥပမာ license ကို စစ်ဆေးဖို့ အင်တာနက်လိုတယ်။ ဒါပေမယ့် အဲဒီခေတ်တုန်းက လူတိုင်းမှာ အင်တာနက်မရှိဘူး။

၆။ လူနဲ့ လူအဖွဲ့အစည်းမှာ လူတော်တော်များများ သိပ်ထူးခကျွန်ကြတယ်။ အပင်ပန်းခံပြီး ခင်ဗျားတို့ protection တွေကို ဖောက်ဖို့ ကြိုးစားကြတယ်။ ဒါပေမယ့် ယထဘူတကျကျ ပြောမယ်ဆိုရင် သူတို့မရှိရင် ခင်ဗျားတို့ပစ်စည်းကို ဘယ်သူမှ သုံးမှာမဟုတ်ဘူး။ ဒါကြောင့် Reverse engineering အဖွဲ့အစည်းအပေါ် ခင်ဗျားရဲ့အမြင်ကို သိလိုပါတယ်။
- သူတို့မှ မရှိရင် ကျွန်တော်တို့ပစ်စည်းလည်း မလိုပါဘူး။ ရိုးသားမြဲ ရိုးသားတဲ့ သူတွေအတွက်ဆို key တစ်ခုလောက်ပဲ လိုလိမ့်မယ်။ သူတို့ တရားဥပဒေဘောင်ပြင်က အလုပ်လုပ်တဲ့အပြင် ဥပဒေချိုးဖောက်တဲ့သူဆိုတာ လေးစားခံရဖို့ ခက်ခဲသည့်တိုင်အောင် ကျွန်တော်ကတော့ ပိုတော်တဲ့ cracker တွေရဲ့ အသိဥာဏ်ပညာကို လေးစားပါတယ်။
- ကျွန်တော့်ဘက်ကတော့ reverse engineering က အရေးကြီးတယ်လို့ ထင်တယ်။ Reverse engineering ဆိုတာ ဆော့ဖ်၀ဲလ်တွေကို crack ဖို့တစ်ခုတည်း မဟုတ်ဘူး။ ဒါပေမယ့် လူတွေကတော့ ဒီလိုပဲ မြင်နေကြတယ်။ RE ကို anti-virus ကုမ်ပဏီတွေက virus တွေ malware တွေကို လေ့လာဖို့ သုံးတယ်။ RE ကနေ tool တွေ၊ technique တွေ အများကြီးထွက်လာနိုင်ပြီး ကောင်းတဲ့ဘက်မှာ အသုံးချနိုင်တယ်။ နောက်ပြီး source code မပေးတဲ့ ဆော့ဖ်၀ဲလ်တွေရဲ့ ယိုပေါက်တွေကို ရှာနိုင်တယ်။  ဒါမှ ပိုပြီး လုံခြုံတဲ့ ဆော့ဖ်၀ဲလ်တွေ ဖြစ်လာမယ်။
- ကျွန်တော့်အမြင်ကတော့ RE ကို cracking နဲ့ ခွဲခြားစေချင်တာပဲ။ RE အသိုင်းအ၀ိုင်းက လူတွေက ပျော်ရှှင်မှုအတွက်ရယ်၊ လေ့လာဖို့အတွက်ရယ်ပဲ လုပ်တာဖြစ်ပြီး ဘယ်သူ့ကိုမှ ဒုက်ခမပေးကြဘူး။ သူတို့ အတွေ့အကြုံတွေကို ဖိုရမ်တွေမှာတော့ မျှေ၀ကြတာပေါ့လေ။ ကျွန်တော်ထင်တာက ဆော့ဖ်၀ဲလ်ကာကွယ်ရေးသမားတွေက Underground Research များများလုပ်ဖို့ လိုပြီး သူတို့ကိုလည်း သူခိုးတွေလို့ ထင်မနေစေချင်ဘူး။ (အချိန်အတော်များများမှာပေါ့)

၇။ ခင်ဗျားဟာ ခင်ဗျားရဲ့ လုံခြုံရေးစနစ်ကို ချိုးဖောက်ခံလိုက်ရတာ တွေ့ပြီဆိုပါတော့။ ဘယ်လိုပြန်ပြီး တုံ့ပြန်ဖြစ်မလဲ။ တရား၀င် နည်းလမ်းဘောင် အပြင်က ဖြစ်ဖြစ်ပေါ့။ ဒါမှမဟုတ် သူတို့ကို လေးစားမိနေမလား။
- ဟုတ်တယ်။ ကျွန်တာ်ကတော့ အတော် လေးစားမိမှာပဲ။ ကျွန်တော့် လုပ်ဖော်ကိုင်ဖက်တွေကတော့ သဘောတူမှာ မဟုတ်ပါဘူး။ ဒါပေမယ့် နည်းလမ်းတွေ ခိုးထားတဲ့ key တွေကို လှျောက်ဖြန်ေ့၀ခြင်း မပြုရင်တော့ ပိုပြီးတော့ လေးစားဖို့ ကောင်းမှာပေါ့ဗျာ။ ဒါပေမယ့် သေချာတာက သူတို့က ဒါမျိုးမလုပ်ဘဲ နေမှာမဟုတ်ဘူး။
- ကျွန်တော်ကတော့ စမတ်ကျပြီး Credit card တွေကိုခိုးပြီး ဆော့ဖ်၀ဲလ်တွေ ၀ယ်ယူတာမျိုးလို သူခိုးကျင့်သူခိုးကြံ မလုပ်သရွေ့ ကျွန်တော်တို့ လုံခြုံရေးစနစ်ကို ချိုးဖောက်နိုင်တဲ့သူတွေကို လေးစားတယ်။ ခက်ခက်ခဲခဲနဲ့ ကျွန်တော်တို့ ကုဒ်တွေကို ချိုးဖောက်ဖို့ disassembling နဲ့ debugging လုပ်တဲ့သူတွေကိုတော့ လေးစားမိတာ အမှန်ပဲ။ ဒါပေမယ့် သူတို့ ဘာလုပ်နိုင်တယ်ဆိုတာကို ကြွား၀ါပြီး ကျွန်တော်တို့ကို မခန့်လေးစား လုပ်တတ်တဲ့ ဆောင့်ကြွားကြွား ငနဲလေးတွေကိုတော့ မလေးစားနိုင်ဘူး။ သူတို့မေ့နေတာက သူတို့ ကွန်ပျူတာ စကိုင်တတ်စ အချိန်မှာတင် ဒါမျိုးအလုပ်တွေက ကျွန်တော်တို့ လုပ်ခဲ့တာတွေ ဆိုတာပဲ။ နောက်ပြီး စနစ်တခုကို ကာကွယ်စောင့်ရှောက်ရတာဟာ စနစ်တစ်ခုကို ချိုးဖောက်ရတာထက် အများကြီး လက်၀င်တယ်။

၈။ ခင်ဗျားအတွက် အကောင်းဆုံး လုံခြုံရေးနည်းလမ်းက ဘာလဲ။ ဥပမာ – Address Table ဖျက်ပစ်တာတို့၊ Anti-debug လုပ်တဲ့နည်းတို့၊ child process တို့လိုပေါ့။
- ကျွန်တော်တို့ရဲ့  level အမြင့်ဆုံး key စနစ်ပါ။ နောက်ပြီး ကျွန်တော်တို့ရဲ့ Strategic Code Splicing နဲ့ Memory patching protection တွေပေါ့။
- ကျွန်တော်ကတော့ Nanomites က အကောင်းဆုံးပဲဗျ။ သူ့မှာ အားနည်းချက်တွေ ရှိနေပေမယ့် cracker အများစုကို ကာကွယ်ပေးနိုင်လိမ့်မယ်။ Import Table Elimination လဲ ကောင်းတာပါပဲ။
- လိုင်စင်အနေနဲ့ကတော့ ကျွန်တော်တို့ key စနစ်ရဲ့ level 10 ကိုသုံးရင် ခင်ဗျား application တွေကို keygen လုပ်ခံရခြင်းမှ ကာကွယ်ပေးလိမ့်မယ်။

၉။ နောင်အနာဂတ်မှာ လုံခြုံရေးအဆင့်တိုးမRင့်အောင် ဘယ်လို ပြုပြင်ပြောငး်လဲမှုတွေ လုပ်မလဲ။
- ကျွန်တော်တို့ကတော့ ကျွန်တော်တို့ security နည်းလမ်းတွေနဲ့ key တွေရဲ့ ကြံ့ခိုင်မှုကို အမြဲ တိုးတက်အောင် လုပ်နေတာပဲ။ နောက်ထပ်ထွက်ပေါ်လာစရာရှိတာက 64-bit window application တွေအတွက် လုံခြုံရေးစနစ်ပါ။
- ကျွန်တော်တို့ကတော့ ကျွန်တော်တို့ လုံခြုံရေးလုပ်ဆောင်ချက်တွေကို အမြဲတိုးတက်အောင် လုပ်နေတာပဲ။ နောက်ပြီး cracking ဖိုရမ်တွေကိုလည်း လိုက်ကြည့်ရတယ်။ ကျွန်တော်တို့ကို တိုက်ခိုက်နိုင်မယ့် တစ်ခုခု တွေ့တာနဲ့ အမြန်ပြင်ဆင်ရတယ်။ အမြဲတမ်းတော့ လုံခြုံရေးစနစ်တွေကို ချိုးဖောက်ရ ခက်ခဲအောင် ကြိုးစားနေတာပါပဲ။ ဒါက အခက်ခဲဆုံး စိန်ခေါ်မှုတစ်ရပ်ပဲ။

၁၀။ Reversing အသိုင်းအ၀ိုင်းကို ဘာများပြောချင်သေးလဲ။
- တချို့ cracker လက်သစ်ကလေးတွေက သိပ်ငယ်တယ်။ သူတို့လုပ်နေသမျှတွေဟာ ပြည်ထောင်စုအစိုးရရဲ့ ဥပဒေကို ချိုးဖောက်နေတာဖြစ်ကြောင်း သတိတောင် မူမိရဲ့လား မသိဘူး။ သူတို့ ဂရုမစိုက်သလို ကိုယ့်ကိုယ်ကို ဟုတ်လှပြီ ထင်နေတဲ့ သူတွေကလည်း နားမလည်ကြဘူး။ ဒါကြောင့် ဘယ်သူလုပ်နေတယ်ဆိုတာ ထောက်ပြဖို့ သိပ်လွယ်သွားတယ်။ (သိပ်ပေါ်ပြူလာဖြစ်ချင်တဲ့ ရောဂါလေ)
- အထွေအထူးတော့ မရှိပါဘူး။ တချို့သောပုဂ်ဂိုလ်တွေ လေးစားမှုကို ပိုပြီးနားလည်ဖို့နဲ့ ဘာရည်ရွယ်ချက်မှ မရှိဘဲ လုံခြုံရေးစနစ် ရေးသားသူတွေကို တိုက်ခိုက်တာမျိုးကိုတော့ ရပ်တန့်စေချင်တယ်။ ကျွန်တော်တို့က သူတို့ စိတ်ကူးတွေကို ခိုးတယ်၊ သူတို့ဆီက သိသွားတာ စသည်ဖြင့် ဖိုရမ်တွေပေါ်မှာ ကြွား၀ါနေကြတာကို ဖတ်ရတာ သိပ်ရယ်ချင်တယ်။ ကျွန်တော်တို့က သူတို့ထက်အရင် ဒါမျိုးတွေလုပ်ခဲ့တာ ကြာကြာလှပေါ့။

၁၁။ ခင်ဗျားတို့ product တွေအပြင် ဘယ်နည်းလမ်းတွေက ဆော့ဖ်၀ဲလ်လုံခြုံရေးအတွက် အကောင်းဆုံးဖြစ်မလဲ။ ဥပမာ Personal Build တွေ၊ Rှatermarking တွေ၊ ဆော့ဖ်၀ဲလ် update တွေနဲ့ Technical support တွေကို ငြင်းပယ်တာမျိုးပေါ့။
- အဲဒါတွေအားလုံးက ဥပမာကောင်းတွေပဲ။ အကောင်းဆုံး နည်းလမ်းကတော့ ကာကွယ်ဖို့ဆိုတဲ့ စိတ်တစ်ခုကို အမြဲသွင်းထားဖို့ပါပဲ။ အရှေ့က ကုဒ်တွေရဲ့ checksum မှန်ကန်မှ နောက်ပိုင်း ကုဒ်တွေ ဆက်အလုပ်လုပ်အောင် ပြုလုပ်တာမျိုးလိုပေါ့။ ပရိုဂရမ်အများစုက ပရိုဂရမ် run နိုင်ဖို့ CD ရှိဖို့လိုတယ်။ CD ကို drive ထဲ တစ်ခါလောက် ထည့် run လိုက်မှ application ကို အလုပ်လုပ်ခွင့်ပေးတာ။ အဲဒါဟာ ကာကွယ်ရေးစနစ်တွေကို ချိုးဖောက်ပစ်ဖို့ အလွယ်ဆုံးပဲ။ တကယ်လို့ ကုမ်ပဏီတွေက CD ကို နေရာအနှံ့မှာ ထပ်ခါထပ်ခါ access လုပ်ခြင်းကနေ ကာကွယ်ဖို့ လုပ်ထားရင်တောင် ဇွဲကောင်းတဲ့ cracker တွေရန်က မကာကွယ်နိုင်ဘူး။
- Virtual Machine တွေက ဆော့ဖ်၀ဲလ် security အတွက် အရမ်းကောင်းတဲ့ နည်းလမ်း ဖြစ်ပါတယ်။ Pcode တွေကို ခွဲခြမ်းစိတ်ဖြာဖို့က Assembly code တွေထက် ပိုခက်တယ်။ Virtual Machine တွေကို ကာကွယ်ရေး ရည်ရွယ်ချက်နဲ့ သုံးတာဟာ အခုအခြေအနေမှာတော့ တိုးတက်လာတဲ့ နည်းလမ်းအသစ်ပဲ။
- Hidden/Delayed check တွေလည်း ကောငး်တာပဲ။ ခင်ဗျား အင်တာနက်မှာ တစ်ပိုင်းတစ်စ crack ထားတဲ့ sofware တွေကို တွေ့ဖူးမယ် ထင်တယ်။ အဲဒီ ဆော့ဖ်၀ဲလ်တွေက အလုပ်ကောင်းကောင်းလည်း မလုပ်ဘူးလေ။ Hidden/Delay check တွေက track လိုက်ဖို့ သိပ်ခက်တယ်။ Check တွေကို ကောင်းကောင်း မကိုင်တွယ်နိုင်တဲ့ cracker တွေက  သူတို့ အသိုင်းအ၀ိုင်းမှာတော့ သောက်ပေါပဲ။
- Rှatermark တွေက security ဖြစ်ဖို့ မသေချာပါဘူး။ ဒါပေမယ့်  ယိုပေါက်ဟာပေါက်တွေနဲ့ ခိုးယူတဲ့သူကို track လုပ်လို့ရတယ်။ တကယ်လို့ ခင်ဗျား customer က  တစ်ယောက်ယောက်ကို သူ့ ဆော့ဖ်၀ဲလ် license ပေးလိုက်တယ် ဆိုပါတော့။  Rှatermak ရှိတာ အဲဒီနေရာကျတော့ ကောင်းသွားရော။

၁၂။ Physical security၊ ဥပမာပြောရရင် dongle တွေပေါ့၊ စျေးကွက်မှာ သိပ်ခေတ်မစားသေးဘူးနော်။ သုံးစွဲသူကို စိတ်အနှောင့်အယှက်ပေးတဲ့ လုံခြုံရေးစနစ်တွေက မတွင်ကျယ်ဘူးလို့ ထင်တယ်။ လုံခြုံရေးစနစ်တွေက စိတ်အနှောင့်အယှက် ဖြစ်ချင်စရာကောင်းနေဖို့ လိုလို့လား။ ဥပမာ driver တွေ install လုပ်ခိုင်းတာမျိုး၊ register လုပ်ဖို့ လိုအပ်ချက်တွေ တောင်းတာနဲ့ dongle တွေပေါ့။ လုံခြုံရေးစနစ်တွေက ပိုပြီး မြင်သာထင်သာ ရှိသင့်တယ်မလား။ ဥပမာ – Fingerprint လို၊ online key validation လိုမျိုး။
- ဟုတ်ကဲ့၊ dongle တွေက ပေါ်ပြူလာတော့ မဖြစ်သေးပါဘူး။ Dongle တွေကို စက်မှာ တပ်ပြီး သုံးနေရတာဟာ တစ်ချို့ user တွေအတွက်တော့ ဖိအားဖြစ်စေတယ်။ အခုတော့ နည်းနည်းလေး တိုးတက်လာပါပြီ။ USB port မှာ သုံးလို့ ရနေပြီလေ။ အရင်က parallel port တွေတုန်းကတော့ တကယ် အလုပ်ရှုပ်ခဲ့တာပဲ။ Program တစ်ခုချင်းစီအတွက် တစ်ခုစီ တပ်နေရသေးတယ်။  ဒါကြောင့် နေရာ လိုအပ်ချက်က စိန်ခေါ်မှု တရပ် ဖြစ်လာတယ်။
- ကျွန်တော်လည်း လုံခြုံရေးစနစ်တွေက စိတ်အနှောင့်အယှက်ပေးတာ မကြိုက်ပါဘူး။ ကျွန်တော်တို့ Armadillo ကနေ registration မှာ key ကို auto ထည့်ပေးနိုင်တဲ့ project မျိုး လုပ်ပေးနိုင်တယ်။ End user တွေအတွက် သက်သာစေတာပေါ့။ ဒါက လူများစုအတွက် အဆင်ပြေတယ်။
- Online key validation က အလုပ်ရှုပ်စေတယ်။ အင်တာနက် သုံးဖို့လိုတဲ့အပြင် သုံးစွဲသူတွေကလည်း ရှုပ်တယ်လို့ မြင်ကြတယ်။ Rှeb server ကို ဘယ်နေ့ နေ့စွဲနဲ့ ၀င်သွားတယ်ဆိုတာ ဘယ်သူသိနိုင်မှာလဲ။ လူများစုကလည်း အဲဒါကို spyware လိုလို ထင်ကြသေးတယ်။
- လုံခြုံရေးစနစ်က အလုပ်ရှုပ်စေတာ မကောင်းဘူး။ ဒါပေမယ့် အလုပ်ရှုပ်စေတဲ့ စနစ်တွေက ပိုပြီး ကောင်းတယ်လို့ ထင်တယ်။ အချိန်က စကားပြောပါလိမ့်မယ်။ သုံးစွဲသူတွေ ဒါကိုလက်ခံဖို့ အဆင်သင့်ဖြစ်တဲ့ အချိန်ကျရင်ပေါ့။

၁၃။ ကုမ်ပဏီတွေက ဆော့ဖ်၀ဲလ် security တွေနဲ့ပတ်သက်လို့ အသိပညာပိုင်း အားနည်းနေသေးတယ်လို့ ထင်သလား။ ဒါက နောက်ပိုင်းမှ စဉ်းစားရမှာပါဆိုတဲ့ အတွေးကို ကိုင်စွဲထားပြီးတော့လေ။
- အမှန်ပဲ။ Microsoft လို နည်းပညာဘီလူးကြီးကိုပဲကြည့်။ ခင်ဗျားမြင်ဖူးတဲ့ မြောက်များစွာသော OS install စီဒီပွားတွေကိုပဲ စဉ်းစားတော့။ ကျွန်တော့် အမြင်တော့ သူတို့ security မညံ့ဘူး။ ကုမ်ပဏီကြီးတွေကျတော့ အဲဒါကို ဘယ်တော့မှ မစဉ်းစားခဲ့တာ၊ နောက်ပြီး ကုန်ကျစရိတ် တစ်ခုလို သဘောထားတာ။ Shareware သမားတွေကျတော့ ဒါကို တကယ်ကို တွန်းအားပေးတာ။ သူတို့ အသက်သွေးကြောက အွန်လိုင်းပေါ်ကနေ စကားပြော ရောင်းရတာလေ။ တကယ်လို့ မရောင်းရတော့ဘူးဆိုရင် စီးပွားပျက်မှာပဲ။ ကုမ်ပဏီကြီးတွေကလည်း အခုတော့ သဘောပေါက်လာပါပြီ။ ကျွန်တော့်အလုပ်ရှင် Digital River ကုမ်ပဏီဆိုရင် အခု Digital Rights Management စနစ်ကို ပရိုမိုးရှင်းလုပ်တော့ security က အဓိကနေရာက ပါ၀င်နေပြီ။

၁၄။ Developer တွေဟာ ဆော့ဖ်၀ဲလ်ဖန်တီးမှုနဲ့ လုံခြုံရေးစနစ်တို့ အချိုးညီပေါင်းစပ်နိုင်ဖို့ သူတို့ဆော့ဖ်၀ဲလ်ကို ဘယ်လို အကာအကွယ်တွေ လုပ်ရမလဲဆိုတာ သိထားဖို့ လိုသလား။ သူတို့ရဲ့ resource တွေ ဘာတွေဖြစ်တယ်၊ API call တွေက ဘယ်ကို redirect လုပ်တယ်၊ child process ဘာကြောင့် ဖန်တီးရတယ်ဆိုတာမျိုးကို သိဖို့လိုလား။
- လိုသလားမေးရင် မလိုလောက်ပါဘူး။ ဒါပေမယ့် developer တစ်ယောက်အနေနဲ့ ဘာတွေဖြစ်နေတယ်ဆိုတာကို နားလည်နိုင်သလောက်အထိ နားလည်ချင်တယ်။ ဒါပေမယ့် အဲဒါက bug တွေပြင်ဖို့လောက်ပဲ အသုံး၀င်တာပါ။

၁၅။ ခင်ဗျားအကြိုက်ဆုံး programming language တစ်ခုကို ပြောပြပါလား။ လုံခြုံမှှုရှိတဲ့ code တွေ ဖန်တီးနိုင်မယ်လို့ရော ထင်သလား။
- ကျွန်တော်သဘောကျတာတော့ C ပဲ။ ဒါကလည်း ကျွန်တော် နှစ်ပေါင်းများစွာ သုံးလာလို့ပါ။ လုံခြုံမှှုရှိသလားဆိုတော့ မရှိပါဘူး။ စျေးကွက်ထဲမှာ C ကို disassemble လုပ်နိုင်တဲ့ tool တွေက တခြားဟာတွေထက်တောင် များသေးတယ်။ Assembly က တချို့လှည့်ကွက်ကလေးတွေရယ်၊ lower level ကုဒ်တွေကတော့ cracker တွေကို ပိုပြီး လွယ်လွယ်ကူကူ လှည့်စားနို်င်ပါတယ်။ ဒါကြောင့် ဒါတွေကိုပဲ အလုံခြုံဆုံးလို့ ပြောရမယ်။ နောက်ပြီးတော့ programmer က လုံခြုံမှုကို မစဉ်းစားဘဲ ရေးသားရင် language က ဘာမှမထူးဘူး။
- တစ်ကိုယ်ရေ ဆုံးဖြတ်ချက်နဲ့ သဘောကျတာကတော့ Assembly ပဲ။ ကျွန်တာ်က ရေးလိုက်သမျှ အားလုံးကို ထိန်းချုပ်ချင်တယ်။ နောက်ပြီး fancy code flow တွေကိုသုံးပြိီး စနစ်တကျဖြစ်အောင် ခက်ခက်ခဲခဲရေးနိုင်တယ်။  ဒါဆို လုံခြုံတဲ့ ကုဒ်ဆိုတာ ဘာလဲ။ Programmer ရဲ့အရည်အချင်းပေါ်မှာ မူတည်တယ်။ ဘယ် language မဆို သေသေချာချာ စနစ်တကျရေးထားရင် လုံခြုံတာပဲ။

၁၆။ ပေါ်ပြူလာဖြစ်တဲ့ ဆော့ဖ်၀ဲလ်တွေကို ကာကွယ်မှု ထပ်ပေါင်းထည့်ပေးခြင်းဟာ အကျိုးရှိတယ်လို့ ထင်လား။ ဒါမှမဟုတ် သူတို့ရဲ့ ပေါ်ပြူလာဖြစ်မှုက အကာအကွယ်တွေကို ချိုးဖောက်ချင်စရာ ကောင်းနေမလား။ ဒါကြောင့် လုံခြုံရေးစနစ်တွေက ကုမ်ပဏီအသေးလေးတွေမှာပဲ ပိုအရေးကြီးနေသလား။
- အကျိုးရှိတယ်လို့ ထင်ပါတယ်။ တစ်ခါမှ အဆင့်မRင့်တင်ခြင်း မလုပ်ခဲ့တဲ့ program တစ်ခု အတိုက်အခိုက်ခံရတယ် ဆိုတဲ့ အဖြစ်အပျက်ဟာ ဆိုး၀ါးပါတယ်။ ဒါပေမယ့် ဖြစ်နိုင်ခြေ ရှားတယ်။ Version 1.0 မှာ အတိုက်အခိုက်ခံရရင် နောက် Version 2.0 ကျရင် လုံခြုံရေးစနစ် ဆော့ဖ်၀ဲလ်ရော မူလ program ကိုပါ ပြန်လည် ပြင်ဆင်ကြမှာပါ။
- Cracker က အချိန်ကုန်ခံပြီး တိုက်ခိုက်ဖို့ ကြိုးစားတယ်ဆိုရင် ခင်ဗျား program ပေါ်ပြူလာဖြစ်တယ်ဆိုတဲ့ သဘောပေါ့ဗျာ။
- နောက်ပြီး ကုမ်ပဏီအသေးလေးတွေမှာလည်း ကျယ်ကျယ်ပြန့်ပြန့် ဖြန့်ဖြူးရောင်းချနေတဲ့ program တွေရှိရင် လုံခြုံရေးအတွက် အစီအမံတွေ ရှိသင့်တယ်။ ၀င်ငွေဆုံးရှုံးတာရယ် နည်းပညာ အခိုးခံရတာတွေက ဆိုင်သေးသေးလေးတွေကို ဖြုတ်ပစ်နိုင်တယ်။

၁၇။ နောက်ထပ် ဘာများထပ်ဖြည့်ချင်သေးသလဲ။
- ကျွန်တော် စဉ်းစားလို့ ရသမျှကို ပြောမယ်လေ။

“Interview with Armadillo Developers” ကို wannar ဘာသာပြန်ဆိုသည်။

Strategic Code Splicing = Dump မလုပ်နိုင်အောင် တားဆီးသည့် နည်းလမ်းတစ်ခု။ (Dump လုပ်ခြင်းဆိုသည်မှာ ဆော့ဖ်ဝဲလ်တစ်ခုခု၏ အကူအညီဖြင့် မှတ်ဥာဏ်ထဲတွင် decrypt/unpack လုပ်ထားသော ကုဒ်များကို exe ဖိုင် အနေဖြင့် သိမ်းဆည်းခြင်းဖြစ်သည်။) Strategic Code Splicing က သင်၏ ကုဒ်များကို ဖယ်ထုတ်လိုက်ပြီး မှတ်ဥာဏ်၏ နေရာအနှံ့အပြားတွင် သွားထားလိုက်သည်။ ကုဒ်များကိုလည်း ပြောင်းလဲပစ်လိုက်သည့်အတွက် အလုပ်လုပ်ပုံမှာ တူညီမည်ဖြစ်သော်လည်း ကုဒ်များမှာမူ ပြောင်းလဲသွားမည်ဖြစ်သည်။

Import Table Elimination = Dump မလုပ်နိုင်အောင် တားဆီးသည့် နောက်ထပ် နည်းလမ်းတစ်ခု။ ပရိုဂရမ်၏ import table ကို ဖယ်ရှားဖျက်ဆီးလိုက်သည့်အတွက် import များကို ပြန်လည်တည်ဆောက်ရာတွင် အခက်တွေ့စေမည်ဖြစ်ပါသည်။

Memory-Patching Protection = Cracker များက loader ရေးပြီး မှတ်ဥာဏ်ထဲမှ ကုဒ်များကို patch လုပ်ခြင်းမှ ကာကွယ်တားဆီးသသည့် နည်းလမ်း။

Nanomites = Dump လုပ်ခြင်းကို တားဆီးသည့် အဆင့်မြင့်နည်းလမ်းဖြစ်ပြီး Jump အချို့ကို INT3 function ဖြင့် အစားထိုးသည်။ ဖယ်ရှားခံလိုက်ရသည့် JUMP instruction များနှင့် ပတ်သက်သည့် အချက်အလက်များကို သေသေချာချာ encrypt လုပ်ထားသည့် table ထဲတွင် သိမ်းဆည်းပါသည်။

Child process = Process တစ်ခုအောက်တွင် အလုပ်လုပ်သော နောက် process တစ်ခု။ Armadillo တွင် Child process သည် မိခင် process အား debug လုပ်ခံထားရခြင်း ရှိ၊ မရှိကို အမြဲစစ်ဆေးလေ့ရှိသည်။

Checksum = Image ဖိုင် (EXE ဖိုင်)အား တွက်ချက်ထားသည့်တန်ဖိုး။ ဒေတာများကို သိမ်းဆည်းရာတွင် အမှားများ ကြုံတွေ့ခြင်း ရှိ၊ မရှိ တွက်ချက်ထားသော တန်ဖိုးဖြစ်ပြီး exe ဖိုင်ထဲတွင်ပင် သိမ်းဆည်းသည်။ Exe ဖိုင်ကို patch လုပ်ခဲ့လျှင် HEX တန်ဖိုးများ ပြောင်းသွားပြီး checksum တန်ဖိုးလည်း ပြောင်းသွားတတ်သည်။

Watermark = ထင်သာမြင်သာရှိသော watermark နှင့် ဖျောက်ထားသော watermark ဟူ၍ နှစ်မျိုးရှိသည်။ ဆော့ဖ်၀ဲလ်များကို ခိုးသုံးခြင်းမှ ကာကွယ်ရန် အသုံးပြုသည်။ Armadillo ၏ hidden watermark သည် encrypted string အနေဖြင့် တည်ရှိနေပြီး ပရိုဂရမ်ကို unpack လုပ်ရာတွင် ၎ကို ဖယ်ရှားနိုင်ရန် အရေးကြီးသည်။ မဖယ်ရှားနိုင်ပါက watermark အလုပ်လုပ်သည့်အတွက် Anti-virus များက ထိုဖိုင်ကို ဗိုင်းရပ်စ်အနေဖြင့် မြင်တတ်သည်။ အချို့ watermark များသည် user နှင့်ပတ်သက်သော အချက်အလက်များကို တိတ်တဆိတ် ထည့်သွင်းထားသည့်အတွက် မိမိဆော့ဖ်၀ဲလ်သည် အင်တာနက်တွင် ပျံ့နှံ့ခဲ့ပါက မိမိဆီမှ ပြန့်သွားကြောင်း ချက်ချင်းသိရှိနိုင်သည်။

Fingerprint = CPU ID၊ BIOS ID၊ Hard disk၊ Motherboard ID စသည်တို့ကို ဖတ်ရှုပြီး Hardware ID အဖြစ် ပြန်လည်တွက်ချက်ပေးသည့် registration နည်းလမ်း။

API Redirection = API redirection ဟူသည် packer/protector အများစုက IAT (သို့မဟုတ် import table) အား (တစ်စိတ်တစ်ဒေသ သို့မဟုတ် လုံး၀) ဖျက်ဆီးပစ်လိုက်သော လုပ်ဆောင်ချက်တစ်ခုဖြစ်သည်။ IAT ထဲတွင် redirect အလုပ်ခံရသော API အသီးသီး၏ သက်ဆိုင်ရာ ကုဒ်နှင့်ဆိုင်သော pointer တစ်ခုကို ရေးလိုက်သည်။ ဆိုလိုသည်မှာ packer သည် pack/protect လုပ်ထားသော ပရိုဂရမ်အတွက် system ၏ DLL များထဲမှ API ၏ address ကို ပေးနိုင်ရန် သတိထားရမည်ဖြစ်သည်။

Source: http://myanmarcrackingteam.blog.com

]]> http://tech4mm.com/2011/12/interview-with-armadillo-developer/feed/ 0 Java ၏ထူးခြားချက်များ http://tech4mm.com/2011/10/java-%e1%81%8f%e1%80%91%e1%80%b0%e1%80%b8%e1%80%81%e1%80%bc%e1%80%ac%e1%80%b8%e1%80%81%e1%80%bb%e1%80%80%e1%80%ba%e1%80%99%e1%80%bb%e1%80%ac%e1%80%b8/ http://tech4mm.com/2011/10/java-%e1%81%8f%e1%80%91%e1%80%b0%e1%80%b8%e1%80%81%e1%80%bc%e1%80%ac%e1%80%b8%e1%80%81%e1%80%bb%e1%80%80%e1%80%ba%e1%80%99%e1%80%bb%e1%80%ac%e1%80%b8/#comments Mon, 10 Oct 2011 16:02:34 +0000 MinLwin http://tech4mm.com/?p=323

အခြေခံ အယူအဆ

Java ပရိုဂရမ်မင်းဘာသာရပ်သည် အောက်ပါ အခြေခံအယူအဆ ၅ချက် အပေါ်တွင် မှုတည်၍ တည်ဆောက်ခဲ့ကြပါသည်။

  • ဝတ္တစက္ခုဗေဒ(Object Oriented) ၏ အယူအဆကို ကျင့်သုံးရန်
  • မတူညီသောOperating Systemများအပေါ်တွင်၊ တစ်ခုတည်းသောပရိုဂရမ်ဖြင့် အလုပ်လုပ်နိုင်စေရန်
  • ကွန်ပျူတာကွန်ယက်ကို အသုံးပြုနိုင်သည့် ဖန်ရှင်များကို အခြေခံအနေဖြင့် ပြင်ဆင်ထားနိုင်ရန်
  • အဝေးရောက် ကွန်ပျူတာအပေါ်ရှိ အသုံးချကုဒ်များကို လုံခြုံစွာ အသုံးချနိုင်ရန် ဒီဇိုင်းရေးသားနိုင်ရန်
  • ရေးသားမှု့ကို လွယ်ကူစေရန်အတွက်၊ ရှိပြီးသား C++ များကဲ့သို့ဝတ္တစက္ခုဗေဒ(Object Oriented) ပရိုဂရမ်မင်း ဘာသာရပ်များမှ ကောင်းသောအချက်များကို လက်ခံရယူရန်

ကွန်ယက်နည်းပညာနှင့် အဝေးရောက်ကွန်ပျူတာအသုံးချနည်းပညာများကို အသုံးပြုရာတွင် အခြေအနေအပေါ်တွင်မှုတည်၍၊ Javaပရိုဂရမ်မာများသည်၊CORBA နှင့် Internet Communications Engine၊ OSGi များကဲ့သို့ နည်းပညာများကိုလည်း အသုံးပြုကြပါသည်။

ဝတ္တစက္ခုဗေဒ ပရိုဂရမ်မင်း

Java သည်ကလပ်စ်ကို အခြေခံသော ဝတ္တစက္ခုဗေဒ(Object Oriented) ပရိုဂရမ်မင်း ဘာသာရပ် တစ်ခု ဖြစ်၏။ Java ပရိုဂရမ်သည် ကလပ်စ်များဖြင့် ဖွဲ့စည်းထားပြီး၊ ထိုကလပ်စ်များကို ပုံစံသွင်းထားသော Object များက အချင်းချင်း ဆက်သွယ်လုပ်ဆောင်ခြင်းအားဖြင့် Java ပရိုဂရမ်များကို အလုပ်လုပ်စေပါသည်။ Java ကလပ်စ်များသည် အမွေဆက်ခံရာတွင် တစ်ခုသော ကလပ်စ်မှသာ အမွေဆက်ခံနိုင်ပြီး၊ အင်တာဖေစ်ကို တစ်ခုမက ပံ့ပိုးပေးထားနိုင်ပါသည်။ အမွေဆက်ခံခြင်း(Inheritance)ဆိုသည်မှာ ကလပ်စ်တစ်ခုကို တည်ဆောက်ရာတွင် အခြားကလပ်စ်တစ်ခုအား စူပါကလပ်စ်အနေဖြင့် သတ်မှတ်ထားပါက၊ စူပါကလပ်စ်က ပိုင်ဆိုင်သော အချက်အလက်များနှင့်၊ လုပ်ဆောင်ချက်များကို အသုံးပြုနိုင်ခြင်းကို ဆိုလိုပါသည်။ Java ဘာသာရပ်တွင် ကလပ်စ်တစ်ခုသည် စူပါကလပ်စ်တစ်ခုတည်းကိုသာ သက်မှတ်နိုင်သော်လည်း၊ အင်တာဖေစ်များကို တစ်ခုထက်မက ပံ့ပိုးပေးနိုင်သောကြောင့်၊ ကလပ်စ်တစ်ခုမှ အမျိုးမျိုးသော တာဝန်ကို ထမ်းဆောင်စေနိုင်ခြင်းဖြစ်၏။

Java တွင် အသုံးပြုသော အချက်အလက်များ၏ ပုံစံသည်၊ တိကျသောငြိမ်သက်ပုံစံ(Strong Static Type)ကို အသုံးပြုထားပါသည်။ ငြိမ်သက်သော အချက်အလက်ပုံစံကို အသုံးပြုထားခြင်းအားဖြင့် Java ကွန်ပိုင်လာနှင့် အသုံးပြု ပတ်ဝင်းကျင်(ပလက်ဖေါင်း)သည်၊ ပုံစံအချင်းချင်း၏ ဆက်စပ်မှု့မှန်ကန်ခြင်းကို စမ်းစစ်ခြင်းအားဖြင့်၊ ပရိုဂရမ်၏ မှန်ကန်စွာအလုပ်လုပ်နိုင်ခြင်းနှင့်၊ လုံခြုံစိတ်ချစွာ အလုပ်လုပ်နိုင်မှု့ကို အာမခံပေးနိုင်ခြင်းဖြစ်၏။

Java ၏ ဒေတာပုံစံသည်၊ ကိုးကားပုံစံ（reference type）နှင့် ကနဦးပုံစံ（primitive type）ဟု နှစ်မျိုးခွဲခြားနိုင်၏။ Java ၏ Object များသည် ကိုးကားပုံစံများဖြစ်ကြ၏။ Java တွင် အသုံးပြုနေသော အချက်အလက်များ၏ အခြေခံပုံစံသည်၊ ရိုးရှင်းသော အချက်အလက်（int, boolean, char …) ပုံစံများဖြစ်ကြ၏။ Java ၏ စနစ်ကျလိုင်ဘရီသည်၊ အခြေခံပုံစံအချက်အလက်များကို Object အဖြစ် အသုံးပြုနိုင်စေရန် အတွက် အခြေခံအချက်အလက်များကို ခြုံငုံထားသော Wrapper Class များကို ပြင်ဆင်ထား၏။ Java（J2SE 5.0）အရောက်တွင် အချက်အလက်ပုံစံများ၏ ပြုပြင်ပြောင်းလည်းမှု့များကို ပြုလုပ်ထားပါသည်။

  • Java ၏ ကွန်ပိုင်လာသည် ကနဦးပုံစံအချက်အလက်များနှင့် သူ၏ Wrapper Class အကြားတွင် အလိုအအလျှောက် ပုံစံပြောင်းပေးနိုင်ပါသည် (Auto Boxing)။ ဤနည်းအားဖြင့် ကိုးကားပုံစံနှင့် ကနဦးပုံစံ ဟူ၍ အချက်အလက်ပုံစံ ၂မျိုး တည်ရှိခြင်းကြောင့် ဖြစ်ပေါ်စေသော Java ၏ ရှုပ်ထွေးမှု့များကို သက်သာစေနိုင်ပါသည်။
  • Genericsကို အသုံးပြုလာနိုင်၏။ ပရိုဂရမ်ထဲတွင် ပုံစံပြောင်းခြင်း အလုပ်ကို သက်သာစေပြီး၊ မလိုအပ်သော အမှားများကိုလည်း နည်းပါးစေနိုင်၏။ Generics သည် ယခင်ကတည်းကC++ ကဲ့သို့သော ပရိုဂရမ်မင်းဘာသာရပ်များတွင် အသုံးပြုနေခဲ့သော နည်းပညာတစ်ခုဖြစ်၏။

Java ၏ ထူးခြားချက်တစ်ခုဖြစ်သော ဝတ္တစက္ခုဗေဒ(Object Oriented)သည်၊ ပရိုဂရမ်မင်းနှင့် ပရိုဂရမ်မင်းဘာသာရပ်ဖွဲ့စည်းပုံ များ၏ နည်းစနစ်တစ်မျိုးဖြစ်၏။ Java သည် ဝတ္တစက္ခုဗေဒပရိုဂရမ်မင်း ဘာသာရပ် တစ်မျိုးဖြစ်၏။ ဝတ္တစက္ခုဗေဒ၏ အတွေးအခေါ်နှင့် ပတ်သက်ပြီး၊ အဓိပ္ပါယ်ဖွင့်ဆိုချက်ပေါင်း များစွာရှိကြ၏။ အများအားဖြင့် ဝတ္တစက္ခုဗေဒ၏ ထင်ရှားချက်ကိုသတ်မှတ်ရာတွင် ဆော့ဖ်ဝဲတွင် အသုံးပြုသော အမျိုးမျိုးသော အချက်အလက်များနှင့်ပတ်သက်၍၊ အချက်အလက်နှင့် ထိုအချက်အလက်များနှင့်ပတ်သက်သော လုပ်ဆောင်ချက်များကို တနေရာတည်းတွင် ပူးတွဲထားပြီး၊ ဆော့ဖ်ဝဲကို ဒီဇိုင်းရေးသားခြင်းပင်ဖြစ်၏။ ဤကဲ့သို့ အချက်အလက်နှင့် ကုဒ်တို့ကို ပူးတွဲထားသည်ကို၊ Objectဟုခေါ်ဆိုပါသည်။ Object ဆိုသည်မှာ၊ အနေအထားကို ဖော်ပြသော အချက်အလက်များနှင့်၊ လုပ်ဆောင်မှု့များကိုပြုလုပ်နိုင်သော ကုဒ်တို့က တနေရာတည်းမှာ စုစည်းထားသော အစုအဝေးတစ်ခုဟု သတ်မှတ်နိုင်ပေသည်။

Java တွင် Object တစ်ခု၏ဖွဲ့စည်းပုံကိုဖေါ်ပြသော မြေပုံကြမ်း(Blue Print) တစ်ခုဖြစ်သော ကလပ်စ်တွင် လုပ်ဆောင်ချက်များကို မက်သတ်ဟုခေါ်ဆိုပြီး၊ အချက်အလက်များကို Fields (Instance Variable) ဟုခေါ်ဆိုပါသည်။

Object Oriented မတိုင်မှီတွင် အသုံးပြုခဲ့သော နည်းပညာများတွင် အချက်အလက်နှင့် လုပ်ဆောင်ချက်များသည် တစ်နေရာစီတွင် တည်ရှိခဲ့ကြ၏။

  • အချက်အလက်ဖွဲ့စည်းပုံကို ပြုပြင်ပြောင်းလည်းလိုပါက၊ ထိုအချက်အလက်ကို အသုံးပြုနေသော အခြားတနေရာတွင်ရှိသည့် လုပ်ဆောင်ချက်များကိုလည်း ပြုပြင်ပြောင်းလည်းရန်လိုအပ်ပါသည်။
  • တဖန် လုပ်ဆောင်ချက်ကို ပြောင်းလည်းပါက၊ အချက်အလက်ဖွဲ့စည်းပုံကိုလည်း ပြောင်းလည်းရန်လိုအပ်ခဲ့၏။

ဝတ္တစက္ခုဗေဒ အတွေးအမြင်ကို အခြေပြုပြီး၊ ယနေ့တိုင် တနေရာစီတွင် တည်ရှိခဲ့သော အချက်အလက်နှင့် လုပ်ဆောင်ချက်များအား၊ Object အနေဖြင့် တစ်နေရာတည်းတွင် စဉ်းစားလာနိုင်ခြင်းသည်၊ ဆော့ဖ်ဝဲစစ္စတမ်များ၏ ဖွဲ့စည်းပုံကို ဒီဇိုင်းရေးသားရာတွင် လွန်စွာမှအစဉ်ပြေသော အခြေခံတစ်ခုဖြစ်လာခဲ့၏။ ဝတ္တစက္ခုဗေဒ ကို အသုံးပြုခြင်းအားဖြင့် ပမာဏကြီးမားသော စစ္စတမ်များကို ရေးသားရာတွင် ဖြစ်ပေါ်လေ့ရှိသော အခက်အခဲများကို လျှော့ပါးစေခြင်း၊ ဆော့ဖ်ဝဲ၏ အရည်အသွေးကို မြင့်မားစေခြင်းနှင့် မအောင်မြင်သော ပရိုဂျက်များကို နည်းပါးစေခြင်း အစရှိသော အကျိုးများကို ရရှိစေနိုင်ပါသည်။

ဝတ္တစက္ခုဗေဒ ၏ အခြားသော ရည်မှန်းချက် တစ်ခုမှာ နေရာ အမျိုးမျိုးတွင် အသုံးပြုနိုင်သော Object များကို ရေးသားခြင်းအားဖြင့်၊ ပရိုဂျက်များအကြားတွင် ဆော့ဖ်ဝဲများကို ပြန်လည်အသုံးပြုနိုင်ခြင်း ပင်ဖြစ်၏။ ဥပမာအားဖြင့်၊ User Object တစ်ခုသည်၊ အခြားသော ပရိုဂျက်တစ်ခုတွင်လည်း တူညီစွာအသုံးပြုနိုင်မည် ဖြစ်၏။ ကြီးမားသော အဖွဲ့အစည်းကြီးများတွင်၊ ပရိုဂျက်အမျိုးမျိုးတည်ရှိကြပြီး ထိုပရိုဂျက်များတွင် အခြေခံ အလွှာတစ်ခုကို တူညီစွာအသုံးပြုရန်လိုအပ်ပါက ပြန်လည်အသုံးပြုနိုင်သော ဆော့ဖ်ဝဲများသည် လွန်စွာမှအရေးကြီးလာပါသည်။ ဤကဲ့သို့ နေရာအမျိုးမျိုးတွင် အသုံးပြုနိုင်သော အခြေခံ ဆော့ဖ်ဝဲများကို ပြင်ဆင်ထားခြင်းအားဖြင့်၊ ဆော့ဖ်ဝဲများကို ရေးသားရာတွင် ရေးသားရန်လိုအပ်သော အချိန်ကို လျှော့ပါးစေပါသည်။

ပလက်ဖေါင်းအပေါ်တွင် မှီခိုမှု့ မရှိခြင်း

Java ထူးခြားချက်နောက်တစ်ခုမှာ ပလက်ဖေါင်းတွင် မှီခိုမှု့မရှိခြင်း ဖြစ်ပြီး၊ Java ပရိုဂရမ်များသည် အမျိုးမျိုးသော ဟဒ်ဝဲနှင့်Operating Systemများအပေါ်တွင် အမြဲတမ်း တူညီစွာ လုပ်ဆောင်မှု့ကို ပြနိုင်သည်ဟု ဆိုလိုခြင်းဖြစ်၏။ Java ပရိုဂရမ်ကို တစ်ကြိမ်ရေးသားပြီးပါက၊ ထိုပရိုဂရမ်ဖြင့် အမျိုးမျိုးသော ပလက်ဖေါင်းအပေါ်တွင် အလုပ်လုပ်စေ နိုင်ပါသည်။ ယခုနောက်ပိုင်းနှစ်များတွင် Java အသုံးပြုပတ်ဝင်းကျင်တွင် ပါဝင်သော Java ဒြပ်မဲ့စက် သည် အမြန်အလုပ်လုပ်စေနိုင်သည့် နည်းပညာကို ထည့်သွင်းလာနိုင်ခဲ့ပြီး၊ ပလက်ဖေါင်းကို မှီခိုသော သဘာဝပရိုဂရမ်မင်းဘာသာရပ် များကဲ့သို့ပင် လျှင်မြန်စွာ အလုပ်လုပ်နိုင်လာခဲ့၏။

Java သည် ပလက်ဖေါင်းအပေါ်တွင် မှီခိုမှု့မရှိသည်မှာ အောက်ပါအကြောင်းများကြောင့် ဖြစ်၏။

  • Java ကွန်ပိုင်လာအတော်များများသည်၊ Java ၏ ပင်ရင်းကုဒ်များကို ကြားခံဘာသာအနေဖြင့် ကွန်ပိုင်းလုပ်ပေးပါသည်။ ထို Java ကြားခံဘာသာစကား ကုဒ်များကို Java ဘိုက်ကုဒ်ဟုခေါ်ဆိုပါသည်။ ဘိုက်ကုဒ်များသည်Java ဒြပ်မဲ့စက်တွင် အလုပ်လုပ်နိုင်သော စက်ဘာသာအမိန့်ပေး စာကြောင်းများ ဖြင့် ဖွဲ့စည်းသားပါသည်။
  • Java ပရိုဂရမ်ကို အလုပ်လုပ်စေရာတွင်၊ အထက်ပါ ဘိုက်ကုဒ်အား Java ဒြပ်မဲ့စက်အပေါ်တွင် အလုပ်လုပ်စေခြင်းဖြစ်၏။ Java ဒြပ်မဲ့စက်သည် အလုပ်လုပ်မည့် ဟဒ်ဝဲ၏ သဘာဝ ဆော့ဖ်ဝဲတစ်မျိုးဖြစ်ပြီး ဘိုက်ကုဒ်ဖြင့် ရေးသားထားသည်များကို နားလည်ရင်း အလုပ်လုပ်စေနိုင်ခြင်း ဖြစ်သည်။
  • Java ပတ်ဝင်းကျင်တွင်၊ Java ဒြပ်မဲ့စက် အပြင် အခြားသော အခြေခံလိုင်ဘရီကိုလည်း ပြင်ဆင်ထား၏။ ထိုအခြေခံ လိုင်ဘရီကို အသုံးပြုခြင်းအားဖြင့် Java ပရိုဂရမ်များမှ ဂရပ်ဖစ်၊ Thread နှင့် Network အစရှိသည့် ဟဒ်ဝဲ၏ လုပ်ဆောင်ချက်များကို နည်းလမ်း တစ်ခုတည်းဖြင့် ရေးသားအသုံးပြု နိုင်ပါသည်။ ပလက်ဖေါင်းအပေါ်တွင်မှုတည်၍ ပြောင်းလည်းရေးသားရန် မလိုအပ်ပေ။
  • Java ဘိုက်ကုဒ်များကို အလုပ်လုပ်စေရာတွင် Java ဒြပ်မဲ့စက်သည်၊ ဟဒ်ဝဲ၏ သဘာဝ စက်ဘာသာကုဒ်များအဖြစ်ပြောင်းလည်းပြီး အလုပ်လုပ်စေပါသည်။ ဘိုက်ကုဒ်များဟ စက်ဘာသာကို ပြောင်းလည်းရာ၌ Java ဒြပ်မဲ့စက်သည် အင်တာပရက်တာကို၎င်း၊ Just In Time ကွန်ပိုင်းလာကို၎င်း သင့်တော်သလို အသုံးချပါသည်။

တဖန်GNU၏GNU Compiler for Java (GCJ) ကဲ့သို့ Java ပင်ရင်းကုဒ်များမှ တိုက်ရိုက် စက်ဘာသာအဖြစ် ပြောင်းလည်း ပေးနိုင်သော ကွန်ပိုင်လာများလည်း ရှိကြ၏။ သို့ရာတွင် ဤနည်းဖြင့် ကွန်ပိုင်းလုပ်ထားသော ပရိုဂရမ်များသည် ကွန်ပိုင်းလုပ်စဉ်က အသုံးပြုထားသော ပလက်ဖေါင်းများအပေါ်၌သာ အလုပ်လုပ်နိုင်ပါသည်။

ယခုနောက်ပိုင်းနှစ်များတွင် Ruby（JRuby）နှင့် Groovy ၊Jabaco ၊Python（Jython） အစရှိသည့် ဘာသာစကားဖြင့် ရေးသားထားသော ပရိုဂရမ်များကို ဘိုက်ကုဒ်အဖြစ် ကွန်ပိုင်းလုပ်ခြင်းအားဖြင့် Java ဒြပ်မဲ့စက် အပေါ်တွင် အလုပ်လုပ်စေသည့် နည်းလမ်းများကိုလည်း တွေလာရပါသည်။

အမှိုက်သိမ်းစနစ်

Java သည် အမှိုက်သိမ်းစနစ်(Garbage Collection)ဟုခေါ်သော အလိုအလျှောက် မံမိုရီထိမ်းသိမ်းရေးစနစ်ကို ပြင်ဆင်ထားပြီး၊ ထိုစနစ်ကို အသုံးမပြုသော အခြားသော ဘာသာရပ်များ နှင့်နှိုင်းယှဉ်လျှင် ပရိုဂရမ်ရေးသားရာတွင် လွယ်ကူမြန်ဆန်ပြီး၊ စိတ်ချစွာအလုပ်လုပ်စေနိုင်၏။ နောက်ပိုင်းနှစ်များတွင် Java ၌ သက်တမ်းအလိုက် အမှိုက်သိမ်းစနစ် (Generational Garbage Collection) ဟုအမည်ရသော ပိုမို၍ အကျိုးရှိစွာအသုံးချနိုင်သော နည်းပညာအသစ်ကို ထည့်သွင်းအသုံးပြုလာခဲ့၏။

အမှိုက်သိမ်းစနစ်ကို အသုံးမပြုထားသော C++ နှင့် အခြားသော ဘာသာရပ်များကို အသုံးပြုရာတွင်၊ ပရိုဂရမ်မာမှ မံမိုရီကို တိုက်ရိုက် ထိမ်းသိမ်းရန်လိုအပ်ခဲ့၏။ OOP ကို အသုံးပြုသော ပရိုဂရမ်မာသည် ပုံမှန်အားဖြင့်၊ Java ကဲ့သို့ Heap မံမိုရီအတွင်းတွင် Object ကို နေရာချ၍ အသုံးပြုလေ့ရှိ၏။ ထိုမှတဆင့် Object ကို အသုံးမလိုတော့သောအခါ မဖြစ်မနေ ထို Object ကို ဖျက်စီးခြင်းအားဖြင့် Object က အသုံးပြုနေသော မံမိုရီကို ပြန်ပြီး လက်လွှတ်ပေးရန် လိုအပ်ပါသည်။ မံမိုရီထိမ်းသိမ်းရေးတွင် အားနည်းသော ပရိုဂရမ်သည် မံမိုရီယိုစီးမှု့ကို ဖြစ်ပွားစေနိုင်၏။ မံမိုရီယိုစီးမှု့ဆိုသည်မှာ မသင့်တော်သော အမိန့်ပေးမှု့များကြောင့် အသုံးမလိုသော Object များမှ မံမိုရီကို ဆက်လက် နေရာယူထားပြီး၊ စုစည်းမိလာသောအခါ ပရိုဂရမ်မှ အသုံးပြုနိုင်သော မံမိုရီက တဖြည်းဖြည်းနည်းပါးလာခြင်းကို ဆိုလို၏။ ထို့အပြင် မံမိုရီကို လက်လွှတ်ချိန်တွင် အကြိမ်ကြိမ် Object ကို ဖျက်မိပါသဖြင့် ပရိုဂရမ်ကို မှားယွင်းစေပြီး ရုတ်တရက် အမှားဖြင့် ပြီးဆုံးသည့်အခါများလည်း ရှိတတ်၏။

အမှိုက်သိမ်းစနစ်ကိုအသုံးပြုခြင်း အားဖြင့် မလိုအပ်သော အမှားများကို ကြိုတင်ကာကွယ်နိုင်၏။ ပရိုဂရမ်မာသည် နှစ်သက်သည့်အချိန်တွင် Object ကို ခေါ်ယူ အသုံးပြုနိုင်ပြီး၊ Java ပတ်ဝင်းကျင်မှ ထို Object ၏ ဘဝစက်ဝိုင်း(Life Cycle)ကို ထိမ်းသိမ်းပေးနိုင်ပါသည်။

Object တစ်ခုသည် အခြားသော Object ကို ကိုးကားနိုင်ပြီး၊ ကိုးကားထားသည့် Object ၏ မက်သတ်များကို ခေါ်ယူအသုံးပြုနိုင်၏။ အခြားသော Object တစ်ခုကို ကိုးကားခြင်းဆိုသည်မှာ Heap မံမိုရီ အပေါ်တွင်ရှိသော Object ၏ လိပ်စာကိုရည်ညွှန်းခြင်းကို ဆိုလို၏။

Object တစ်ခုအား ဘယ်နေရာကမှ ကိုးကားခြင်း မပြုတော့ပါက၊ Java ၏အမှိုက်သိမ်းစနစ်သည် အသုံးပြုရန်မလိုသော Object ကို အလိုအလျှောက် ဖျက်စီးပေးခြင်းအားဖြင့် အလိုအပ်ပဲနေရာယူထားသော မံမိုရီများကို ပြန်လည် လွှတ်ထုတ်ပေးနိုင်၏။ ဤသို့ ပြုလုပ်ပေးခြင်းအားဖြင့် မလိုအပ်ပဲ နေရာယူထားသော မံမိုရီများက တဖြည်းဖြည့် စုစည်းပြီး ဖြစ်ပေါ်တက်သော မံမိုရီယိုယွင်းမှု့မှ ကာကွယ်ပေးနိုင်ပါသည်။

ကွန်ယက်နည်းပညာ

Java ၏ ပြည့်စုံသော လိုင်ဘရီကို အသုံးပြုခြင်းအားဖြင့်၊ ကွန်ပျူတာကွန်ယက်ကို အသုံးပြုသည့် ဆော့ဖ်ဝဲများကို လွယ်ကူစွာရေးသားနိုင်၏။ Java ၏ ကနဦးဗားရှင်းများမှစ၍၊ TCP/IP（IPv4） ကို အသုံးပြုနိုင်သော လိုင်ဘရီကို ပြင်ဆင်ထားပြီး၊ Network တွင် ဆော့ကက်ကို အသုံးပြုပြီး ဆက်သွယ်နိုင်သည့် ဆော့ဖ်ဝဲများကို လွယ်ကူစွာရေးသားနိုင်ခဲ့၏။ Java RMI ဒါမှမဟုတ် CORBA ၏ အဝေးရောက် Object (Remote Object)နည်းပညာကိုလည်း အခြေခံမှစ၍ အသုံးပြုနိုင်ခဲ့၏။ နောက်ပိုင်းနှစ်များတွင် အခြေခံ လိုင်ဘရီနှင့် မွန်းမံလိုင်ဘရီများကို အသုံးပြုခြင်းအားဖြင့် အမျိုးမျိုးသော ကွန်ယက် ပရိုတိုကောများကို အဆင့်မြင့်စွာ အသုံးပြုလာနိုင်ခဲ့၏။

  • FTP
  • HTTP
  • SMTP/POP/IMAP,NNTP
  • SSH, TLS/SSL
  • SMB

လက်ရှိတွင် IPv6 ကို လည်းအသုံးပြုလာနိုင်ခဲ့၏။

လုံခြုံရေးစနစ်

Java သည် ကနဦးဗားရှင်းများမှစ၍ အခြားကွန်ပျူတာတစ်ခုအပေါ်ရှိ အလုပ်လုပ်နိုင်သောကုဒ်（Java အပလတ်）ကို စိတ်ချစွာအသုံးချနိုင်ရန် ဒီဇိုင်းရေးသားခဲ့ပါသည်။

  • Java ဒြပ်မဲ့စက်၏ ဘိုက်ကုဒ်စစ်ဆေးရေးစနစ်ဖြင့်၊ Java အလုပ်လုပ်နိုင်သောကုဒ်များဖြစ်သည့် ဘိုက်ကုဒ်များ၏ ရေးသားပုံကို စစ်ဆေးနိုင်၏။
  • Java ပတ်ဝင်းကျင်၏ ကလပ်စ်လုဒ်ဒါစနစ်ဖြင့်၊ ကလပ်စ်များကို ခေါ်ယူရာတွင် ထိုကလပ်စ်၏ သတင်းအချက်အလက်များကို စမ်းစစ်၍ စိတ်ချမှု့ကို စစ်ဆေးနိုင်၏။
  • Java ပတ်ဝင်းကျင်၏လုံခြုံရေးမန်နေဂျာစနစ်ဖြင့်၊ Java အပလတ်သည် အသုံးပြုသူက ခွင့်ပြုထားသော နေရာများအပြင် အခြားသောပိုင်ဆိုင်မှု့များကို ခိုးဝှက်ဆက်သွယ်ခြင်းကို တားမြစ်ထားပါသည်။

Java ပတ်ဝင်းကျင်၏ မှုလသတ်မှတ်ချက်ဖြင့်၊ အဝေးရောက်ကွန်ပျူတာ တစ်ခုအပေါ်ရှိ အလုပ်လုပ်နိုင်သောကုဒ်များမှ၊ လိုကယ်ဖိုင်စစ္စတမ်ဆီသို့ ဆက်သွယ်ခြင်းနှင့်၊ လုဒ်လုပ်ခဲ့သော ဆာဗာအပြင် အခြားသောနေရာများနှင့် ဆက်သွယ်ခြင်းကို တားမြစ်ထားပါသည်။

လေးစားစွာဖြင့်
မင်းလွင်

]]> http://tech4mm.com/2011/10/java-%e1%81%8f%e1%80%91%e1%80%b0%e1%80%b8%e1%80%81%e1%80%bc%e1%80%ac%e1%80%b8%e1%80%81%e1%80%bb%e1%80%80%e1%80%ba%e1%80%99%e1%80%bb%e1%80%ac%e1%80%b8/feed/ 0 Basic Micro-controller Circuit (Pic 18*) – 1 http://tech4mm.com/2011/09/basic-micro-controller-circuit-pic-18-1/ http://tech4mm.com/2011/09/basic-micro-controller-circuit-pic-18-1/#comments Fri, 30 Sep 2011 12:47:17 +0000 May Oo http://tech4mm.com/?p=314

The important tips are-

1) to keep the Data Sheet from manufacturer as main reference

2) to make sure the input pins and output pins are not mixed up

3) to check connection neat and tidy for safety reasons

Micro-controller တစ်ခုနဲ့ ပရောဂျက်တစ်ခု တည်ဆောက်မယ်ဆိုရင် အရေးပါတဲ့ အချက်တွေက -

၁) ကွန်ထရိုလာကို ထုတ်လုပ်သူဘက်က အထောက်အကူအဖြစ် ထုတ်ပေးထားတဲ့ Data Sheet ကို ဖတ်စာအုပ်လို ဖတ်ရှုမှီငြမ်းရန်

၂) အချက်အလက်ကို ရယူမယ့် ပင်နဲ့ ထုတ်ပေးမယ့် ရေး/ဖတ် ပင်တွေ မရောအောင် ဂရုစိုက်ရန်

၃) မတော်တဆ အမှားတွေ မဖြစ်ရအောင် ဆက်သွယ်မှု လမ်းကြောင်းတွေကို စနစ်တကျ သပ်ရပ်မှု ရှိမရှိ ဂရုစိုက်ရန်

မိုက်ခရိုကွန်ထရိုလာ ဘာသာရပ်ကို စတင်လေ့လာသူတွေ အသုံးများတာက ၂၈ ပင် သို့မဟုတ် ၄၀ ပင် ရှိတဲ့ စတုဂံပုံ ကွန်ထရိုလာများ ဖြစ်ပါတယ်။ ယာယီ ဆက်သွယ်မှုတွေ စမ်းသပ်ပြုလုပ်ဖို့ မုန့်ပြား (breadboard) လိုင်းတွေပေါ်မှာ အသုံးပြုရတာ ပိုမို လွယ်ကူလို့ဖြစ်ပါတယ်။

ဆားကစ်တစ်ခုကို အဆင်သင့်ပြင်ဖို့ လိုအပ်သော ပစ္စည်း

- ကွန်ထရိုလာ

- မုန့်ပြား (Breadboard)

- Single Core ဝါယာ (အနီ၊ အနက်၊ အဝါ၊ အပြာ စသည့် အရောင်များ ခွဲခြားသုံးခြင်းဖြင့် ပါဝါလိုင်း၊ ဂရောင်းလိုင်း၊ အချက်အလက် ရေး/ဖတ် လုပ်ပေးရမယ့် သက်ဆိုင်ရာ ပင်တွေကို မမှားရအောင် ကာကွယ်ပါ။)

- စွယ်စုံတိုင်း ကိရိယာ (Multi-Meter)

- plier

- cutter

- Capacitors

- Oscillator

- Resistors

- LED

- switch

 

ပရောဂျက်အတွက် ဆားကစ် တည်ဆောက်ရာမှာ ပထမဆုံးကြည့်ရမှာက ကိုယ်အသုံးပြုမယ့် ကွန်ထရိုလာရဲ့ ပင်နေရာချထားပုံ (Pin Diagram) ဖြစ်ပါတယ်။ ကွန်ထရိုလာတစ်ခု ပုံမှန်အလုပ်လုပ်ဖို့ ဘယ်နေရာမှာ ဘာနဲ့ ချိတ်ပေးရမယ် ဆိုတာတွေကို ကြည့်ပြီး တစ်ဆင့်ချင်း လိုက်ချိတ်ဆက်ရပါတယ်။ ဥပမာပေးထားတဲ့ ကွန်ထရိုလာမှာ မဖြစ်မနေ ဆက်သွယ်ရမှာတွေက VDD, VSS (VDD is High Voltage, VSS is Low Voltage or Ground) စုံတွဲ ၂ စုံ၊ MCLR နဲ့ OSC (oscillator)  စုံတွဲ ပါဝင်ပါတယ်။ ကျန်တာတွေ အကုန်လုံးက ပုံမှန် (ရေး/ဖတ်) ပင်တွေ ဖြစ်ပါတယ်။

 

 

 

]]> http://tech4mm.com/2011/09/basic-micro-controller-circuit-pic-18-1/feed/ 1 Java သမိုင်း http://tech4mm.com/2011/09/java-%e1%80%9e%e1%80%99%e1%80%ad%e1%80%af%e1%80%84%e1%80%ba%e1%80%b8/ http://tech4mm.com/2011/09/java-%e1%80%9e%e1%80%99%e1%80%ad%e1%80%af%e1%80%84%e1%80%ba%e1%80%b8/#comments Mon, 19 Sep 2011 00:50:42 +0000 MinLwin http://tech4mm.com/?p=297

ကနဦးခေတ်

Javaပလက်ဖေါင်းနှင့်ပရိုဂရမ်မင်းဘာသာရပ်Javaသည်၊ ၁၉၉၀ခုနှစ် ၁၂လပိုင်းတွင်Sun Microsystemsမှ ကိုယ်ပိုင်ပရိုဂျက်တစ်ခုအဖြစ် စတင်ခဲ့ပါသည်။ ထိုပရိုဂျက်သည် C++/C၏ အစားထိုး ပရိုဂရမ်မင်းဘာသာရပ်တစ်ခုအနေဖြင့် တီထွင်ရေးသားခဲ့ကြ၏။ ထိုဘာသာရပ်သည်၊ ပရိုဂျက်အတွင်း၌ Green Operating System (Green OS) နှင့်အတူ၊ Green OS ၏ အခြေခံဘာသာရပ်အနေဖြင့် တီထွင်ခဲ့ခြင်းဖြစ်၏။ ထိုဘာသာရပ်အား 1992ခုနှစ် လောက်တွင် ပရိုဂျက်အတွင်း၌ Oak ဟု အမည်တွင်ခဲ့သော်လည်း၊ နောက်ပိုင်းတွင် Java ဟု ပြောင်းလည်း ခေါ်ဝေါ်ခဲ့ကြခြင်း ဖြစ်၏။ ပြောင်းလည်းခေါ်ဝေါ်ခဲ့ကြခြင်း အကြောင်းအရင်းမှာ Oakသည် အခြားသော ကုမ္ပဏီတစ်ခုမှ စီးပွားဖြစ်အမည် တစ်ခုအနေဖြင့် တရားဝင် အသုံးပြုလျှက်ရှိသောကြောင့် ဖြစ်၏။

၁၉၉၀ခုနှစ် ပိုင်းတွင် Sun ၏ ပညာရှင် တစ်ယောက်ဖြစ်သော Patrick Naughton သည်၊ ကုမ္ပဏီ၏ ကိုယ်ပိုင် C++ နှင့် C တို့၏ API နှင့် လိုင်ဘရီများအား အားမလို အားမရဖြစ်နေခဲ့၏။ ထိုအချိန်တွင် အိုင်တီနည်းပညာ နယ်ပယ်တွင်၊ NeXTမှ တီထွင်လိုက်သော နည်းပညာအသစ် တစ်ခုသည် အားလုံး၏အာရုံစိုက်မှု့ကို ရရှိခဲ့သည်ကို အစပြု၍၊ Naughton သည်လည်း Sun တွင် နည်းပညာအသစ်များကို ဖန်တီးရန် တာဝန်ကျခဲ့၏။

NeXT မှ တီထွင်ခဲ့သော NeXT Workstationနှင့် NEXT STEPOSတွင်၊ ဝတ္တစက္ခုဗေဒ(Object Oriented) ပရိုဂရမ်မင်း ဘာသာရပ်တစ်ခုဖြစ်သော် Objective-C ပရိုဂရမ်မင်း ဘာသာရပ်ကို အခြေခံ ပရိုဂရမ်မင်းဘာသာရပ် အနေဖြင့် အသုံးပြုထားခဲ့၏။ ဤသို့ဖြင့် Java သည် ဝတ္တစက္ခုဗေဒကို အခြေခံသော နောက်လိုက်ပရိုဂျက်တစ်ခု အနေဖြင့် စတင်ခဲ့၏။

ဤကဲ့သို့စတင်ခဲ့သော နောက်လိုက်ပရိုဂျက်သည်၊ စစချင်းပင် James Gosling နှင့် Mike Sheridan တို့သည် ပါဝင်ခဲ့ကြပြီး၊ ပရိုဂျက်၏အမည်ကိုလည်းအစိမ်းရောင်ပရိုဂျက်ဟု ပြောင်းလဲခေါ်ဆိုခဲ့ကြ၏။ ဤအစိမ်းရောင်ပရိုဂျက်တွင် အခြားသော နည်းပညာရှင်များလည်း ပါဝင်ခဲ့ကြပြီး၊ အမေရိကပြည်ထောင်စုကာလီဖိုးနီးယား ပြည်နယ် ရှိ သေးငယ်သော ရုံးခန်းလေးတစ်ခုမှ စတင်ခဲ့ကြပါသည်။ အစိမ်းရောင်ပရိုဂျက်၏ ရည်ရွယ်ချက်မှာ၊ နောင်တစ်ခေတ်၏ အိမ်သုံးလျှပ်စစ် ပစ္စည်းများအတွက် ပရိုဂရမ်မင်းနည်းပညာ အသစ်တစ်ခုကို တီထွင်ရန် ဖြစ်၏။ Sun သည် ထိုစဉ်ကတည်းက ဤနယ်ပယ်တွင် အဓိကကျသော ဈေးကွက်တစ်ခု ဖြစ်ပေါ်လာမည့်အကြောင်း ကြိုတင်မှန်းဆ ခဲ့ကြခြင်းဖြစ်၏။

စတင်ခါစတွင် အစိမ်းရောင်ပရိုဂျက်သည် ပရိုဂရမ်မင်းဘာသာရပ်အနေဖြင့် ဝတ္တစက္ခုဗေဒ(Object Oriented) ပရိုဂရမ်မင်း ဘာသာရပ်တစ်ခုဖြစ်သော C++ ကို အသုံးပြုရန် စဉ်းစားခဲ့ကြသော်လည်း၊ အကြောင်းအမျိုးမျိုးကြောင့် C++ အားလက်လျှော့ခဲ့ကြ၏။ အဓိက အကြောင်းတစ်ခုမှာ C++ သည် စက်ပစ္စည်း၏ လျှပ်စစ်အရင်းအမြစ်ကို သုံးလွန်းသည်ဟု သတ်မှတ်ခဲ့ကြသောကြောင့် ဖြစ်၏။ သူတို့၏ ရည်ရွယ်ချက်မှာ အိမ်သုံးလျှပ်စစ်ပစ္စည်းများ၏ နည်းပညာကို တီထွင်ရန်ဖြစ်၏။ အိမ်သုံးလျှပ်စစ်ပစ္စည်းများတွင် အသုံးပြုနိုင်သော အရင်းအမြစ်များမှာ အလွန်နည်းပါးသည်၏။ ထို့ကြောင့် အရင်းအမြစ်များကို သုံးစွဲလွန်းသော C++ ကို လက်လျှော့ခဲ့ကြခြင်းဖြစ်၏။

နောက်အကြောင်းအရင်း တစ်ခုမှာ C++ သည် ခက်ခဲသော ဘာသာရပ် တစ်ခု ဖြစ်သောကြောင့် ဖြစ်၏။ C++ ကို အသုံးပြုသော ပရိုဂရမ်မာများသည် ဘယ်လောက်ပင်ကရုစိုက်သော်လည်း တစ်ကြိမ်ကြိမ်တွင် အမှားများကို ကျူးလွန်မိမြဲ ဖြစ်၏။
အကြောင်းမှာ C++ တွင်အမှိုက်သိမ်းစနစ်မရှိခဲ့ပေ။ ထို့အတွက် C++ ပရိုဂရမ်မာများသည် ရေးသားလိုသော လော့ဂျစ်အပြင်ကိုယ် မန်မိုရီကို ထိမ်းသိမ်းရေးအတွက်ပါ အာရုံစိုက်ရန်လိုအပ်ခဲ့၏။ ပရိုဂရမ်မာကိုယ်တိုင်က မန်မိုရီကို ထိမ်းသိမ်းခြင်းသည် လွန်စွာ စွန့်စားရသော အလုပ်တစ်ခု ဖြစ်ပြီး၊ မှားယွင်းလွယ်သော လုပ်ရပ်တစ်ခုလည်း ဖြစ်၏။ မသိလိုက်မသိသာ မံမိုရီယိုစီးမှု့ကို ဖြစ်ပွားစေတတ်သောကြောင့်ဖြစ်၏။

အစိမ်းရောင်ပရိုဂျက်၏ အဖွဲ့ဝင်များသည်၊ အဓိကလုပ်ဆောင်ချက်အချို့တွင် C++ ၏အပြောင်းအရွှေ့မလွယ်ကူခြင်းကို ပြဿနာတစ်ခုအဖြစ် ကြည့်မြင်ခဲ့ကြ၏။ ထို အဓိက လုပ်ဆောင်ချက်များမှာ လုံခြုံရေးစနစ်၊နေရာခြားကွန်ပျူတာစနစ်(Distributed Computing)နှင့်၊ စလက်များ(Multi Thread)ဖြစ်ကြ၏။ ထိုလုပ်ဆောင်ချက်များသည် ပလတ်ဖောင်းအပေါ်တွင် မှီခိုခြင်းမရှိပဲ အသုံးချနိုင်ရန် လိုအပ်ပေသည်။ အထက်ပါအကြောင်းများကြောင့် သူတို့သည်၊ လျှပ်စစ်ပစ္စည်း အမျိုးမျိုးတွင် လွယ်ကူစွာပြောင်းရွှေ့နိုင်သော ပလတ်ဖေါင်း၏ လိုအပ်ချက်ကို သိမြင်ခဲ့ကြ၏။

တဘက်တွင် Sun ၏ နည်းပညာရှင် တစ်ယောက်ဖြစ်သော Bill Joy သည်၊Xerox Corporation၏Palo Alto Research Centerတွင် Altoဟု အမည်ရသော Workstation စမ်းသပ်စက် အတွက် တီထွင်ခဲ့သော ပရိုဂရမ်မင်းဘာသာရပ် Mesa ဖြင့် C ဘာသာရပ်၏ ကောင်းသောနေရာများကို လက်ခံရယူပြီး ပရိုဂရမ်မင်းဘာသာရပ် အသစ်တစ်ခုကို ပုံဖော်နေခဲ့၏။ Joy သည် Further ဟု အမည်ရသော စာတမ်းတစ်စောင်ကို ရေးသားခဲ့ပြီး၊ C++ ကိုအခြေခံသော ဝတ္တစက္ခုဗေဒ(Object Oriented) ပတ်ဝင်းကျင်ကို တီထွင်ရန် အားထုတ်နေခဲ့၏။

ဦးစွာJames Arthur Goslingသည် C++ ကို ပြုပြင်ပြောင်းလဲပြီးအသုံးပြုရန် စမ်းသပ်ခဲ့၏။ Gosling သည် ဤ ပြုပြင်ထားသော C++ အား “C++ ++ –” ဟု အမည်ပေးခဲ့၏။ သို့ရာတွင် Gosling သည် ချက်ချင်းဆိုသလို C++ အားပြုပြင်ပြောင်းလည်းခြင်းကို ရပ်တန့်ခဲ့ပြီး၊ ပရိုဂရမ်မင်းဘာသာရပ် အသစ်တစ်ခုကို တီထွင်ရန် စတင်ခဲ့၏။ Gosling သည် ထို ပရိုဂရမ်မင်းဘာသာရပ် အသစ်အား Oak ဟုခေါ်ဆိုခဲ့၏။ ထိုအမည်ကို ရယူခဲ့ခြင်းမှာ James Arthur Gosling ၏ ရုံးခန်းအနီးအနားတွင် ဝက်သစ်ချပင်များ ပေါက်ရောက်နေသောကြောင့် ဖြစ်သည် ဟုဆိုသည်။

အစိမ်းရောင်ပရိုဂျက် အဖွဲ့ဝင်များသည် အချိန်ပိုကို လုပ်ရသည့်အထိ ကြိုးစား၍၊ ၁၉၉၂ ခုနှစ် နွေရာသီ အရောက်တွင် အသစ်ရေးသားထားသော ပလတ်ဖေါင်းအား၊ Green OS၊ Oak ဘာသာရပ်၊ လိုင်ဘရီ၊ စက်ပစ္စည်းများနှင့် တွဲဖက်ပြီး အစမ်းပြသနိုင်ခဲ့ကြ၏။ ၁၉၉၂ခု၊ ၉လ၊ ၃ရက် ပထမဆုံး ပြပွဲတွင် Star7 ဟုအမည်ရသော PDA ကို တီထွင်ရာတွင် အားစိုက်ခဲ့ကြ၏။ Star7 ၏ အမည်မှာ ခလုပ်*7 ကို နှိပ်ခြင်းအားဖြင့် ဖုန်းအဖြစ်အသုံးပြုနိုင်သောကြောင့် ဖြစ်၏။

ထို Star7 သည် ထိုခေတ်က လွန်စွာဆန်းသစ်သော GUI ကို ပြင်ဆင်ထားပြီး၊ “Duke” ဟု အမည်ရသော လက်ထောက်ကလေးက အသုံးပြုသူကို အကူအညီပေးပါသည်။ ထိုနှစ် ၁၁လပိုင်းတွင်၊ Sun သည် အစိမ်းရောင်ပရိုဂျက်ကို ခွဲထုတ်ခဲ့ပြီး လက်အောက်ခံ ကုမ္ပဏီ FirstPerson, Inc စတင်ခဲ့၏။ FirstPerson အဖွဲ့ဝင်များသည်၊ အဆင့်မြင့် အပြန်အလှန်အသုံးပြု ကရိယာများ အပေါ်တွင် စိတ်ဝင်စားမှု့ကို ပြသခဲ့၏။ ထိုအချိန်တွင် ime Warner Inc.သည် ကေဘယ် တီဗွီသုံးSet Top Box၏ RFP (Request For Proposal) ကို ထုတ်ပြန်ခဲ့၏။ ထိုအခါ FirstPerson သည် မိမိတို့၏ ရည်ရွယ်ချက်ကို ပြောင်းလည်းခဲ့ပြီး ime Warner Inc.၏ RFP ကို လက်ခံပြီး အကြံပြုချက်များ ကို တင်သွင်းခဲ့ကြ၏။ သို့ရာတွင်FirstPerson သည် အပြိုင်အဆိုင် ၌Silicon Graphics, Inc. (SGI)ကို ရှုန်းနှိမ့်ခဲ့၏။ ထို့နောက်တွင်3DO ၏Set Top Box လုပ်ငန်းရှိခဲ့သော်လည်း၊ စာချုပ်ချုပ်နိုင်သည့်အဆင့်ကို မရောက်ခဲ့ပေ။ Sun သည် တီဗွီနယ်ပယ်တွင် ထင်သလောက် အကျိုးအမြတ် မရရှိခဲ့ပါသော၊ FirstPerson အား ဖျက်သိမ်းခဲ့ပြီး အဖွဲ့ဝင်များကို ပြန်လည်ခေါ်ယူခဲ့၏။

အင်တာနက်နယ်ပယ်ဆီသို့

၁၉၉၄ခု ၆လ မှ ၇လပိုင်းအထိ John Gage၊ James Gosling၊Bill Joy၊ Patrick Naughton ၊Wayne Rosin၊ Eric Emerson Schmidtတို့ကြားတွင်၊ ၃ရက်တိုင်တိုင် ဆွေးနွေးပွဲ ပြုလုပ်ခဲ့ပြီး၊ Web လောက ဘက်ကို ဦးတည်ချက်ပြောင်းရန် ချမှတ်ခဲ့ကြ၏။ သူတို့သည် ခေတ်ရှေ့ပြေးသော Web Browserတစ်ခုဖြစ်သည့် NCSA Mosaic ကို တွေ့မြင်ပြီး Web ကို အစပြုသည့် အင်တာနက် ၏ နယ်မြေသည် ကေဘယ်တီဗွီထက် မနိမ့်ကျသော အပြန်အလှန် အသုံးပြုနိုင်သော အဆင့်မြင် ကြားခံနယ်တစ်ခုဖြစ်လာနိုင်ကြောင်းကို လက်ခံခဲ့ကြ၏။ Oak ကို အသုံးပြု၍ Prototype အနေနှင့် Naughton သည် WebRunner ဟုအမည်ရသည့် ဘရောက်ဇာ အသေးစားလေးတစ်ခုကို တီထွင်ခဲ့၏။ ထို ဘရောက်ဇာ၏ အမည်သည် နောက်ပိုင်းတွင် HotJava ဟု ပြောင်းလဲခဲ့၏။ Web စာမျက်နှာ တွင် Java အပလက် ဟု အမည်ရသော Java ပရိုဂရမ် အသေးစားများကို ထည့်သွင်းပြီး၊ HotJava ဖြင့် စာမျက်နှာကို ဖွင့်ကြည့်သောအခါ HotJava အပေါ်တွင် ကာတွန်းကားများနှင့် မောက်စ်၏ လှုပ်ရှားမှု့ အားပြန်လည်ပြီး တုံ့ပြန်နိုင်သည့် ပရိုဂရမ်များကို အသုံးချလာနိုင်ခဲ့ကြ၏။

ထိုနှစ်ထဲမှာပင် Oak ၏ အမည်အား Java ဟု ပြောင်းလည်းခေါ်ဆိုခဲ့ကြ၏။ အကြောင်းမှာ အမည် မှတ်ပုံတင်ရန် လေ့လာကြည့်သောအခါ “Oak” သည် ဗွီဒီယို ကတ်ထုတ်လုပ်ရေး ကုမ္ပဏီ (Oak Technology) က လက်ရှိ အသုံးပြုနေသောကြောင့်ဖြစ်၏။ Java ဟူသော အမည်မှာ ထိုစဉ်က အဖွဲ့ဝင်များ အသွားများခဲ့သော ကော်ဖီဆိုင်တစ်ဆိုင်၏ အမည်ဟုလည်း အပြောများကြ၏။ အချို့မှာမူ အခြား စကားလုံးတစ်ခု၏ အတိုကောက်အမည်ဟုလည်း ပြောကြ၏။

  • စကားလုံးအစများ ကိုယူထားခြင်းမဟုတ်ဟူသော အဆိုကို လက်ခံသူများကြ၏။
  • အနီးအနားရှိ ကော်ဖီဆိုင်တွင် ရောင်းသောကော်ဖီစေ့၏ အမျိုးအစားကို အသုံးပြုထားသည်ဟု စဉ်းစားသူကများ၏။ အဘယ့်ကြောင့်ဆိုသော် Java ကလပ်စ်ဖိုင်၏ဘိုက်ကုဒ်）၏ အစစာလုံး လေးလုံးသည် အမြဲတမ်း 0xCAFEBABE ဟု ရေးသားထားသောကြောင့်ဖြစ်၏။
  • တဖန် အမေရိကန် အင်္ဂလိပ်ဘာသာရပ်တွင် coffee ဟုလည်း အဓိပ္ပါယ်ရပါသည်။
  • သို့ရာတွင် James Gosling, Arthur Van Hoff, and Andy Bechtolsheim တို့၏ အစစာလုံးကို အသုံးပြုထားသည်ဟု ပြောကြသည်လည်းရှိ၏။
  • တဖန် Just Another Vague Acronym ၏ အစစာလုံးဟု ပြောဆိုသည်လည်းရှိ၏။

၁၉၉၄ခု ၁၀လပိုင်းတွင် HotJava နှင့်Java ပလတ်ဖေါင်း သည် Sun Microsystem ၏ အရေးပါဝန်ထမ်းများ၏ရှေ့တွင် စမ်းသပ်ပြသနိုင်ခဲ့၏။ ထိုမှတဆင့် ၁၉၉၄ခုနှစ် အတွင်းမှာပင် Java 1.0a （Alpha Version）ကို ဒေါင်းလုဒ်လုပ်နိုင်ခဲ့၏။

Java နှင့် HotJava ၏ ပထမဦးဆုံး တရားဝင်ထုတ်ပြန်ခဲ့ကြသည်မှာ ၁၉၉၅ခု ၅လပိုင်း ၂၃ရက်နေ့တွင် ကျင်းပခဲ့သော SunWorld တွေ့ဆုံပွဲတွင် ဖြစ်၏။ Sun သည် Java ဖြင့်ရေးသားထားသော Web ဘရောင်ဇာ HotJava ကိုအသုံးပြု၍ Java နှင့်Java အပလက် နည်းပညာဖြင့်ဝက်စာမျက်နှာအပေါ်တွင် ကာတွန်းလှုပ်ရှားမှု့ များ၊ မောက်စ်၏ လှုပ်ရှားမှု့အားတုံ့ပြန်နိုင်မှု့များအား ပြသခဲ့၏။ ထိုတွေ့ဆုံပွဲတွင် ထုတ်ပြန်ကျော်ညာခဲ့သည်မှာ Sun ၏နည်းပညာ ဌာနမှုးတစ်ဦးဖြစ်သော John Gage ပင် ဖြစ်၏။ ထို တွေ့ဆုံပွဲမှာပင် John Gage ၏ထုတ်ပြန်ချက်နှင့်ပတ်သက်ပြီး Netscape Communications ၏ ဒုတိယ ဥက္ကဋ္ဌ Marc Andreessen ၏ ထုတ်ပြန်ချက်က တက်ရောက်လာသူများအား အံ့အားသင့်စေခဲ့၏။ တဖန် Netscape ကုမ္ပဏီမှ ၎င်း၏ဘရောင်ဇာဖြစ်သော Netscape Navigator တွင် Java အား ထည့်သွင်းရန် စီစဉ်နေကြောင်းကို ထုတ်ပြန်ခဲ့၏။ ဤထုတ်ပြန်ချက်ကြောင့် Java နည်းပညာသည် အိုင်တီနည်းပညာလောတွင် အသိများစေခဲ့ပါသည်။

လတ်တလော လှုပ်ရှားမှု့များ

Java ၏ တရားဝင် ထုတ်ပြန်ပြီးချိန်မှ ယနေ့အချိန်အထိ ပြောင်းလည်းလာခဲ့ပုံကို အဘက်ဘက်မှ သုံးသပ်သွားပါမည်။

Web（Client ဘက်မှအမြင်）

Web ဘရောင်ဇာဖြင့် Java အပလက်ကို အသုံးပြုသည့်နည်းပညာမှာ အတော်ကျယ်ကျယ်ပြန့်ပြန့်ကို အသုံးပြုလာခဲ့ကြ၏။ ဘရောက်ဇာ（World Wide Web၏Clientဘက်ခြမ်း）သည်Web စာမျက်နှာ အတွင်း Animation များကို ဖော်ပြရာတွင်၎င်း၊ Mouse Event အပေါ်တွင် Interactive လှုပ်ရှားမှု့များကို တုံ့ပြန်ရာတွင်၎င်း Java ကို အသုံးပြုခဲ့ကြ၏။ သို့ရာတွင် ယခုနောက်ပိုင်းတွင် အင်အားကြီးသော အပြိုင်အဆိုင် များလည်း ထွက်ပေါ်လာခဲ့၏။ ယနေ့ နှစ်များတွင် Yahoo! Games နှင့် ဗွီဒီယိုပြစက် အစရှိသည့် အပလီကေးရှင်းများတွင် Java အပလက်ကို အသုံးပြုများသည်ကို တွေ့ရ၏။

ယခင် အချိန်များတွင် Java အပလက်ကို အသုံးပြုထားသည့် ဆိုဒ်များကို ကြည့်လိုသည့်အခါ စက္ကန့်အတန်ကြာ ကြာမြင့်သည့် ဘရောက်ဇာများလည်းရှိတတ်၏။ Java နှင့် Java အပလက် ၏ နည်းပညာတိုးတက်လာမှု့ကြောင့် ပတ်ဝင်းကျင်ကြောင့်ကြာမြင့်မှု့များ၊ စာမျက်နှာကို ဖော်ပြရာတွင် ကြံ့ကြာမှု့ အစရှိသည့် အခက်အခဲများလည်း ဖြေရှင်းလာနိုင်ခဲ့၏။

လွယ်ကူသော Animation များကို အသုံးပြုရာတွင် Java အပလက်ထက်စာလျှင် GIF89a နှင့် Adobe Flash ကို အသုံးပြုကြသည်က များ၏။ ယနေ့ခေတ် Web Client နယ်ပယ်တွင် Ajax သည်လည်း ခေတ်စားလာခဲ့၏။

Web（ဆာဗာ ဘက်မှအမြင်）

ယနေ့ခေတ် World Wide Web၏ဆာဗာ ဘက်ပိုင်းတွင် Java နည်းပညာ(Java EE) အား အတော်များများ အသုံးပြုနေကြသည်ကို တွေ့ရ၏။ ဝက်ဘ်ဆိုက် အတော်များများသည်၊ Java ဆာဗလက် (Java Servlet) နှင့် JSP（JavaServer Pages）အစရှိသည့် Java EE နည်းပညာများကို အသုံးပြု၍ ဝက်စာမျက်နှာများကို အလိုအလျှောက်ထုတ်လုပ်ပေးနိုင်သော ဆိုက်များကို တည်ဆောက်လာကြသည်ကို တွေ့ရ၏။ Java ဆာဗလက် သည် သက္ကရစ် ၂၀၀၀ခုနှစ်နောက်ပိုင်းတွင် အကျယ်တဝင့် အသုံးပြုလာကြပြီး ယနေ့အချိန်အခါတွင်ဝက်ဘ်အပလီကေးရှင်းအတော်များများသည် ဆာဗလက်များအပေါ်တွင် တည်ဆောက်ထားကြသည်ကို တွေ့ရပါ၏။

Sun Microsystems မှရေသားခဲ့သော Java ဆာဗလက်၏ အလုပ်လုပ်ဆောင်ပုံကို အကျဉ်းချုံးဖော်ပြပါမည်။

  • Java အားအသုံးချနိုင်သည့် ပတ်ဝင်းကျင်ပရိုဆက်（ဆာဗလက်ပတ်ဝင်းကျင်）အား အလုပ်လုပ်နေစေပြီး ဝက်ဘ်ဆာဗာအနေဖြင့် အလုပ်လုပ်နေစေ၏။
  • ဝက်ဘ်ဆာဗာသည်ဝက်ဘ်ဘရောင်ဇာမှ ဆက်သွယ်တောင်းဆိုမှု့(Request)ကို လက်ခံရရှိပါသည်။
  • ဝက်ဘ်ဆာဗာသည် လက်ခံရရှိလာသော တောင်းဆိုမှု့ကို ဆာဗလက်ပတ်ဝင်းကျင်ဆီသို့ လက်ဆင့်ကမ်းပေးပို့ပါသည်။
  • ဆာဗလက်ပတ်ဝင်းကျင် အပေါ်တွင်အလုပ်လုပ်နေသော Java ပရိုဂရမ်（Java ဆာဗလက်）သည်၊ လက်ခံရရှိသည့် တောင်းဆိုမှု့အပေါ်တွင် မှုတည်ပြီးဝက်ဘ်စာမျက်နှာများကို အလိုအလျောက် ရေးသားပေးပါသည်။
  • ဆာဗလက်ပတ်ဝန်းကျင်သည်၊ ဆာဗလက်မှရေးသားပေးသော ဝက်ဘ်စာမျက်နှာများကို ဝက်ဘ်စာမျက်နှာများဆီသို့ ပြန်လည်ပေးပို့ပါသည်။
  • ဝက်ဘ်ဆာဗာသည်၊ ဆာဗလက်ပတ်ဝင်းကျင်မှ လက်ခံရရှိသော ဝက်ဘ်စာမျက်နှာကို ဝက်ဘ်ဘရောင်ဇာဆီသို့ ပြန်လည်ပေးပို့ပါသည်။

Sun က Java ဆာဗလက် နည်းပညာကို တီထွင်ခဲ့ကြသည့် ၁၉၉၀ခုနှစ်ပိုင်းများတွင်၊ ဝက်ဘ်အပလီကေးရှင်းများကို ရေးသားကြရာတွင် အောက်ပါအခက်အခဲများကို ကြုံတွေ့ရလေ့ရှိခဲ့၏။

  • ဝက်ဘ်အပလီကေးရှင်း（Dynamic Web Page）များကို ရေးသားရာတွင်CGIသို့မဟုတ်၊Microsoft၏IISမှ ထုတ်ပြန်ထားသောActive Server Pages (ASP) ကို အသုံးပြုနေကြသည်က များ၏။
  • CGI သည် ၎င်း၏ထူးခြားချက်မှ အိုဗာဟတ်ဒ်အဖြစ်များ၍၊ စာမျက်နှာကို လျှင်လျှင်မြန်မြန်ဖော်ပြနိုင်ရန် ရေးသားရန်အလွန်ခက်ခဲလှ၏။
  • ASP သည်ဆာဗာသည် အလွန်တန်ဖိုးကြီးမားသော Microsoft Windows NT Server ဖြစ်ရန် လိုအပ်ပါသည်။

    • Java ဆာဗလက်သည် အထက်ပါပြဿနာများကို ဖြေရှင်းနိုင်ရန် ရည်ရွယ်ပြီး ရေးသားခဲ့သော နည်းပညာဖြစ်ပါသည်။

    Desktop ဘက်ကို ပြောင်းလည်းလာပုံ

    Desktop ပတ်ဝင်းကျင်နှင့်ပတ်သက်ပြီးကိုယ်ပိုင်ရပ်တည်နိုင်သော Java (Java SE) ၏အပလီကေးရှင်းဆော့ဖ်ဝဲ（Javaအပလီကေးရှင်း）သည်၊ ယခင်က အသုံးနည်းပါးခဲ့သော်လည်း ယခုနောက်ပိုင်းတွင် Java ကိုအသုံးပြုသော ဆော့ဖ်ဝဲများကို တွေ့လာခဲ့ရပါသည်။ ဤကဲ့သို့ အသုံးများလာရခြင်း အကြောင်းအရင်းကို အောက်ပါအချက်များကြောင့်ဟု စဉ်းစားနိုင်ပါသည်။

  • ကွန်ပျူတာ၏ လုပ်ဆောင်နိုင်စွမ်း စွမ်းရည်သည် မြင့်မားလာမှု့ကြောင့်ဖြစ်၏။
  • Java ၏ဒြပ်မဲ့စက်（Java ဒြပ်မဲ့စက်၊ Java VM）နှင့်Javaကွန်ပိုင်းလာသည် များစွာ တိုးတက်ပြောင်းလည်း လာခဲ့သောကြောင့် ဖြစ်၏။
  • သုံးရလွယ်ကူသော Java ၏Desktop အပလီကေးရှင်းများကို လွယ်ကူစွာ ရေးသားနိုင်သော အဆင့်မြင့် IDEများကို၊Open Sourceနှင့် စီးပွားဖြစ် လုပ်ငန်းသုံးများဘက်မှ ထုတ်ပြန်လာနိုင်ခဲ့သောကြောင့် ဖြစ်၏။

အသုံးများသော Java ဆော့ဖ်ဝဲများမှာNetBeansနှင့်Eclipse SDK၏ပေါင်းစုရေးသားပတ်ဝင်းကျင်နှင့်၊ LimeWireနင့်Azureusကဲ့သို့သောဖိုင်ပူးတွဲအသုံးချ ဆော့ဖ်ဝဲများ အစရှိသော ဆော့ဖ်ဝဲများပဲဖြစ်ကြ၏။ တဖန် သင်္ချာဆော့ဖ်ဝဲတစ်ခုဖြစ်သော MATLAB မှာလည်းUser Interface၏ ပံ့ပိုးမှု့နှင့် အတွက်အချက်ပိုင်းနေရာ အချို့တွင် Java ကို အသုံးပြုထားပါသည်။ Java Swingနှင့်SWT၏ဝစ်ဂျက်တူးကစ်ကို အသုံးပြုထားသော အပလီကေးရှင်းများကို နောက်ပိုင်းနေ့ရက်များတွင် တွေ့လာခဲ့ရပါသည်။

ဤကဲ့သို့ ယနေ့ခေတ်များတွင် Desktop Java အပလီကေးရှင်းများကို အသုံးပြုလာသည်ကို တွေ့ရပါသော်လည်း၊ အောက်ပါ အခက်အခဲများကြောင့် သုံးသင့်သလောက် အသုံးမများသည်ကို တွေ့နေရ၏။

  • Java အပလီကေရှင်းများသည်၊ Java ပတ်ဝင်းကျင်၏ အိုဗာဟက်ဒ်ကြောင့် သဘာဝအပလီကေးရှင်းများနှင့် နှိုင်းယှဉ်လျှင် မံမိုရီ အသုံးများကြသည်က များ၏။
  • GUI သည် အသုံးပြုမည့်ပလတ်ဖေါင်း ကိုယ်ပိုင်ထူးခြားမှု့ရှိသည့် Human Interface Guideline (HIG) ကို ထည့်သွင်း စဉ်းစားထားခြင်းမရှိပေ။ HIG ကို လိုက်နာပြီးအပလီကေးရှင်းများကို ရေးသားပါက၊ အသုံးပြုသူသည် အသုံးပြုမည့် အပလီကေးရှင်းကို နားလည်ရလွယ်ကူ တတ်ပါသည်။ တဖန် မှုလအတိုင်းအသုံးပြုမည် ဆိုပါက စာလုံးဒီဇိုင်းများကို ချောမွေ့စေသည့် နည်းပညာ (Font Smoothing) ကို အသုံးပြု၍မရနိုင်ပေ။ ထို့ကြောင့် User Interface ၏ စာလုံးများကို ဖော်ပြရာတွင် လှပခြင်းမရှိပဲ အရည်အသွေးမှာ မြင့်မားခြင်းမရှိနိုင်ပေ။
  • Java Development Kit (JDK)အဖြစ် အခမဲ့ပံ့ပိုးပေးနေသော အခြေခံJavaပလတ်ဖေါင်းသည် အသုံးလွယ်သော Desktop အပလီကေးရှင်းများကို ရေးသားရန်မှာ အားနည်းနေပါသေး၏။
    • ယခုနောက်ပိုင်းတွင် အထက်ဖော်ပြပါအတိုင်း၊ အသုံးလွယ်ကူသည့် Java Desktop အပလီကေးရှင်းများကို လွယ်ကူစွာရေးသားနိုင်သည့် အထောက်ကူပြုကရိယာများအားOpen Source/စီးပွားဖြစ် အနေဖြင့်၎င်း ပံ့ပိုးပေးနေကြ၏။
    • Javaပလက်ဖေါင်း (JRE) သည် ယနေ့တိုင် အဓိက ဗားရှင်းမြှင့်တင်မှု့များကို အကြိမ်ကြိမ် ပြုလုပ်ခဲ့ကြပြီး၊ ဗားရှင်းအမျိုးမျိုးရှိကြ၏။ အသုံးပြုသူသည် Java အပလီကေးရှင်းတစ်ခုကို စတင်အသုံးပြုရာတွင် လိုအပ်သလို ထိုအပလီကေးရှင်းကို အလုပ်လုပ်စေနိုင်သည့် ဗားရှင်းသို့မဟုတ် ထိုထက်နောက်ကျသော ဗားရှင်းကို အင်စတောလုပ်ထားရန် လိုအပ်ပါသည်။ Java ပလက်ဖေါင်းသည် 7MB အကျော်ရှိပြီး၊ ဒေါင်းလုဒ်လုပ်ပြီး အင်စတောလုပ်ရန်မှာ အတော်လေးကို အလုပ်များစေပါသည်။
    • ယခုနောက်ပိုင်းတွင် Java Web Start ၏ ထွက်ပေါ်လာခြင်းကြောင့် အော်တို ဒေါင်းလုဒ်နှင့် အင်စတော ကို လုပ်ဆောင်လာနိုင်ခဲ့ပါသည်။ ဝက်ဘ်ဘရောင်ဇာမှ Java အပလီကေရှင်းကို ရှာဖွေတွေ့ရှိပါက ကလစ်တစ်ခါနှိပ်ရုံဖြင့် JRE ကို အလိုအလျှောက် ဒေါင်းလုဒ်လုပ်ပြီး၊ အင်စတောလုပ်ခြင်း၊ Update လုပ်ခြင်း အစရှိသည်တို့ကို လုပ်ဆောင်ပေးနိုင်ပြီး၊ Java Web Start ကို အခြေခံသောSwing အပလီကေးရှင်းများကို အလုပ်လုပ်စေနိုင်ပါသည်။

အချို့သောဆော့ဖ်ဝဲရေးသားသူများသည် အိုင်တီနည်းပညာတွင်ဝက်ဘ်ကို အခြေခံသော မော်ဒယ်သည် ခေတ်စားနေပြီး၊ Stand Aloneအပလီကေးရှင်းများသည် ခေတ်နောက်ကျလျှက်ရှိပြီး၊ ပရိုဂရမ်မင်းနည်းပညာ အသစ်များသည် ထူးချွံသောဝက်ဘ်အပလီကေးရှင်းကို ရေးသားနိုင်ခြင်းဖြင့် ပြည့်စုံနေသည်ဟု ထင်မြင်နေကြ၏။ ဤအမြင်နှင့်ပတ်သက်၍ ဆော့ဖ်ဝဲနည်းပညာရှင်များကြားတွင် ထောက်ခံသူများရော ကန့်ကွက်သူများပါ အမျိုးမျိုးရှိကြပါ၏။

လက်ရှိအချိန်တွင်Rich Clientနှင့်Web 2.0တို့၏ ထွက်ပေါ်လာမှု့ကြောင့် ပုံစံအသစ်များကို ဖြစ်ပေါ်စေခဲ့ပါသည်။ ဝက်ဘ်ကို အခြေပြုသော ဝက်ဘ်အပလီကေးရှင်းနှင့်Stand Aloneအပလီကေးရှင်းများ၏ ပူးတွဲမှု့များပင်ဖြစ်၏။ ဝက်ဘ်အပလီကေးရှင်းအား Ajaxနှင့် Java Web Start၊Adobe Flash အစရှိသည့် ပူးတွဲရေးသားမှု့များကြောင့်၊ Web2.0 ခေတ်နှင့် လိုက်ညီသော လှပသေသပ်သည့် အပလီကေးရှင်းများကို ရေးသားလာနိုင်ခဲ့ကြပါသည်။

အိမ်သုံး ကွန်ပျူတာနှင့် ပတ်သက်၍

ယနေ့ခေတ် အိမ်သုံးကွန်ပျူတာ (PC) အတော်များများသည် အသုံးပြုသူက ဝက်ဘ်နှင့်Desktop ပတ်ဝင်းကျင်အပေါ်တွင် Javaအပလီကေးရှင်း များကို အခက်အခဲမရှိ အလုပ်လုပ်စေနိုင်ပါသည် ။ PCထုတ်လုပ်သူ အတော်များများသည် ထုတ်လုပ်ရောင်းချသည့် Windows PC တွင်Javaပလက်ဖေါင်း (JRE) ကို ထည့်သွင်းပေးလျှက်ရှိ၏။ ပန်းသီးတံဆိပ်၏ Mac OS X နှင့် Linux အတော်များများတွင်လည်း Java ပလက်ဖေါင်းကို ထည့်သွင်းပေးလျှက်ရှိ၏။ ထို့ကြောင့် ၂၀၀၁ခုနှစ်နောက်ပိုင်း Microsoftမှ Java ပလက်ဖေါင်းကို Windows တွင် ထည့်သွင်းခြင်းမပြုတော့ဟု ထုတ်ပြန်ချက်သည် Java အပလီကေးရှင်းများ အပေါ် အကျိုးသက်ရောက်မှု့မှာ ထင်သလောက်ကြီးမားခြင်းမရှိပေ။

၂၀၀၁ခုနှစ် နောက်ပိုင်းတွင် မိုက်ကရိုဆော့ဖ်မှ Java ပလက်ဖေါင်းကို Windows တွင် ထည့်သွင်းခြင်းမပြုတော့ဟု ထုတ်ပြန်ခဲ့ခြင်းသည်၊ ဆန်းမိုက်ကရိုစစ္စတမ်မှ မိုက်ကရိုဆော့ဖ်အား အဆင့်နိပ်သော Java ပလက်ဖေါင်းအား ထည့်သွင်းနေမှု့ကြောင်း တရားစွဲဆိုခဲ့သောကြောင့်ဖြစ်၏။ မိုက်ကရိုဆော့ဖ်မှ ယနေ့တိုင် Windows တွင် ထည့်သွင်းခဲ့သော Java ပလက်ဖေါင်းတွင် အသုံးပြုရန် ရေးသားသားသော Java ပရိုဂရမ်တစ်ခုသည် အခြားသော ပလက်ဖေါင်းအပေါ်ရှိ Java ပလက်ဖေါင်းအပေါ်တွင် အလုပ်နိုင်မည်ဟု အာမခံနိုင်မည် မဟုတ်ပေ။

သို့ရာတွင် ယနေ့ခေတ်များတွင် Java အပလီကေးရှင်းများ ကိုယ်တိုင်က Java ပလက်ဖေါင်းများကို ပူးတွဲဖြန့်ဝေလာကြသည်ကို တွေ့ရ၏။ ထိုသို့ဖြန့်ဝေလာကြခြင်းမှာ Java အပလီကေးရှင်းများကို ရေးသားသူနည်းပညာရှင်များ၏ ဆုံးဖြတ်ချက်ကြောင့် ဖြစ်၏။ Java အပလီကေးရှင်းများကို ရည်ရွယ်ထားသလို အသုံးပြုနိုင်စေရန်အတွက် Java ပလက်ဖေါင်း၏ခြားနားမှု့ကြောင့် ဖြစ်ပေါ်စေတတ်သော ပြဿနာများကို ရှောင်ရှားနိုင်စေဖို့အတွက် ကွန်ပျူတာအပေါ်တွင်ရှိသော Java ပလက်ဖေါင်းအား အသုံးပြုရန် မသင့်ဟု ဆုံးဖြတ်ခဲ့ကြသောကြောင့် ဖြစ်၏။

လက်ရှိအချိန်တွင်Javaအပလက်သည် ကိုယ်တိုင်အလုပ်လုပ်နိုင်သော ပလတ်ဖေါင်းကို ခွဲခြားသိရှိ လာနိုင်ခဲ့ပါသည်။ တဖန်၊ ဗားရှင်းများအကြား၌ အပြန်အလှန်အသုံးပြုနိုင်မှု့ သည်လည်း ပရိုဂရမ်မင်းဘာသာရပ်များ အကြားတွင် အဆင့်မြင့် အနေအထားတွင် တည်ရှိပါသည်။ Java SE 1.3 နောက်ပိုင်းတွင် ဗားရှင်းမတူညီမှု့ကြောင့် ဖြစ်ပေါ်တက်သော ပြဿနာများမှာ အလွန်နည်းပါးလာခဲ့ပါသည်။ ထို့အပြင် Java Web Start နည်းပညာသည် အင်စတောလုပ်ထားသော Java ဗားရှင်းကို စမ်းစစ်ပြီး လိုအပ်ပါက အလိုအလျှောက် အပ်ဒိတ်လုပ်ပြီး၊ Java Web Start သုံး အပလီကေးရှင်းများကိုပါ အပ်ဒိတ်လုပ်လာနိုင်ပါသည်။ ထို့အတွက် Java ပလက်ဖေါင်း ဗားရှင်းအဟောင်းများကို အသုံးပြုနေသော စက်များပင်ဖြစ်လင့်ငြား အလိုအလျှောက် အပ်ဒိတ်လုပ်နိုင်ခြင်းကြောင့် ဘားရှင်းပြဿနာသည် ခက်ခဲသော ပြဿနာတစ်ခုမဟုတ်တော့ပါ။

နှစ်မြှုပ်စစ္စတမ် အပိုင်းဆိုင်ရာ

နှစ်မြှုပ်စစ္စတမ်သုံး Java (Java ME) သည် တွင်ကျယ်စွာအသုံးပြုနေသော ပတ်ဝင်းကျင်တစ်မျိုးဖြစ်၏။

မိုဘိုင်းကရိယာ（မိုဘိုင်းဖုန်း・PHSやPDA・စမတ်ဖုန်းအစရှိသည့်）များတွင် Java ပလက်ဖေါင်းများကို အသုံးပြုကြသည်က များ၏။ Java ပလက်ဖေါင်းအား အထက်ပါ မိုဘိုင်းကရိယာများတွင် တွင်ကျယ်စွာအသုံးပြုနေကြ၏။ တဖက်တွင် Symbian နှင့် BREW သည်လည်း မိုဘိုင်းဖုန်းအား အဓိကထားပြီး Java နှင့် အပြိုင်ဖြစ်လာခဲ့ပါသည်။

Java ME သည် BREW နှင့်မတူညီပဲ၊ ဖန်တီးသူမှ လိုင်စဉ်ခ ပေးဆောင်ရန်မလိုပဲ ပရိုဂရမ်များကို ဖန်တီးရေးသားနိုင်၏။ တဖန် Java ME အား Symbian ထက်စာလျှင် ကျယ်ပြန့်စွာ အသုံးပြုနေသည်ကို တွေ့ရပါသည်။ ထိုအချက်ကြောင့် Java ME သည် Symbian ထက်ကျယ်ပြန့်စွာ အသုံးပြုလာကြသည်မှာ မိုဘိုင်းကရိယာများအတော်များများအပေါ်တွင် သက်သာစွာ အလုပ် လုပ်ဆောင်နိုင်စေသောကြောင့် ဖြစ်၏။ အထက်ပါအကြောင်းများကြောင့် တတိယပါတီများမှတဆင့် Opera mini ကဲ့သို့သော အခမဲ့ Java ဆော့ဖ်ဝဲများကို ရေးသားလာနိုင်ခြင်းဖြစ်၏။

]]> http://tech4mm.com/2011/09/java-%e1%80%9e%e1%80%99%e1%80%ad%e1%80%af%e1%80%84%e1%80%ba%e1%80%b8/feed/ 0 Java ဆိုသည်မှာ http://tech4mm.com/2011/08/java-%e1%80%86%e1%80%ad%e1%80%af%e1%80%9e%e1%80%8a%e1%80%ba%e1%80%99%e1%80%be%e1%80%ac/ http://tech4mm.com/2011/08/java-%e1%80%86%e1%80%ad%e1%80%af%e1%80%9e%e1%80%8a%e1%80%ba%e1%80%99%e1%80%be%e1%80%ac/#comments Sat, 27 Aug 2011 17:30:01 +0000 MinLwin http://tech4mm.com/?p=276

ပြီးခဲ့သော နှစ်ရက်လောက်ကတည်းက မြန်မာဝီကီပီဒီယားထဲမှာ Java အကြောင်းကို သွားရေးနေခဲ့ပါတယ်။ အဓိကကတော့ အင်္ဂလိပ်ဝိကီနဲ့ ဂျပန်ဝီကီကို ဖတ်ရင်း၊ ဘာသာပြန်ရင်း၊ မှုရင်းစာစောင်များကို ရှာဖတ်ရင်းပေါ့။ အဲ့ဒီအထဲမှာ ရေးသားထားတာလေးတွေကို ပြန်လည် ဖော်ပြပါဦးမည်။

ပရိုဂရမ်မင်းဘာသာရပ်Java နှင့်Javaပလက်ဖေါင်းအား1990ခုနှစ်အစပိုင်းတွင်Sun Microsystemတွင်James Gosling အမှုးပြုသော ပညာရှင်များက တီထွင်ရေးသားခဲ့ကြပါသည်။ လက်ရှိတွင် Java နည်းပညာ၏ အခြေခံပြုခြင်းလုပ်ငန်းများသည်Java Community Process (JCP) ဟုအမည်ရသော အဆင့်များဖြင့် ပြုပြင်ရေးသားနေကြ၏။

Java နှင့်ပတ်သက်သော အမည်နှင့် အဓိပ္ပါယ်မှာ အသုံးပြုပုံ အပေါ်တွင်မှုတည်ပြီး အမျိုးမျိုး ကွဲပြားခြားနား၏။ Sun Microsystemsသည်、Java နည်းပညာ（Java နည်းပညာ、Java technology）ဟု ခေါ်ဆိုအသုံးပြုပြီး၊ တဘက်တွင် Java ၏ အမျိုးမျိုးသော နည်းပညာများ၏ အမည်အဖြစ်လည်း Java ဟုခေါ်ဆိုအသုံးပြုလေ့ရှိ၏။ ပရိုဂရမ်မာ အများစုသည်၊ ပရိုဂရမ်မင်းဘာသာရပ် ဟူသော အဓိပ္ပါယ် အဖြစ် Java ကို အသုံးပြုလေ့ရှိ၏။ Java ၏ ပတ်ဝင်းကျင်သည်၊ Java ပလတ်ဖေါင်း (Java Runtime Environment; JRE) ဟု ခေါ်ဆိုလေ့ရှိ၏။ Java ၏ အခြေခံ ရေးသားနိုင်သော ပတ်ဝင်းကျင်ကိုJava Development Kit (Java Development Kit; JDK) ဟု ခေါ်ဆို၏။

Java သည်Class ကို အခြေခံသော ဝတ္တစက္ခုဗေဒ(Object-Oriented) ပရိုဂရမ်မင်း ဘာသာရပ် တစ်ခု ဖြစ်၏။ Java၏ပရိုဂရမ်သည်၊ classများဖြင့် ဖွဲ့စည်းထားပြီး၊ ပရိုဂရမ်ကို အလုပ်လုပ်စေသောအခါ၊ ထို Class များကို အခြေခံပြီး ပြုလုပ်ထားသော ရုပ်ဝတ္တု(Object) များက အပြန်အလှန်ဆက်သွယ်ခြင်း အားဖြင့် အလုပ်လုပ်စေပါသည်။ Java သည်အမွေဆက်ခံခြင်းသဘောတရားကို အသုံးပြုနိုင်ပြီး Class တစ်ခုမှ အခြားသော Class ၏ အချက်အလက်နှင့် လုပ်ဆောင်ချက်များကို အမွေဆက်ခံခြင်းဖြင့် ပြန်လည်အသုံးပြုနိုင်၏။ အမွေဆက်ခံရာတွင် တစ်ခုတည်းမှသာ အမွေဆက်ခံနိုင်မည် ဖြစ်၏။ သို့ရာတွင် ကလပ်စ် တစ်ခုမှ၊ တစ်ခုထက်မကသော အင်တာဖေးစ်များကို ပံ့ပိုးပေးနိုင်ပါသည်။ Java တွင်အသုံးပြုသော အချက်အလက်ပုံစံ（Data Type）သည် တည်ငြိမ်၍ ခိုင်မာသောပုံစံကို အသုံးပြုထား၏။ ဤကဲ့သို့ Java ၏ကွန်ပိုင်းလာနှင့် အသုံးချ ပတ်ဝင်းကျင်သည်၊ အချက်အလက်ပုံစံများ၏ စစ်မှန်ချက်ကို စစ်ဆေးခြင်းအားဖြင့်၊ ပရိုဂရမ်က မှန်ကန်စွာအလုပ်လုပ်နိုင်ခြင်းနှင့် လုံခြုံစွာ အလုပ်လုပ်နိုင်ခြင်းတို့ အပေါ်တွင် အာမခံပေးနိုင်ပါသည်။

Java သည် ခြွင်းချက်လုပ်ဆောင်ချက်စနစ်ကို ပြင်ဆင်ထားပြီး၊ပရိုဂရမ် အလုပ်လုပ်နေစဉ် ဖြစ်ပွားတက်သော မျှော်လင့်မထားတတ်သော အမှားများကို၊ လုံခြုံစိတ်ချသောနည်းလမ်းဖြင့် လုပ်ဆောင်စေနိုင်ပြီး၊ ပရိုဂရမ်တစ်ခုကိုလည်း ရှင်းလင်းစွာ ရေးသားနိုင်ပါသည်။

Java မှာတော့ သန့်ရှင်းသော မံမိုရီမော်ဒယ်ကို အသုံးပြုထားသောကြောင့်၊ ပရိုဂရမ်မာက မံမိုရီထိမ်းသိမ်းမှု့ အပေါ်တွင် သက်သာစေပေသည်။ Java Object များသည် မံမိုရီအတွင်းရှိHeap Memory နေရာကို အသုံးပြုကြ၏။ မံမိုရီထိမ်းသိမ်းခြင်းသည်Java Virtual Machineတွင် ပူးတွဲပါဝင်သော အမှိုက်သိမ်းစနစ်ဖြင့် ထိမ်းသိမ်းထားနိုင်၏။ C++ မှာတော့ Heap Memory အပေါ်တွင် နေရာချထားသော Object များကို အသုံးမလိုသည့်အခါ ဖျက်စီးပစ်ရန် ပရိုဂရမ်မာက တာဝန်ယူ၍ လုပ်ဆောင်ရန် လိုအပ်ခဲ့ပေသည်။ ဤအချက်သည် C++ ပရိုဂရမ်မာအတွက် ဝန်ထုပ်တစ်ခုအနေနဲ့ ဖြစ်ခဲ့ပြီး၊ ရှုပ်ထွေးပြီး မှာယွင်းလွယ်တတ်ပေသည်။ Java မှာတော့ အမှိုက်သိမ်းစနစ် ကို ပိုင်ဆိုင်သောကြောင့် မံမိုရီကို ထိမ်းသိမ်းရန်ဝန်ထုပ် မရှိပါသဖြင့် ပရိုဂရမ်မာအတွက် လွန်စွာမှအစဉ်ပြေစေခဲ့ပါသည်။

Java၏ ရေးသားပုံသည်၊ Cနှင့်C++ မှ အတော်များများကို အတုယူခဲ့၏။ တဖန် C/C++ တွင် အသုံးပြုသော အခြေခံနေရာများကို ထိမ်းသိမ်းအသုံးပြုနိုင်သောPointerကို အသုံးမပြုပါဟုဆိုသော်လည်း၊ လက်တွေ့မှာတော့ C/C++ ၏ Pointer Model နှင့်မတူသော၊ Pointer Model ကို Java တွင်လည်း အသုံးပြုထားပါသည်။ ဥပမာအားဖြင့် Class Instance နှင့် Array များတွင် Pointer ကို အသုံးပြုထားပါသည်။ “ClassName a = new ClassName();”နှင့် “ClassName b;”ပြန်လည် သတ်မှတ်ပြီး “b = a” အစားထိုးခြင်းအားဖြင့် b သည် a ၏ ပိုင်ဆိုင်မှု့များ ကို အသုံးချနိုင်မည် ဖြစ်သည်။ ဆိုလိုသည်မှာ a,b တွင် လိပ်စာများကို သတ်မှတ်ထားခြင်း ဖြစ်၏။ ဖော်ပြပါအတိုင်း Instance ၏ အမည်တွင် ဗားရှင်း1.2 နှင့် မတိုင်မှီက Object Handle（pointer ၏ pointer）၊ ဗားရှင်း1.3 ၏ နောက်ပိုင်းတွင် pointer ကို အသုံးပြုထားပါသည်။ ထို့ကြောင့် Java သည် ယနေ့တိုင် Pointer နှင့် ဖြတ်ချင်သော်လည်း မပြတ်နိုင်သော အနေအထား တစ်ခုဖြစ်နေရပါသည်။

Java သည်ပလက်ဖေါင်းအပေါ်တွင် မှီခိုခြင်း မရှိစေရ ဟူသည်ကို ဦးတည်ချက်ထားပြီး၊ ဗားရှင်း တစ်ခုနှင့်တစ်ခု ကြားတွင်လည်း အပြန်အလှန်အသုံးချနိုင်မှု့အပေါ် သတိပြု၍ တီထွင်ဖန်တီးမှု့များ ပြုလုပ်လျှက်ရှိ၏။ Java နည်းပညာကို အသုံးပြုခြင်းအားဖြင့်၊ ပလက်ဖေါင်းအပေါ်တွင် မှီခိုခြင်းမရှိသော အပလီကေးရှင်း ဆော့ဖ်ဝဲ ကို ရေးသား၊ အသုံးပြုနိုင်မည် ဖြစ်သည်။ ယနေ့ပရိုဂရမ်မင်း ဘာသာရပ်အတော်များများသိ ပလက်ဖေါင်း (CPU) အပေါ်တွင် မှီခိုခြင်းရှိသော သဘာဝကုဒ်များ အဖြစ်ကွန်ပိုင်းလုပ်ခြင်းကို ပုံစံဖြင့် ဒီဇိုင်းရေးသားထားကြ၏။ သို့ရာတွင် Java သည် အထက်ပါ ဘာသာရပ်များနှင့် မတူပဲ ကြားခံဘာသာ（Byte Code）အဖြစ် ကွန်ပိုင်းလုပ်ပြီး၊Java VMတွင် အလုပ်လုပ်နိုင်စေရန် ဒီဇိုင်းရေးသားထား၏။ အတော်များများသည် Just In Time ကွန်ပိုင်းပုံစံ ကို အသုံးပြုထားကြပါသည်။

ပလက်ဖေါင်းအပေါ်တွင် မမှီခိုခြင်းနှင့် ဗားရှင်းကြားတွင် အပြန်အလှန်အသုံးပြုနိုင်ခြင်း တို့သည်၊ လက်ရှိအနေအထားအရ အပြည့်အဝ အကောင်ထည်ဖော်နိုင်ခြင်း မရှိသေးပဲ ပြဿနာများလည်း အနည်းငယ်ရှိနေပါသေးသည်။

Java တွင်Thread ကို ဘာသာရပ်၏ အခြေခံအသုံးပြုပုံအနေဖြင့် သတ်မှတ်ထားပြီး၊ Multi Thread ဖြင့်Parallel Computing ကို အခြားသော ကွန်ပျူတာဘာသာရပ်များနှင့် စာလျှင် လွန်စွာလွယ်ကူစွာ အသုံးပြုနိုင်မည် ဖြစ်သည်။ Parallel Computingသည်၊ လုပ်ဆောင်ချက်များကို တစ်ကြိမ်တည်းတွင် လုပ်ဆောင်နိုင်သည့် ပုံစံဖြစ်၏။ တဖန်Thread သည်၊Process ထက် ပေါ့ပါးသေးငယ်၏။

Java သည် ပြည့်စုံသော Library များကို အသုံးပြု၍၊ကွန်ပျူတာ ကွန်ယက်ကို အသုံးပြုနိုင်သော ဆော့ဖ်ဝဲကို၊ အချိုးကျကျ ဖန်တီး နိုင်မည်ဖြစ်သည်။ Java သည် ဦးဆုံးဗားရှင်းကတည်းက၊ TCP/IP၏ Library ကို ပြင်ဆင်ထားခဲ့၏။ Distributed Object ပတ်ဝင်းကျင်အတွက်လည်း (Java RMI, CORBA) အပေါ်တွင် အခြေခံသော ဆော့ဖ်ဝဲများကိုလည်း အချိန်အတော်စောစောကတည်းက ဖန်တီးရေးသားနိုင်ခဲ့၏။ ယနေ့အခါတွင် အမျိုးမျိုးသောNetwork Protocol များ၏ အဆင့်မြင့် library များကို ပြင်ဆင်ထားပြီးဖြစ်၏။ ပြီးပြည့်စုံသော Network ဖန်ရှင်များနှင့် အောက်ဖော်ပြပါ XML ကို တွဲဖက် အသုံးပြုခြင်းအားဖြင့်၊ အဆင့်မြင့် System များကို တည်ဆောက်နိုင်သော ပရိုဂရမ်မင်းဘာသာရပ် တစ်ခုဖြစ်၏။

XML ကို အသုံးပြုနိုင်သော ဖန်ရှင်များကိုလည်း အချိန်စောစောကတည်းက ပြင်ဆင်ခဲ့၏။ XML သည် ယနေ့နယ်ပယ်အတော်များများတွင် အသုံးပြုနိုင်သော အချိုးကျ စာရေးစနစ် နည်းပညာတစ်ခုဖြစ်၏။ ယနေ့ အချိန်အခါတွင် XML Processor နှင့်XSLT Processor များသည် Java အခြေခံ Library တွင် ထည့်သွင်းထားပြီး ဖြစ်၏။

Java သည်လုံခြုံရေး ကို အဓိကထားပြီး ဒီဇိုင်းရေးထားသောSand Box မော်ဒယ်တွင် အခြေခံသော လုံခြုံရေးစနစ်ကို ပြင်ဆင်ထား၏။ လုံခြုံရေးစနစ်ကို မှန်ကန်စွာအသုံးပြုထားသော Java အသုံးချ ပတ်ဝင်းကျင်ကို အသုံးပြုခြင်းအားဖြင့်၊ အဝေးတနေရာတွင် ရှိသော Java အသုံးချကုဒ်များကို လုံခြုံစွာအသုံးပြုနိုင်မည် ဖြစ်သည်။（Java Applet）

တဖန်Namespace စနစ်ကို အသုံးပြုထားသော ဘာသာရပ်တစ်ခုဖြစ်ပြီး၊ Library နှင့် အပလီကေးရှင်း တွင်ပါဝင်သော Java များ（ကလပ်စ် နှင့် အင်တာဖေစ်）သည်၊ Package (Java) ဟု ခေါ်သော အဆင့်ဆင့်ခွဲခြား ထိမ်းသိမ်းမှု့စနစ်ဖြစ် ခွဲခြားအသုံးပြုနိုင်မည်ဖြစ်သည်။

ယနေ့ခေတ်တွင် Java နှင့် ပတ်သက်ပြီး ဝေဖန်ချက်များလည်း မနည်းပေ။ အချို့သော ဝေဖန် ရှုတ်ချမှု့များနှင့်ပတ်သက်ပြီး၊ Sun နှင့် JCP တွင်ပါဝင်ခဲ့သော အဖွဲ့ဝင်များ၏ အားထုတ်မှု့များကြောင့်၊ Java ၏ ပြုပြင်ပြောင်းလည်းမှု့များကို ပြုလုပ်လျှက်ရှိပါသည်။ တပြိုင်နက်တည်းမှာပင် ဆော့ဖ်ဝဲ ရေးသားသူအတော်များများက Java နှင့် ပတ်သက်ပြီး ကျယ်ကျယ်ပြန့်ပြန့် အသုံးပြုနိုင်သော ထူးချွံသော ပရိုဂရမ်မင်းဘာသာရပ်တစ်ခု အဖြစ် အသိအမှတ်ပြုထားကြပါသည်။

Java ၏သမိုင်းကြောင်းမှာ ရေးသားဆဲဖြစ်၍ ရေးသားပြီးပါက ပြန်လည် ဖော်ပြသွားပါဦးမည်။

လေးစားစွာဖြင့်
မင်းလွင်

]]> http://tech4mm.com/2011/08/java-%e1%80%86%e1%80%ad%e1%80%af%e1%80%9e%e1%80%8a%e1%80%ba%e1%80%99%e1%80%be%e1%80%ac/feed/ 0 Open Courseware Myanmar (OCW Myanmar) http://tech4mm.com/2011/08/open-courseware-myanmar-ocw-myanmar/ http://tech4mm.com/2011/08/open-courseware-myanmar-ocw-myanmar/#comments Tue, 23 Aug 2011 16:49:36 +0000 Dr. Aung Win Htut http://tech4mm.com/?p=268
Very good site for Education. You should visit there NOW!

https://www.facebook.com/pages/Open-Courseware-Myanmar-OCW-Myanmar-/154218721317769?sk=info

]]> http://tech4mm.com/2011/08/open-courseware-myanmar-ocw-myanmar/feed/ 0 အင်ဗာတာ-မော်တာ ဒီဇိုင်းဆိုင်ရာ ပြဿနာများ(၁) http://tech4mm.com/2011/08/%e1%80%a1%e1%80%84%e1%80%ba%e1%80%97%e1%80%ac%e1%80%90%e1%80%ac-%e1%80%99%e1%80%b1%e1%80%ac%e1%80%ba%e1%80%90%e1%80%ac-%e1%80%92%e1%80%ae%e1%80%87%e1%80%ad%e1%80%af%e1%80%84%e1%80%ba%e1%80%b8%e1%80%86/ http://tech4mm.com/2011/08/%e1%80%a1%e1%80%84%e1%80%ba%e1%80%97%e1%80%ac%e1%80%90%e1%80%ac-%e1%80%99%e1%80%b1%e1%80%ac%e1%80%ba%e1%80%90%e1%80%ac-%e1%80%92%e1%80%ae%e1%80%87%e1%80%ad%e1%80%af%e1%80%84%e1%80%ba%e1%80%b8%e1%80%86/#comments Sun, 21 Aug 2011 06:10:43 +0000 Dr. Aung Win Htut http://tech4mm.com/?p=252

အင်ဒတ်ရှင်း မော်တာတွေဟာ လျှပ်စစ်စွမ်းအင်ကို အများဆုံး အသုံးချတဲ့ ပစ္စည်းတွေဖြစ်တဲ့ အတွက် သူ့ရဲ့ efficiency ကိုပိုကောင်းအောင် ပြုလုပ်ခြင်းဟာ အဓိက ကျတဲ့ လိုအပ်ချက်ဖြစ်ပါတယ်။ ဒီနည်းအားဖြင့် သုံးစွဲသူအနေနှင့် ရေရှည်တွင် လျှပ်စစ် စွမ်းအင် အတွက် ကုန်ကျစားရိတ် သိသိလာသာ သက်သာလာမည်ဖြစ်သည်။ ဒီဇိုင်နာများအနေနှင့်မူ ပြင်ဆင်မှု လွယ်ကူအောင်၊ အသံဆူညံမှု နည်းအောင် နဲ့ ခနခန ပျက်မှာကို မပူရဘဲ စိတ်ချယုံကြည်စွာ ရေရှည်သုံးနိုင်အောင် ရှုပ်ထွေးခက်ခဲစွာ ဒီဇိုင်းပြုလုပ်ကြရမှာ ဖြစ်ပါတယ်။
ဒီလိုမော်တာတွေ လုပ်ဖို့ ကို နည်းပညာပိုင်း ငွေကြေးအရင်းအနှီးပိုင်း လိုအပ်ချက်တွေ လိုလာမှာကို ထည့်တွက်ကြရမယ်။ *မော်တာတွေကို ခေတ်မီဖို့ ပြင်ဆင်ရာမှာ machine line တွေကို အကုန်လဲလှယ်ဖို့ လိုတဲ့ အတွက် မလွယ်ကူပေမယ့် အခုမှ စလုပ်မဲ့ သူတွေ အတွက် အစတည်းက ဒီလို မျိုးလုပ်ဖို့ စဉ်းစားသင့်တယ်။
ခုခေတ်မော်တာ အတော်များများဟာ အိမ်သုံး စက်ရုံသုံး လျှပ်စစ် ဓါတ်အားပေးလိုင်းတွေနဲ့ တိုက်ရိုက် ချိတ်ဆက်အသုံးပြုဖို့ကိုသာ ဒီဇိုင်းပြုလုပ်ထားတာ ဖြစ်ပါတယ်။ ၄င်းတို့ကို အမြောက်အများ ပုံစံတူ ထုတ်လုပ်လေ့ရှိပြီး series မော်တာများဟု ခေါ်ဆိုပါသည် (ဥပမာ-4A series, 5A series)။ ဆိုလိုတာက input voltage နဲ့ frequency ကို constant အနေနဲ့ ယူဆပြီး အဲဒီ rated vale တွေမှာပဲ အလုပ်အကောင်းဆုံးလုပ်အောင် ဒီဇိုင်း ပြုလုပ်ထားတာ ဖြစ်ပါတယ်။ မြန်မာ စျေးကွက်မှာ အများဆုံး ရှိနေတာက အဲလို မော်တာမျိုးတွေပါ။ အင်ဗာတာ နဲ့ တွဲသုံးပြီး frequency အမျိုးမျိုး၊ ဗို့အား အမျိုးမျိုး နဲ့ သုံးနေရတဲ့ အခြေအနေမျိုးအတွက် သင့်တော်ခြင်းမရှိပါဘူး။
တစ်ခါ စက်မှု သုံးမဟုတ်ဘဲ အိမ်သုံး အနေနဲ့ မော်တာကို သုံးတဲ့ အခါမှာ အိမ်သုံးလျှပ်စစ်လိုင်းက စင်ဂယ်ဖေ့စ် ပဲရှိတဲ့ အတွက် စင်ဂယ်ဖေ့စ် မော်တော်တွေကို သုံးကြပါတယ်။ တကယ်က စင်ဂယ်ဖေ့စ် မော်တာအစစ်တွေဟာ သီးသန့် ဒီဇိုင်းလုပ်ကြရပြီး ပါဝါများများ အတွက် အသုံးပြုလျင် losses များလို့ မသင့်တော်ပါ။ ဒီအခါမှာ ကွန်ဒန်စေတာ (Capacitor) များကို သုံးပြီး သရီးဖေ့စ် မော်တာများကို စင်ဂယ်ဖေ့စ် အဖြစ်ပြောင်းလဲ ကာ တွက်ချက် အသုံးချလာကြပါတယ်။ ဆိုလိုတာက စျေးကွက်မှာ အလွယ်ရတဲ့ သရီးဖေ့စ် မော်တာ တစ်လုံးကို ကွန်ဒန်စေတာ နဲ့ တွက်ချက်ထားတဲ့ အတိုင်း ချိတ်ဆက်လိုက်တဲ့ အခါမှာ စင်ဂယ်ဖေ့စ် ပါဝါ ဆပ်ပလိုင်းနဲ့ ချိတ်ဆက်သုံးနိုင်တဲ့ စင်ဂယ်ဖေ့စ်မော်တာတစ်လုံးကို ရရှိပါတယ်။ ပုံမှာကြည့်ပါ။

ဒီပုံတွေမှာ a,b,c ဆိုတာက သရီးဖေ့စ် မော်တာရဲ့ စတေတာက winding ၃ ခု ဖြစ်ပါတယ်။ ၄င်းတို့မှ ထွက်လာတဲ့ ကြိုးစတွေကို ပုံမှာ ပြထားတဲ့ အတိုင်း capacitors ၂ ခု (Cp and Co) နဲ့ ချိတ်ဆက်ပြီး U ဆိုတဲ့ စင်ဂယ်ဖေ့စ် လိုင်းကို ချိတ်ဆက် အသုံးပြုနိုင်တယ်ဆိုတာကို ပြထားတာဖြစ်ပါတယ်။ ဒါက ကၽွန်တော့် မာစတာ သီးစစ် ဖြစ်ခဲ့ပါတယ်။ အဲဒီလို ချိတ်ဆက်ဖို့မှာ ဘယ်လို မော်တာမျိုးကို capacitors တန်ဖိုး ဘယ်လောက်တွေနဲ့ ဘယ်လို နည်းလမ်းမျိုး နဲ့ ချိတ်ဆက်မယ်ဆိုရင် ဘယ်လိုဖြစ်လာမယ်ဆိုတာကို အသေအချာတွက်ချက်လေ့လာပြီးမှ လက်တွေ့ အသုံးချရမှာ ဖြစ်ပါတယ်။ မြန်မာပြည်မှာ စင်ဂယ်ဖေ့စ်မော်တာ အများစုက ဒီလို မော်တာမျိုးဖြစ်ပါတယ်။

ဒီလိုမော်တာတွေဟာ အင်ဗာတာတွေ မပေါ်ခင်နဲ့ စျေးနှုန်းကြီးမြင့် စဉ်က အသုံး များခဲ့ပေမယ့် အခုအခါ အင်ဗာတာတွေ စျေးကျလာပြီး efficiency ကို အဓိက လိုချင်လာတဲ့အခါ၊ ကွန်ထရိုးလုပ်ချင်လာတဲ့ အခါမှာ interver fed induction motor drive တွေကို ပြောင်းလဲ အသုံးပြုလာနေပါပြီ။ ခုလောလောဆယ် အမေရိကန်မှာ ထုတ်ပြန်တဲ့ 1992 ဥပဒေ ЕРАСТ (Energy Policy Аct 1992) မှစတင်ပြီး မော်တာများရဲ့ minium efficiency ကို တိုးမြှင့်ထုတ်လုပ်အောင် တွန်းအားအများကြီးပေးခဲ့ပါတယ်။
ဥရောပ နိုင်ငံများကလည်း အဲဒီ စံနှုန်းတွေကို လက်ခံခဲ့ကြပါတယ်။ မော်တာထုတ်လုပ်သူများက အဲဒီဥပဒေအရ ပြဌာန်းထားတဲ့ စံနှုန်း များထက် လျော့နည်းပြီး ထုတ်လုပ်ပါက ဒဏ်ငွေ အမြောက်အမြား အတပ်ခံရမှာ ဖြစ်ပါတယ်။ အောက်မှာ ဖေါ်ပြထားတဲ့ တေဘယ်လ် ကတော့ အဲဒီ စံနှုန်းတစ်ချို့ပဲ ဖြစ်ပါတယ်ခင်ဗျာ။


အင်ဗာတာတွေ သုံးလာကြတဲ့ အခါ စွမ်းဆောင်ရည်အသစ်တွေ ရရှိလာပေမယ့် အခြားတစ်ဘက်မှာလည်း ပြဿနာတွေ တစ်ပုံကြီး တွေ့လာရပါတယ်။ ယနေ့ တစ်ချို့ ထုတ်လုပ်ရေး လုပ်ငန်းများတွင် inverter-motor drive များထုတ်လုပ်ရာတွင် အချို့ သတိပြုရမည့်အချက်များကို သေချာ ထည့်သွင်း စဉ်းစားခြင်းမပြုကြသေးပေ။ အထူးသဖြင့် အမေရိကန်နှင့် ဥရောပမှလွဲ၍ ကျန်သောနိုင်ငံများရှိ မော်တာထုတ်လုပ်သူများသည် များသောအားဖြင့် series လိုက်ထုတ်နေသာ သာမာန် motor များကိုသာ အလွယ်ရယူ၍ အင်ဗာတာနှင့် တွဲဖက်ကာ သုံးစွဲလိုက်ကြသည်သာဖြစ်သည်။ (အတိအကျ သုတေသန မပြုထားရသေးသောအချက်ဖြစ်ပါသည်။ စာတမ်းများမှ လေ့လာ ထားချက်များအရ သိရခြင်း ဖြစ်ပါသည်)။ technical parameters များကို modernize လုပ်ရန် နားမလည်ကြသေးချေ။ စားသုံးသူများ၏ လျှပ်စစ်စွမ်းအင်အပေါ် ရေရှည် ကုန်ကျစားရိတ် သက်သာအောင် သို့တည်းမဟုတ် နိုင်ငံ၏ လျှပ်စစ်စွမ်းအား သုံးစွဲမှုကို ရေရှည်တွင် ထိရောက်စွာ ခေျွတာနိုင်မည့် energy saving motor များကို ဒီဇိုင်းပြုလုပ်ခြင်း လည်းမရှိပေ။ ထို့ပြင် မော်တာ၏ သက်တမ်းနှင့် ယုံကြည်စိတ်ချရမှု စသည်တို့နှင့် ဆိုင်သော မဖြေရှင်းရသေးသည့် ပြဿနာများလည်း ကျန်နေပေသေးသည်။series အလိုက်ထုတ်သော motor များသည် rated conditions များတွင်သာ ကောင်းစွာ အလုပ်လုပ်ရန် ထုတ်လုပ်ထားခြင်းသာဖြစ်သည်။ အကယ်၍ motor ကို regulation ပြုလုပ်သုံးစွဲမည်ဆိုပါက မော်တာနှင့် အင်ဗာတာ အပြန်အလှန် ဆက်နွယ်မှု သဘောတရားများကို အသေအချာထည့်တွက်ရမည်ဖြစ်ရာ ဒီဇိုင်းပြုလုပ်ရန်၊ ထုတ်လုပ်ရန် ပိုမို ရှုပ်ထွေးလာရမည်သာဖြစ်သည်။ Scalar control နည်းစံနစ်များကို အသုံးပြုပါက frequency နည်းလေ staror ရှိ inductance တန်ဖိုးများ ကျဆင်းလေဖြစ်ပြီး resistance တန်ဖိုးများမှာလည်း အလွန်ကျဆင်းကာ stator current မတည်ငြိမ်တော့ဘဲ ရုတ်တရက် မြင့်တက်ကာ motor ၏ Torque လည်း stable မဖြစ်နိုင်တော့ပေ။ ထိုအချက်ကို အထူးသဖြင့် Torque stable ဖြစ်ရန် လိုအပ်သော ၀န်ချီစက်များ၊ ဓါတ်လှေခါးများ ရိုလာစက်များတွင် အသုံးပြုသော inverter-motor များ ဒီဇိုင်းပြုလုပ်ရာတွင် ထည့်သွင်းတွက်ချက်ရန် အရေးကြီးပေသည်။
ဒီအခက် အခဲ ကို ကျော်လွန်ဖို့ လက်တွေ့မှာ မော်တာနဲ့ အင်ဗာတာကို ပိုပြီး ပါဝါ များတာကို ၀ယ်ကြရလို့ စျေးပိုကြီးလာရတယ်။
energy saving မော်တာကို ပြောင်းလဲ ဒီဇိုင်းပြုလုပ် ရာမှာ ကုန်ကြမ်း 15-30% ပိုမို သုံးစွဲရတာကို အတွက်အချက်များအရ သိရပါတယ်။ efficiency 1% တိုးဖို့အတွက် active material တွေရဲ့ mass 3-6% ပိုမို သုံးစွဲရပါတယ်။ ဒါကြောင့် စျေးနှုန်းမှာ ရိုးရိုးမော်တာထက် 25% ပိုများနေရပါတယ်။ ပြီးတော့ moment of inertia ကလဲ 20-50% ပိုတိုးလာပါတယ်။ ဒါကြောင့် special design သာသေချာ လုပ်မထားနိုင်ခဲ့ရင် ဒိုင်းနမစ် အခြေအနေမှာ ရိုးရိုးမော်တာထက် ကို ပိုဆိုးနိုင်ပါတယ်။
မော်တာ ထုတ်လုပ်ရာတွင် အသုံးပြုသော ပစ်စည်းများ၏ စျေးနှုန်းများကို လေ့လာရာတွင် ၄င်းစျေးနှုန်းများသည် တဖြည်းဖြည်းခြင်း မြင့်တာလာမည့် အလားအလာကို အခိုင်အမာပင် တွေ့ရှိရပေသည်။
electrical steel တန်ဖိုး 50%ခန့် မြင့်တက်လာတယ်။ ဝါယာနဲ့ပက်သက်တဲ့ ပစ္စည်းတွေ 31% မြင့်တက်လာပြီး သံကြွပ်တန်ဖိုး ၈၀% အထိ ထိုးတက်သွားတယ်။ ပစ္စည်းတွေ စျေးတက်လာတယ် ဒါကြောင့် မော်တာ ဖိုးကို စျေးတင်လိုက်ရတယ်။ ဒါ့အပြင် ဒီလိုထပ်ဖြစ်ဖို့ အခွင့်အလမ်းတွေ များနေသေးတယ်။ တစ်ချိန်တည်းမှာ အင်ဗာတာတွေ စျေးကျလာပြီး မော်တာနဲ့ စျေး အတူတူလောက်ဖြစ်လာတယ်။
ဒီကနေပြီး ဘာသုံးသပ်လို့ ရလာသလဲဆိုတော့ မော်တာကို drive အတွက်သီးသန့် ဒီဇိုင်းထုတ်တာဟာ အဲဒီ drive ရဲ့စျေးကို ကျသွားဖို့ အများကြီး အကျိုးသက်ရောက်မှု ရှိတယ် ဆိုတာပါပဲ။ နောက်ပြီးတော့ နည်းပညာပိုင်း အရည်အသွေးတွေ ပိုကောင်းလာပြီး reliability ပိုများ လာစေပါတယ်။
ဒါကြောင့် အင်ဗာတာနဲ့ တွဲသုံးမယ့် မော်တာတွေဟာ construction ပိုင်းတွေမှာ သာမာန် မော်တာတွေနဲ့ မတူဘဲ သီးသန့် ဒီဇိုင်းပြုလုပ်ဖို့ လိုလာပါတယ်။
ဒီလိုပြောင်းလဲမှုတွေ လုပ်ရာမှာ မော်တာကို magnetic system အသစ် ဖြစ်အောင် လုပ်ကြရမယ်၊ rotor slot တွေ ပုံစံ ပြောင်းလဲရမယ်၊ squirrel cage rotor အတွက် material အသစ်တွေလည်း ပြောင်းလဲ သုံးစွဲတာတွေ ပြုလုပ်ရပါမယ်။
မော်တာရဲ့ insulation တွေဟာ အင်ဗာတာ နဲ့ တွဲသုံးတဲ့ အတွက်ကြောင့် ပိုမို စိတ်ချရအောင် ပြုလုပ်ထားရမယ်။ ဘာလို့လဲ ဆိုတော့ high frequency ရှိတဲ့ PWM ရဲ့ ဗို့အားက သာမာန် သုံးနေကျ insulator တွေကို ပျက်စီးသွားစေနိုင်လို့ပဲ ဖြစ်တယ်။ 75 ကီလို၀ပ် ထက်ကြီးတဲ့ မော်တာတွေ အတွက်ဆို ဘယ်ရင်းတွေမှာ စီးဆင်းနေတဲ့ current ကို ခန့်မှန်းဖို့ ရှုပ်ထွေးမှုက အခက်အခဲ တစ်ခု ဖြစ်တယ်။ အဲဒီ current က မော်တာနဲ့ ချိတ်ထားတဲ့ encoder ကို အနှောက်အယှက် ဖြစ်စေနိုင်တယ်။ အဲဒီ encoder က ကွန်ထရိုး စစ်စတမ် ရဲ့ အစိတ်အပိုင်းတစ်ခု ဖြစ်ပါတယ်။
အချုပ်အားဖြင့် ဆိုရမည်ဆိုလျင် inverter fed induction motor special design အတွက် လောလောဆယ် မဖြေရှင်းနိုင်သေးသော ပြဿနာများ၊ ထည့်သွင်းစဉ်းစားရန် အချက်များ တစ်ပုံတစ်ခေါင်းကြီး ကျန်ရှိနေပေသေးသည်။ ထိုအချက်များကို ဖြေရှင်းသည့်နည်းလမ်းများ ရှာရန် ဒီဇိုင်နာများအနေဖြင့် ကြိုးပမ်း ၍ သုတေသနများပြုလုပ်နေကြဆဲဖြစ်ကြောင်း တင်ပြအပ်ပါသည်ခင်ဗျား။
ဘလူးဖီးနစ်
http://engineer4myanmar.com
ကျမ်းကိုးစာရင်း
1. Беспалов В.Я , Макаров Л.Н. Основные направления совершенствования конструкций и технологии производства низковольтных асинхронных двигателей. Г.Москва МЭИ (ТУ), РУСЭЛПРОМ.
2. http://www.aceee.org/motors/epactapp.htm

ဒီဆောင်းပါးကို ပီဒီအက်ဖ် PDF နဲ့ သိမ်းထားချင်တယ်ဆိုရင် ဒီနေရာ ကနေရယူပါ။

]]> http://tech4mm.com/2011/08/%e1%80%a1%e1%80%84%e1%80%ba%e1%80%97%e1%80%ac%e1%80%90%e1%80%ac-%e1%80%99%e1%80%b1%e1%80%ac%e1%80%ba%e1%80%90%e1%80%ac-%e1%80%92%e1%80%ae%e1%80%87%e1%80%ad%e1%80%af%e1%80%84%e1%80%ba%e1%80%b8%e1%80%86/feed/ 3