J Sharp

J#に対応した統合開発環境としてはVisual Studioやスタンドアロン型のVisual J# Express Editionがある。J#のソースファイルの拡張子には ".jsl" を用いる。

J#はJavaとは違い、Windows環境でのみ動作するバイナリコードのアプレットやアプリケーションのみを作成できる。つまり、拡張子が.exeの実行ファイルやコンソールアプリケーション、そして拡張子が.dllのクラスファイルである。

JavaとJ#とで全般的な文法はほぼ同じであるが、.NET環境をサポートするためにJavaの規格には適合していない。たとえば、.NETプロパティを普段のJavaBeanのクラスで使うためには、getXxxメソッドやsetXxxメソッドのようなget/setのプレフィックスを備える必要があり，メソッドに対してJavadocのような注釈を添える。

	/** @beanproperty	 */

もしget/setで始まるプライベート変数を有するなら，get/setで始まらない別の名称に変更しなければならない。 J#はJavaのソースコードから.classファイルのようなJavaバイトコードにコンパイルしないし、Javaアプレット開発環境やWebブラウザ上でアプレットを実行する機能もない。しかしながら、ActiveXオブジェクトとしてホストするためのラッパー(Microsoft J# Browser Controls)は提供されている。 最後に、Java Native Interface (JNI) とRaw Native Interface (RNI) については、P/Invoke（プラットフォーム呼び出し）で代用する。J#はJava RMIをサポートしない。

言い換えると、Javaが中間コードをJava仮想マシン上で動作させるのと同じように、J#は共通中間言語にいったんコンパイルされた中間コードを.NET Framework上で実行する。

J#は、C#やVB.NETに負けないプログラミング言語であるとは一般的に考えられていない。そしてほか言語になされるのと同じくらいのサポート、サンプルの提供、またはアップデートもなされていない。この事実にもかかわらず、J#は.NETで利用可能な言語であり、共通言語ランタイムが備える機能をほとんど利用できる。

2007年にマイクロソフトのJ#開発チームは、J#の将来について2つの重要なアナウンスをおこなった^[2]。

• マイクロソフトは64ビットランタイムをサポートして欲しいという顧客の要求に応えるため、Visual J#のアップデートバージョンを提供する。それはJ#2.0 Second Editionと呼ばれる64ビット環境の再頒布できるバージョンを含むはずである^[3][4]。
• J#とJava Language Conversion Assistantを、Visual Studioの将来のバージョンに含めないこと。それは現在のJ#の特徴が顧客の要求へあわなくなり、J#の利用が衰えたためである。Visual Studio 2005として出荷されている現在のバージョンは、ソフトウェアリリースライフサイクルによって2015年までサポートされる^[5]。