มีใครพยายามใช้ C # สำหรับ JVM หรือไม่ ในฐานะนักพัฒนา Java ฉันมอง C # ด้วยความอิจฉา แต่ฉันไม่เต็มใจที่จะสละความสามารถในการพกพาและวุฒิภาวะของ JVM ไม่ต้องพูดถึงเครื่องมือที่หลากหลายสำหรับมัน
ฉันรู้ว่ามีความแตกต่างที่สำคัญระหว่าง JVM และ CLR แต่มีอะไรที่เป็น showstopper หรือไม่?
คำตอบ:
มีความแตกต่างที่สำคัญมากระหว่าง CLR และ JVM
ตัวอย่างบางส่วน:
คุณอาจพอร์ตC # จำนวนมาก - แต่คุณจะเหลือประสบการณ์ที่ไม่น่าพอใจ IMO
ไปอีกทางคุณรู้จักIKVMหรือไม่? ช่วยให้คุณสามารถรันโค้ด Java ใน. NET
ไปที่http://code.google.com/p/stab-language
รหัสด้านล่างหากเป็นรหัสภาษา Stab สำหรับ JVM
using java.lang;
using stab.query;
public class Test {
public static void main(String[] args) {
// Sorts the arguments starting with "-" by length and then using the default
// string comparison
var query = from s in Query.asIterable(args)
where s.startsWith("-")
orderby s.length(), s
select s;
foreach (var s in query) {
System.out.println(s);
}
}
}
Grasshopperสามารถใช้ CLR bytecode และถ่ายทอดเป็น JVM ได้ มีไว้สำหรับเว็บแอปเป็นหลักโดยไม่มีให้เช่นการใช้งาน JVM ของคลาส Windows Forms ดูเหมือนจะค่อนข้างล้าสมัย เว็บพูดถึง ASP.NET 2.0, Visual Studio 2008 และอื่น ๆ กล่าวถึงครั้งแรกโดย @alex
XMLVMสามารถใช้ CLR หรือ JVM bytecode เป็นอินพุตและสร้างเป็นเอาต์พุต นอกจากนี้ยังสามารถส่งออก Javascript หรือ Objective-C ยังไม่มีการเผยแพร่มีเพียงการโค่นล้ม "เวอร์ชันทดลองพัฒนาที่ห้ามใช้ในสภาพแวดล้อมการใช้งานจริง"
IKVMไปในทิศทางอื่นที่ OP ต้องการ จัดเตรียมการใช้งาน JVM ที่รันบน CLR, JVM ถึง CLR bytecode Transpiler และตัวสร้างต้นขั้วเมธอดไลบรารี CLR สำหรับ Java http://www.ikvm.net/uses.htmlพูดถึงโดย @Jon Skeet
เหตุใดจึงไม่ให้ CLR และ JVM ทำงานควบคู่ไปและทำให้การสื่อสารราบรื่นที่สุด นี่ไม่ใช่สิ่งที่ OP ต้องการ แต่คำตอบอื่น ๆ นั้นค่อนข้างไม่ตรงประเด็นในรูปแบบที่แตกต่างกันดังนั้นเรามาพูดถึงมัน
RabbitMQมีตัวเลือกฟรีเป็นเซิร์ฟเวอร์ RPC ที่เขียนด้วย Erlang พร้อมไลบรารี API สำหรับ C # Java และอื่น ๆ
jnBridgeใบอนุญาตอาจแพงเกินไปสำหรับผู้ใช้ที่คาดหวังบางราย
gRPCและไลบรารี RPC สมัยใหม่ที่คล้ายคลึงกันให้การสนับสนุนภาษาที่กว้างการสร้างรหัสสำหรับไลบรารีไคลเอ็นต์ในภาษาเหล่านี้รูปแบบสายที่เป็นอิสระของภาษาสำหรับข้อมูลคุณสมบัติขั้นสูงเช่นการยกเลิกการโทรแบบเรียงซ้อนและอื่น ๆ
เขียนครั้งเดียววิ่งได้ทุกที่;)
Haxeรวบรวมเป็น C # / CLR, Java / JVM, Javascript, Flash, Python, ... จัดเตรียมกลไกการทำงานร่วมกันสำหรับภาษาเป้าหมายแต่ละภาษา สามารถคิดได้ว่าเป็นตัวตายตัวแทนของ ActionScript3 ในระดับหนึ่ง ดูเหมือนจะเป็นเรื่องที่ค่อนข้างมั่นคงโดยมีอย่างน้อยหนึ่ง บริษัท ขึ้นอยู่กับมัน น่าเชื่อถือมากกว่า Stab ที่กล่าวถึงต่อไป
Stabนำเสนอคุณสมบัติ C # และการทำงานร่วมกันของ Java ไม่มีประโยชน์มากนักคุณจะได้รับคุณสมบัติ C # บางอย่าง แต่สิ่งที่คุณโต้ตอบคือโค้ด Java ที่ไม่ได้ใช้ https://softwareengineering.stackexchange.com/a/132080/45826ภาษาค่อนข้างคลุมเครืออาจถูกละทิ้งโดยมีสัญญาเล็กน้อยว่าจะดีขึ้น กล่าวถึงที่นี่ครั้งแรกโดย @Vns
อากาศบริสุทธิ์สำหรับแพลตฟอร์ม JVM;)
Scala , Kotlinและอื่น ๆ เป็นภาษาที่ค่อนข้างดีที่ทำงานบน JVM ซึ่งนำคุณสมบัติที่โปรแกรมเมอร์ C # อาจพลาดใน Java โดยเฉพาะอย่างยิ่ง Kotlin รู้สึกเหมือนเป็นทางเลือกที่สมเหตุสมผลสำหรับ C # ในโลกของ JVM Scala อาจเป็นภาษาที่ใหญ่เกินไปสำหรับโปรแกรมเมอร์ที่จะใช้งานได้ในเวลาอันสั้น
นั่นเป็นตัวเลือกอย่างแน่นอนเช่นกัน ทำไมต้องเปลี่ยนเป็น JVM ถ้า Mono สามารถรันได้ตามที่เป็นอยู่ กล่าวถึงครั้งแรกโดย @ferhrosa
นิวยอร์ก - 12 พฤศจิกายน 2557 - เมื่อวันพุธที่ผ่านมา Microsoft Corp. ได้ตอกย้ำความมุ่งมั่นในประสบการณ์ของนักพัฒนาข้ามแพลตฟอร์มโดยการเปิดสแต็ก. NET ฝั่งเซิร์ฟเวอร์แบบเปิดและขยาย. NET เพื่อทำงานบนแพลตฟอร์ม Linux และ Mac OS
ตามข่าวประชาสัมพันธ์นี้ที่อ้างถึง Visual Studio 2015 จะเพิ่ม Linux / Mono เป็นแพลตฟอร์มที่รองรับ
นี่คือบล็อกที่เขียนโดย Mono project คนเกี่ยวกับเรื่องนี้จากอีกด้านหนึ่ง: .NET Source Code Integration (พฤศจิกายน 2014)
Windows / Linux เวอร์ชันหลายแพลตฟอร์มของ (บางส่วน) Net ที่ควบคุมโดย Microsoft 'Nuff กล่าวhttps://github.com/dotnet/core
ตอนนี้จำเป็นต้องทดลองใช้เครื่องมือ / กรอบงานเหล่านี้และดูว่ามีแรงเสียดทานมากน้อยเพียงใด OP ต้องการเขียนเป็น C # สำหรับ JVM ซึ่งอาจใช้งานได้ดีโดยใช้ Grasshopper
การทำเช่นนี้โดยมีเป้าหมายเพื่อรวมไลบรารี C # และ Java world ไว้ใน codebase เดียวอาจไม่ได้ผล
แหล่งที่มา
http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop
การเขียนตัวแปลงจาก IL เป็น bytecode อาจจะง่ายกว่า ด้วยวิธีนี้คุณจะได้รับการสนับสนุนสำหรับภาษา. NET บน JVM โดยอัตโนมัติ
อย่างไรก็ตามนี่เป็นความคิดที่ชัดเจนว่าหากยังไม่ได้ทำอาจเป็นเรื่องยากมากหรือยากที่จะทำได้ดี / มีประโยชน์
ตัวเลือกสำหรับการพัฒนาข้ามแพลตฟอร์มใน C # อาจเป็นแบบโมโน: http://www.mono-project.com/
คุณสามารถใช้คอมไพเลอร์ต้นทางสู่แหล่งที่มาเพื่อแปลภาษา C # เป็นภาษาที่ไม่ใช่การรันบน JVM ตัวอย่างเช่นมีตัวแปลง C # เป็น Java หลายตัวที่อนุญาตให้แอปพลิเคชัน C # ทำงานบน JVM หลังจากแปลเป็น Java
คำตอบนี้อาจจะช้าไปสำหรับคุณ แต่อันนี้เพิ่งมาใหม่ คุณอาจต้องการชำระเงินภาษาโปรแกรมKotlin มันมีน้ำตาลไวยากรณ์ที่ C # มีและใกล้เคียงกับไวยากรณ์ C # มากที่สุดเช่นกันนอกเหนือจากภาษา JVM ที่ไม่ใช่ Java จากJetBrains
ฉันเห็นเหตุผลสองประการว่าทำไมสิ่งนี้จึงไม่ได้รับความกระตือรือร้นมากนัก
สิ่งแรกที่ต้องตระหนักก็คือเมื่อพูดถึงคุณสมบัติที่แท้จริงของภาษา C # และ Java นั้นอยู่ใกล้กันมาก C # amd Java ไม่เพียง แต่ปิดเท่านั้น แต่ยังเคลื่อนที่ไปในทิศทางที่คล้ายกัน มีคุณสมบัติบางอย่างที่ JVM ไม่รองรับในปัจจุบัน แต่นั่นไม่ใช่ปัญหาที่แท้จริง คุณสามารถปลอมสิ่งที่หายไปได้เสมอ ฉันคิดว่าผู้คนชอบรอให้ Java ได้รับน้ำตาลมากกว่าที่จะสร้างเกือบ - Java ตั้งแต่เริ่มต้น เมื่อพอร์ตพร้อม Java อาจตัดสินใจตามทัน
ประการที่สองเหตุผลที่นักพัฒนาชอบ C # ไม่ใช่ภาษาตัวเองมากนัก แต่เป็นเครื่องมือรอบตัวความสัมพันธ์สองทางกับ C # และวิธีที่ Microsoft สนับสนุนสิ่งทั้งหมด ตัวอย่างเช่นคำสั่งผสม C # -XAML เป็นมิตรกว่า JavaFX เนื่องจาก C # และ XAML ถูกแฮ็กสำหรับแต่ละคน (เช่นคลาสบางส่วนใน C # การผูกใน XAML และอื่น ๆ ) การใช้ C # บน JavaFX ไม่ได้ปรับปรุงมากนัก ในการรับประสบการณ์ C # ใน JVM คุณต้องพอร์ตเครื่องมือด้วยและนั่นเป็นโครงการที่ใหญ่กว่ามาก ไม่แม้แต่โมโนจะรำคาญ
ดังนั้นคำแนะนำของนักพัฒนา Java ที่ต้องการใช้ภาษานักเล่น ontop ของเครื่องมือที่คุ้นเคยคือการตรวจสอบที่มีอยู่JVM ภาษา
โมโนก็เป็นอีกทางเลือกหนึ่งเช่นกัน แต่ฉันก็สงสัยมาตลอด แม้ว่าจะเป็น C # -. NET และข้ามแพลตฟอร์ม แต่โดยทั่วไปสิ่งที่สร้างด้วยเครื่องมือของ Microsoft จะไม่ทำงานบน Mono มันคือสิ่งที่เป็นของตัวเองเป็นหลัก เราจะเห็นว่าเกิดอะไรขึ้นในตอนนี้ที่ Microsoft กล่าวว่าพวกเขาจะร่วมมือกัน