stanford-oval/wikipedia huggingface dataset:
傷ついた天使

| --- | --- |

作者: ヒューゴ・シンベリ
製作年: 1903
種類: 油彩
寸法: 127 cm × 154 cm (50 in × 61 in)
所蔵: アテネウム、ヘルシンキ
傷ついた天使(原題:Haavoittunut enkeli 1903年)は、フィンランドの象徴派の画家、ヒューゴ・シンベリの作品。彼の代表作であり、2006年のアテネウム美術館で行われたアンケートではフィンランドの「国家の絵」に選ばれた。
シンベリの他の作品と同様に、この「傷ついた天使」もメランコリックな雰囲気に満ちている。中央の、両目を蔽った天使の姿をした少女の羽からは血が流れている。彼女を、くすんだ色の洋服を着た少年たちが担いでいる。右側の少年の、まっすぐ淡々とした視線はこの絵画を観賞する人間を挑発しているようでもあるが、その目つきからは少女を助けようとしているのか、それとも彼が傷つけたのかははっきりしない。
似つかわしくない大人びた装いの少年たちには、やはり彼らのしていることも似つかわしくないようにみえる。おそらく彼ら自身の運命もまたあやういバランスのうえに成り立っていることを示しているのだろう。彼らの仕事は背景にもそのまま現れている。この風景がどんな気晴らしを与えてくれるのだろうか。
天使の神話とも合致するように、少女の両足が地面に着いていないことは非常に重要である。そしてその天使は裸足だ。それを死の象徴とみる文化はいくつもある。しかしまた、天使がマツユキソウ(snowdrop )のひとふさを握り締めていることを見落としてはならない。それは癒しと再生のシンボルなのだ。
シンベリ自身はあらゆる解釈をあたえることを拒絶し、見る人それぞれが結論を引き出すべきだとしている。だが、かつてシンベリが髄膜炎を患っており、この絵が快復する力の源となったことは有名である。この事実は、「傷ついた天使」にある暗喩的な見方をすることを誘う。髄膜炎とは首もとがひどくこわばる症状として知られている。さらには、無気力やめまいもそうだ。これらは全て、中央の少女の形象にあてはまらないだろうか。また結核性髄膜炎とは上肺野を擦過するものである。彼女の背中にあるものを羽ではなく肺のイメージで読み替えてみるならば、このような「診断」は羽にある小さな傷の説明にもなる。
1905年から06年にかけてタンペレ大聖堂にフレスコ画を描くというオファーをシンベリは受けた。その作品の一つに、より大きなサイズの「傷ついた天使」がある。これはシンベリ自身も気に入っていたという。
フィンランドのカルチャーのなかでは、この絵から派生した作品がよくみられる。有名なものでは、ウニクルビとナイトウィッシュによるミュージックビデオ(2007年)がある。
背景はヘルシンキのエラインタルハで、画面の奥の水辺はトーロン湾である
。
近代文学

近代文学（きんだいぶんがく）
世界文学においては、広義にはシェイクスピアやセルバンテスなどが活躍した1600年頃から第二次世界大戦終結（1945年）までの文学。狭義にはロマン主義の時代（1800年頃）からモダニズムの時代（1920年頃）までの文学。
日本文学においては、明治から昭和戦前期の文学の総称。 ⇒ 日本の近現代文学史
1945年から1964年にかけて刊行されていた文芸雑誌。 ⇒ 近代文学 (雑誌)
サマーカップ

| --- | --- |
: 南アフリカの競馬の競走については「サマーカップ (南アフリカ)」をご覧ください。
| サマーカップ |
| --- | --- |
開催国:   日本
主催者:  岐阜県地方競馬組合
競馬場:  笠松競馬場
第1回施行日:  1978年7月23日
2024年の情報
距離:  ダート1400m
格付け:  SPII
賞金:  1着賞金400万円 
出走条件:  サラブレッド系3歳以上オープン、北陸・東海所属
負担重量:  別定、3歳55kg、4歳以上57kg（牝馬2kg減）
出典:  
テンプレートを表示
サマーカップとは岐阜県地方競馬組合が笠松競馬場のダート1400mで施行する地方競馬の重賞（SPII）競走である。副賞は日本中央競馬会理事長賞、岐阜県馬主会会長賞。正式名称は「スポーツニッポン杯 サマーカップ」、スポーツニッポン新聞社が優勝杯を提供している。
概要

1978年にサラブレッド系4歳（現3歳）以上の東海（愛知・笠松）所属馬限定の重賞競走「サマーカップ」として創設。創設から一貫してダート1400mで施行されている。1996年から東海地区重賞格付け制度施行によりSPIII（スーパープレステージスリー）に格付けされた。
1997年から北陸・東海地区交流競走として施行、金沢所属の競走馬が出走可能となり、2000年から北陸・東海・近畿地区交流競走として施行、兵庫所属の競走馬が出走可能となる。
2001年から1着馬のみ、中央競馬のスプリンターズステークスのトライアル競走の北陸・東海・近畿地区（2006年からは中国地区を含む）のブロック代表馬としてスプリンターズステークストライアル（アイビスサマーダッシュ、セントウルステークス）への出走権が与えられる。更にアイビスサマーダッシュまたはセントウルステークスのどちらかの競走で上位2着までに入賞すると、スプリンターズステークスへ出走可能となる。2006年からは北陸・東海・近畿・中国地区交流となり、福山所属の競走馬が出走可能となる。福山競馬場の廃止により、2013年からは北陸・東海・近畿地区交流競走として施行されていたが、2024年より北陸・東海地区交流競走として施行されることになった。
2019年より格付けがSPIIIからSPIIに格上げされた。
2024年現在、くろゆり賞のトライアルとなっている。
概要 > 条件・賞金（2024年）

東海所属は前年6月20日から本年6月21日の間に出走実績を持つB級以上馬、他地区所属は前年6月20日から本年6月20日の間に出走実績を有する馬。
出走枠は他地区所属4頭以下、東海所属8頭以上（原則笠松4頭以上、名古屋4頭以下）。
歴史

1978年 - 笠松競馬場のダート1400mのサラブレッド系4歳（現3歳）以上の東海所属馬限定の別定重量の重賞競走「サマーカップ」として創設。
1981年 - 愛知の野島三喜雄が調教師として史上初の連覇。
1983年
愛知の黒宮高徳が騎手として史上初の4連覇。
愛知の福田秀己が調教師として史上2人目の連覇。
1986年
笠松のマルゼンスターが史上初の連覇。
笠松の後藤保が調教師として史上3人目の連覇。
1993年 - 笠松のロングニュートリノが当競走で史上2頭目の2度目の優勝。
1996年 - 東海地区重賞格付け制度施行によりSPIIIに格付け
1997年 - この年から北陸・東海地区交流競走として施行され、出走条件を「サラブレッド系4歳（現3歳）以上の北陸・東海所属馬」に変更。
1999年 - 笠松の荒川友司が調教師として史上4人目の連覇。
2000年 - この年から北陸・東海・近畿地区交流競走として施行され、出走条件を「サラブレッド系4歳（現3歳）以上の北陸・東海・近畿所属馬」に変更。
2001年
馬齢表示の国際基準への変更に伴い、出走条件を「サラブレッド系4歳以上の北陸・東海・近畿所属馬」から「サラブレッド系3歳以上の北陸・東海・近畿所属馬」に変更。
1着馬にスプリンターズステークストライアルへの出走権が付与される様になる。
2004年
笠松のブルックリンガイが史上2頭目の連覇かつ当競走で史上3頭目の2度目の優勝。
笠松の濱口楠彦が騎手として史上2人目の連覇。
笠松の柳江仁が調教師として史上5人目の連覇。
2006年 - この年から北陸・東海・近畿・中国地区交流競走として施行され、出走条件を「サラブレッド系3歳以上の北陸・東海・近畿・中国所属馬」に変更。
2009年 - 兵庫のベストタイザンが他地区の地方所属馬として史上初の優勝。
2013年 - 福山競馬場の廃止に伴い、出走条件を「サラブレッド系3歳以上の北陸・東海・近畿所属馬」に変更。
2018年 - 「スポーツニッポン創刊70周年記念杯 サマーカップ」として施行。
2019年 - 格付けをSPIIIからSPIIに昇格。
2020年 - 笠松競馬場の走路改修工事に伴い開催休止。
2021年 - 不祥事の影響による開催自粛で施行なし。
2023年 - 「スポーツニッポン創刊75周年記念杯 サマーカップ」として施行。
2024年 - 出走条件を「サラブレッド系3歳以上の北陸・東海所属馬」に変更。
2025年 - 笠松競馬場の走路改修工事に伴い開催休止。
歴史 > 歴代優勝馬

| 回数 | 施行年月日 | 優勝馬 | 性齢 | 所属 | タイム | 優勝騎手 | 管理調教師 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 第1回 | 1978年7月23日 | ダイタクチカラ | 牡5 | 笠松 | 1:26.8 | 原隆男 | 倉間昭夫 |
| 第2回 | 1979年7月22日 | アドミアサハタ | 牡5 | 笠松 | 1:27.4 | 安藤勝己 | 吉田秋好 |
| 第3回 | 1980年7月20日 | アサヒテルヒカリ | 牝5 | 愛知 | 1:26.8 | 黒宮高徳 | 野島三喜雄 |
| 第4回 | 1981年7月19日 | クインレデイー | 牝6 | 愛知 | 1:26.9 | 黒宮高徳 | 野島三喜雄 |
| 第5回 | 1982年7月25日 | トレビカツオウ | 牡5 | 愛知 | 1:26.9 | 黒宮高徳 | 福田秀己 |
| 第6回 | 1983年7月31日 | サクラハイデン | 牡5 | 愛知 | 1:27.0 | 黒宮高徳 | 福田秀己 |
| 第7回 | 1984年7月29日 | ボールドマツクス | 牡4 | 笠松 | 1:26.4 | 伊藤強一 | 大倉譲 |
| 第8回 | 1985年7月28日 | マルゼンスター | 牡5 | 笠松 | 1:26.0 | 安藤勝己 | 後藤保 |
| 第9回 | 1986年7月27日 | マルゼンスター | 牡6 | 笠松 | 1:27.7 | 川原正一 | 後藤保 |
| 第10回 | 1987年7月29日 | トウカイオー | 騸5 | 笠松 | 1:27.6 | 伊藤浩臣 | 小井土金一 |
| 第11回 | 1988年7月27日 | ワカオライデン | 牡7 | 笠松 | 1:26.2 | 安藤光彰 | 荒川友司 |
| 第12回 | 1989年7月26日 | アエロプラーヌ | 牡4 | 笠松 | 1:26.4 | 安藤勝己 | 吉田秋好 |
| 第13回 | 1990年7月25日 | ハツピーダンデイ | 牡5 | 笠松 | 1:26.5 | 坂口重政 | 飯干秀人 |
| 第14回 | 1991年7月24日 | ロングニュートリノ | 牡6 | 笠松 | 1:26.0 | 松原義夫 | 青木和夫 |
| 第15回 | 1992年7月29日 | ベッスルエース | 牡4 | 笠松 | 1:28.2 | 安藤光彰 | 飯干秀人 |
| 第16回 | 1993年7月25日 | ロングニュートリノ | 牡8 | 笠松 | 1:27.3 | 松原義夫 | 青木和夫 |
| 第17回 | 1994年7月31日 | ミスオペラ | 牝4 | 笠松 | 1:27.7 | 川原正一 | 原隆男 |
| 第18回 | 1995年8月2日 | アメージングレイス | 牡4 | 笠松 | 1:28.2 | 安藤勝己 | 荒川友司 |
| 第19回 | 1996年7月17日 | トモエギャル | 牝6 | 笠松 | 1:26.9 | 安藤光彰 | 柳江俊明 |
| 第20回 | 1997年7月13日 | キタイセタテヤマ | 牡5 | 笠松 | 1:28.8 | 川原正一 | 原隆男 |
| 第21回 | 1998年7月15日 | ランフォータックス | 牡6 | 笠松 | 1:27.7 | 安藤勝己 | 荒川友司 |
| 第22回 | 1999年7月14日 | トミケンシルバー | 牡5 | 笠松 | 1:25.5 | 川原正一 | 荒川友司 |
| 第23回 | 2000年7月12日 | エイシンナポレオン | 牡6 | 笠松 | 1:27.9 | 坂口重政 | 山際孝幸 |
| 第24回 | 2001年6月19日 | シュウタイセイ | 牡4 | 笠松 | 1:27.4 | 安藤勝己 | 後藤保 |
| 第25回 | 2002年5月29日 | イッコーオー | 牡6 | 愛知 | 1:27.5 | 竹下太 | 岩田幸一 |
| 第26回 | 2003年6月27日 | ブルックリンガイ | 牡6 | 笠松 | 1:25.8 | 濱口楠彦 | 柳江仁 |
| 第27回 | 2004年6月25日 | ブルックリンガイ | 牡7 | 笠松 | 1:30.0 | 濱口楠彦 | 柳江仁 |
| 第28回 | 2005年6月22日 | レジェンドハンター | 牡8 | 笠松 | 1:26.5 | 安藤光彰 | 大橋敬永 |
| 第29回 | 2006年6月16日 | マイネフォクシー | 牝5 | 愛知 | 1:26.6 | 丸野勝虎 | 竹地正樹 |
| 第30回 | 2007年6月14日 | マサアンビション | 牡8 | 愛知 | 1:25.7 | 戸部尚実 | 瀬戸口悟 |
| 第31回 | 2008年6月12日 | シールビーバック | 牝6 | 笠松 | 1:27.7 | 濱口楠彦 | 伊藤強一 |
| 第32回 | 2009年6月11日 | ベストタイザン | 牡7 | 兵庫 | 1:26.4 | 下原理 | 齊藤裕 |
| 第33回 | 2010年6月11日 | エーシンアクセラン | 牡6 | 笠松 | 1:25.4 | 花本正三 | 伊藤強一 |
| 第34回 | 2011年7月1日 | エーシンクールディ | 牝5 | 笠松 | 1:24.4 | 岡部誠 | 伊藤強一 |
| 第35回 | 2012年7月27日 | シンボリバッハ | 騸8 | 兵庫 | 1:26.8 | 木村健 | 吉行龍穂 |
| 第36回 | 2013年7月12日 | リプレイスインディ | 騸4 | 笠松 | 1:26.4 | 佐藤友則 | 井上孝彦 |
| 第37回 | 2014年7月3日 | クリスタルボーイ | 牡7 | 愛知 | 1:25.8 | 戸部尚実 | 川西毅 |
| 第38回 | 2015年6月18日 | タガノジンガロ | 牡8 | 兵庫 | 1:24.4 | 木村健 | 新子雅司 |
| 第39回 | 2016年7月13日 | マルトクスパート | 牡6 | 兵庫 | 1:26.6 | 川原正一 | 田中範雄 |
| 第40回 | 2017年7月13日 | トランヴェール | 牡6 | 兵庫 | 1:25.2 | 永島太郎 | 長南和宏 |
| 第41回 | 2018年7月12日 | エイシンバランサー | 牡6 | 兵庫 | 1:25.3 | 下原理 | 新子雅司 |
| 第42回 | 2019年7月18日 | エイシンエンジョイ | 牡4 | 兵庫 | 1:24.9 | 下原理 | 橋本忠明 |
| 第43回 | 2021年 | 開催中止 | 開催中止 | 開催中止 | 開催中止 | 開催中止 | 開催中止 |
| 第44回 | 2022年7月14日 | ファストフラッシュ | 牡7 | 金沢 | 1:28.5 | 青柳正義 | 鈴木正也 |
| 第45回 | 2023年7月6日 | パールプレミア | 牝5 | 兵庫 | 1:26.6 | 笹田知宏 | 新子雅司 |
| 第46回 | 2024年7月4日 | エイシンヌウシペツ | 牝5 | 笠松 | 1:27.1 | 渡邊竜也 | 笹野博司 |
※馬齢は2000年以前についても現表記を用いる。
歴史 > 各回競走結果の出典

サマーカップ 歴代優勝馬（地方競馬全国協会）
決戦は日曜日

| --- | --- |
: 「決戦は金曜日」とは異なります。
| 決戦は日曜日 |
| --- | --- |
監督:  坂下雄一郎
脚本:  坂下雄一郎
製作:  深瀬和美 若林雄介
製作総指揮:  藤本款
出演者:  窪田正孝 宮沢りえ 赤楚衛二 内田慈 小市慢太郎 音尾琢真
音楽:  渡邊崇
撮影:  月永雄太
編集:  上野聡一
制作会社:  パイプライン
製作会社:  「決戦は日曜日」製作委員会
配給:  クロックワークス
公開:   2022年1月7日
上映時間:  105分
製作国:   日本
言語:  日本語
テンプレートを表示
『決戦は日曜日』（けっせんはにちようび）は、2022年1月7日公開の日本映画。監督は坂下雄一郎、主演は窪田正孝。
概要

病に倒れた衆議院議員である父親に代わって立候補した令嬢を当選させようとする私設秘書の奮闘を描く。
窪田と宮沢は本作が初共演となり、脚本の段階で出演を快諾した。窪田は坂下とは仕事を共にしたかった相手とした上で、「監督が描く人の醜さや谷村の視点から見る景色が滑稽すぎて笑いが止まらなかった」とし、宮沢との初共演についても「一緒に芝居をするのが刺激的で、毎日現場に行くのが楽しみだった」といい、「これまでとは違うりえさんが見られると思う」と語っている。
一方の宮沢も出演を承諾した理由として「今までとは全く無縁の役柄だったので演じられるか不安だったが、演じてみたい、この作品に参加してみたいという意欲の方が勝った感じ」とし、窪田との初共演についても「その場の空気を瞬時に汲み取ったりできる安定感や周りへの気遣いに対する気持ちがあって頼もしいなと思った」と語っている。
あらすじ

地元で強い基盤を持つ衆議院議員である川上昌平の私設秘書を務めてきた谷村勉だが、30歳となり秘書として中堅となった昨今、政治への意欲はすっかり薄れてきていた。そんな中で病で倒れた川上に代わり、娘の有美が立候補することになった。世間知らずであり、政界には疎いが熱意だけはあるご令嬢の有美を当選させるべく、谷村は東奔西走するのだが、そんなに生易しい展開になるとは周りの人間は誰も思わなかった。
キャスト

谷村勉：窪田正孝
川島有美：宮沢りえ
岩渕勇気：赤楚衛二
田中菜々：内田慈
濱口祐介：小市慢太郎
向井大地：音尾琢真
川島昌平：小林勝也
後援会会長・渡辺：たかお鷹
後援会幹部：高瀬哲朗
後援会幹部：今村俊一
池田代議士：原康義
石川武
松井工
久松信美
田村健太郎
駒木根隆介
前野朋哉
斎藤志郎
スタッフ

監督・脚本：坂下雄一郎
音楽：渡邊崇
製作総指揮：藤本款
プロデューサー：深瀬和美、若林雄介
撮影：月永雄太
照明：藤井勇
録音：島津未来介
美術：福岡淳太郎
装飾：松葉明子
スタイリスト：西留由起子
ヘアメイク：板垣実和、千葉友子（宮沢りえ担当）
編集：上野聡一
音響効果：勝亦さくら
監督補：塩崎遵
キャスティングディレクター：杉野剛
ポストプロダクションプロデューサー：篠田学
ラインプロデューサー：大熊敏之
制作プロダクション：パイプライン
企画・幹事・配給：クロックワークス
製作：「決戦は日曜日」製作委員会（クロックワークス、BBB、TBSグロウディア、パイプライン、アミューズ、クオラス）
C SharpとJavaの比較

C#とJavaの比較（シーシャープとジャバのひかく）の記事では、プログラミング言語C#とJavaの比較について説明する。
言語 > オブジェクトの扱い

いずれの言語もクラスベースのオブジェクト指向言語であり、その文法はC++に類似しているが、C++との互換性はない。メモリ再利用の手段として、従来の手動で解放する方法ではなくガベージコレクション (GC) を使用する。また、スレッド同期の手段を言語構文に組み込んでいる。
また、いずれの言語もC++のデストラクタに相当する機能を持たないため、ガベージコレクションの管理対象外となるリソース（ファイルやネットワーク接続など）はプログラマが明示的に破棄する処理を記述する必要がある。例外安全に破棄を実行する手段として、try-finallyステートメントのほか、C#ではIDisposableインターフェイスとusingステートメント、JavaではAutoCloseableとtry-with-resourcesが用意されている。両言語にはファイナライザという機能も用意されているが、ファイナライザの動作タイミングは決定論的ではなく、プログラマがリソースを破棄し忘れた場合の最終防壁として用意されている手段であり、一般的に使われることはない。Java 9ではファイナライザが非推奨となっている。
Java、.NETいずれもガベージコレクションの実装形態は細かく規定されていないが、多くの実装でコピーGCとマーク＆スイープGCを併用した世代別ガベージコレクションが使われている。.NET Frameworkは当初から世代別GCだったが、組み込み環境向けの.NET Compact Frameworkは世代別GCではなくマーク＆スイープGCである。
いずれの言語も強い参照と弱い参照の両方をもつ。Javaでは参照がガベージコレクタによって回収された時に通知を受けるリスナーを登録することができる。これはWeakHashMapの性能を考慮したものである。C#にはこれに相当する機能はなく、ファイナライザを使用する方法しかない。その一方、C#は指定したオブジェクトのファイナライザ呼び出しをプログラマが抑止することができる。「世代」の概念をもつガベージコレクションにおいてファイナライザの呼び出しは性能に大きな影響を与えるため、これは非常に有効である。ファイナライザをもつオブジェクトは通常余分な世代が与えられ、回収されるまでに長くかかる。
言語 > 実行形態と安全性

基本的に実行時コンパイラにより中間表現（.NETの場合は共通中間言語、Javaの場合はJavaバイトコード）を機械語に変換しつつ仮想機械上で実行させる形態をとっており、通常のプログラムコードの実行は実行環境（ランタイム）によってすべて管理される。.NETではこれをマネージコード（マネージドコード）と呼び、C#のような言語をマネージ言語と呼ぶが、Javaについても同様にマネージ言語と呼ぶことがある。いずれもC言語やC++と比べて安全性が高く、例えばnullのデリファレンスや配列の範囲外アクセスなどが発生しても未定義動作とはならず、ランタイム例外として安全に処理される。
C#は、一部の言語設計者から危険であると指摘されるポインタを使用した演算が制限つきながら利用できる。C#はポインタを使用するメソッド、型あるいはコードブロックをunsafeキーワードで修飾することでこの懸念に対応している。これにより、このコードを利用する者はそれが他の部分に比べて危険であるということを知ることができる。また、このようなコードをコンパイルする際にはコンパイラに対して/unsafeスイッチを指定する必要がある。一般に、unsafeコードが使われるのはアンマネージなAPIやシステムコールとの相互運用が必要なとき、あるいは性能の向上が必要なときのみである。
言語 > 型システムとデータ型

Javaには大別して参照型（クラス型）とプリミティブ型（基本型）が存在する。参照型はjava.lang.Objectクラスから派生するが、プリミティブ型はスーパークラスを持たない。
一方、C#には大別して参照型、値型、ポインタ型が存在する。このうちポインタ型を除き、あらゆる型はすべてSystem.Objectクラスから派生する。クラス (class) は参照型であり、数値型や論理型を含む構造体 (struct) および列挙型 (enum) は抽象クラスSystem.ValueTypeから暗黙的に派生する値型である。
Javaの組み込み型 (built-in type) はプリミティブ型 (primitive data type) と呼ばれる。C#は組み込み型をJavaよりも多く持ち、すべての組み込み型はSystem名前空間に存在する型へのエイリアスである。組み込み型には以下のようなものがある。
整数型: Javaは符号付き整数のみをサポートし、符号なし整数型が存在しない。C#では符号付き整数と符号なし整数の両方をサポートする。内部表現は2の補数であることが言語仕様で規定されている。
浮動小数点数型: いずれの言語もIEEE 754準拠の32bit単精度浮動小数点数と64bit倍精度浮動小数点数を持つ。
文字型: いずれの言語もUTF-16ベースの文字型charを持つ。整数型と相互に変換でき、その値は'\u0000' (0) から'\uFFFF' (65535) の範囲である。
ブーリアン型: いずれの言語もtrue/falseのいずれかを表すブーリアン型を持ち、Javaではboolean、C#ではboolである。
オブジェクト型: C#では組み込み型としてobject型を持つ。Javaのオブジェクト型java.lang.Objectは組み込み型ではない。
文字列型: C#では組み込み型としてstring型を持つ。Javaの文字列型java.lang.Stringは組み込み型ではない。
C#言語自体にはプリミティブ型という用語は存在しないが、.NET Frameworkの共通言語ランタイム (CLR) では、System.Type.IsPrimitiveプロパティによって、型がCLRプリミティブ型であるかどうかを判定できる。.NET言語組み込みの値型は必ずしもCLRプリミティブ型ではないが、CLRプリミティブ型はすべて値型である。
いずれの言語もプリミティブ型（もしくは値型）と参照型との間で変換するためにボックス化 (boxing) とボックス化解除 (unboxing) が可能である。これによってプリミティブ型（もしくは値型）は参照型のサブセットとみなすことができる。値型は仮想メソッドテーブルを持たず、したがってそのままでは多態性を利用できないが、C#においては、ボックス化によって値型で多態性を利用することが可能である（例えばobject型のToString()メソッドをオーバーライドすることができる）。C#では数値リテラルもオブジェクトであり、たとえば42.ToString()のようにint型のリテラルからメソッドを呼び出すことも可能である。Javaではこのような用途のためにプリミティブ型をラップするクラスが別に定義される。すなわち、42.toString()のようなインスタンスメソッド呼び出しでなくInteger.toString(42)のような静的メソッド呼び出しが必要になる。もう一つの相違点として、Javaではジェネリクスにおいてこのような型を多用するため、暗黙的なボックス化解除が可能になっている（C#ではボックス化せずにジェネリクスを利用できる）。このような変換はnullポインタ例外を発生する可能性があるが、Javaではそれがコード上で明白ではない。
C#では、structキーワードによって構造体を定義することができる。構造体にはフィールドやメソッド、プロパティなどの任意のメンバーを定義できる。引数を持たないコンストラクタ（デフォルトコンストラクタ）をプログラマが定義することはできないが、一つ以上の引数を持つパラメータ化されたコンストラクタを定義することはできる。デフォルトコンストラクタはすべてのメンバーを各々の既定値（通例ゼロ相当の値）で初期化する。C# 10.0以降の構造体は、引数のないコンストラクタをユーザー定義することもできるようになった。また構造体を定義する際、メンバーのメモリレイアウトを属性によって細かく制御することができるため、P/Invokeなどによるネイティブコードとの相互運用にも便利である。なお、構造体は継承元となる基底型を指定することはできず、派生型を定義することもできない。ただし任意のインターフェイスの実装は可能である。Javaには構造体が存在せず、ユーザー定義の値型を作成することはできない。
C#の列挙型は抽象クラスSystem.Enumから暗黙的に派生する値型の一種であり、組み込みの整数型をベースとしている。ベースとなる整数型のどの値も列挙型の値として有効になる（明示的なキャストは必要であるが）。このため、ビットフラグにおいてビットごとのOR演算で列挙型の値を組み合わせることが可能である。ただし構造体と違って任意のインターフェイスを実装することはできない。一方、Javaの列挙型は抽象クラスjava.lang.Enumから暗黙的に派生する参照型である。Javaの列挙型として有効な値は定義においてリストされたものだけである。列挙型の値を組み合わせるためには列挙セットクラスを使用する必要がある。Javaの列挙型では、値によって異なるメソッドの実装が可能である。JavaとC#はいずれも列挙型を文字列に変換することができるが、Javaにおいてはこの変換をカスタマイズすることができる。また、Javaの列挙型は任意のインターフェイスを実装することができる。
プリミティブ型（あるいは値型）は参照型（クラス）とは異なり、インスタンスはヒープ領域ではなくスタックに置かれる。また、（フィールドとして、あるいはボックス化された状態で）クラスの一部になることも、配列の要素になることも可能である。クラスのインスタンスはメモリ上で間接的に参照される必要があるが、プリミティブ型（あるいは値型）はその必要がない。プログラマの視点からは、C#の値型は軽量なクラスとみなせる。しかし、プリミティブ型（あるいは値型）には前述のように多数の制限がある。値型は通常nullの値をとることができないが、.NET Framework 2.0でnull許容型 (System.Nullable) が導入され、C#でも擬似的にnull値を取り得る値型が利用可能となった。
型そのものをコード上で表現するメタデータ型（メタクラス）として、Javaではjava.lang.Classを、C#ではSystem.Typeを利用する。これらはいずれもリフレクションやイントロスペクションで重要な役割を果たす。
言語 > 配列

C#およびJavaの配列は参照型であり、第一級オブジェクトである。C#の配列は共通の基本クラスSystem.Arrayから派生するが、Javaの配列はjava.lang.Objectから派生する。代わりに、配列のユーティリティクラスとしてjava.util.Arraysが用意されている。
いずれの言語も配列は共変性 (covariance) を持つ。
System.Console.WriteLine(typeof(int[]).BaseType); // System.Array
object[] objs = new string[3]; // 代入可能。
objs[0] = "test";
objs[0] = 10; // System.ArrayTypeMismatchException
System.out.println(int[].class.getSuperclass()); // java.lang.Object
Object[] objs = new String[3]; // 代入可能。
objs[0] = "test";
objs[0] = 10; // java.lang.ArrayStoreException
なお、Java 1.5で拡張for文がサポートされた。これはC#のforeach文に相当する。配列を始めとするコレクション型を、イテレータにより走査することができる。
C#は真の多次元配列（矩形配列）をサポートするが、Javaはサポートしない。C#およびJavaはともに「配列の配列」をサポートする（C#ではジャグ配列と呼ばれる）。
→詳細は「配列」を参照
言語 > 内部クラス

いずれの言語もネストされた型（入れ子にされた型：クラスや構造体のブロックの中で定義されたクラス・構造体・列挙型・インターフェイス）をサポートする。Javaではインターフェイス内部にクラスや列挙型を定義することもできる。C# 7.xまではインターフェイス内部にクラス・構造体・列挙型・インターフェイスを定義することはできなかったが、C# 8.0以降は定義できるようになった。
Javaでは、ネストされたクラス (nested class) は既定で内部クラス (inner class) となる。内部クラスは外側のクラスのインスタンスを暗黙的にキャプチャすることで、静的メンバ、非静的メンバいずれにもアクセスすることができる。ネストされたクラスがstatic修飾されていた場合は静的メンバのみにアクセスできる。メソッドの内部にクラスを定義することもでき、これはローカルクラス (local class) と呼ばれる。ローカルクラスでは、外側のローカル変数には読み取りアクセスのみできる。また、型の名前を持たないローカルクラス（匿名クラス: anonymous class）を定義し、同時にインスタンス生成をすることもできる。
C#では、ネストされたクラス／構造体から外側のクラス／構造体の非静的メンバにアクセスするためには外側のクラス／構造体のインスタンスへの明示的な参照が必要になる。Javaの内部クラスやローカルクラスに相当する機能は存在しない。代わりに、C# 2.0以降では匿名メソッド (anonymous method) が、C# 3.0以降ではラムダ式が、そしてC# 7.0以降ではローカル関数がサポートされ、外側の変数をキャプチャするクロージャとして利用できる。なお、C# 3.0では限定的なローカルクラスとして、匿名型（読み取り専用プロパティのみを持つ、匿名のクラス型）がサポートされる。
言語 > ジェネリクス

Javaではジェネリクスは型消去 (type erasure) によって実装されている。これによってジェネリック型についての情報は実行時には失われ、リフレクションを通してのみ取得できるようになる。.NET 2.0では、ジェネリック型についての情報は完全に保存される。Javaはプリミティブ型に対するジェネリック型は定義できないが、C#では参照型・値型（プリミティブ型を含む）いずれに対してもジェネリック型を定義できる。Javaはその代わりにボックス化した型を使用することができる（List<int>の代わりにList<Integer>など）が、全ての値をヒープに確保し直す必要があるため、パフォーマンスコストが高い。JavaとC#はいずれも、参照型に特殊化されたジェネリック型は、型によらず共通のコードが実行される。しかし、C#において値型に特殊化された場合、CLRは型に最適化されたコードを動的に生成する。.NETにおいては、ジェネリック型に対する型安全性はコンパイル時にチェックされ、CLRにロードされる時に強制される。Javaにおいてはコンパイル時に部分的にチェックされるのみであり、Java VMは実行時にジェネリック型に関する情報を持たないため、キャスト操作を行う必要がある。
言語 > ジェネリクス > ジェネリクスの型制約

C#、Javaともに、ジェネリクスの型制約を持つ。
C#では基底型指定以外に、class（参照型）、class?（null許容またはnull非許容の参照型）、struct（値型）、new()（デフォルトコンストラクタあり）、notnull（null非許容型）、unmanaged（アンマネージド型）の各制約を指定できる。
// C#
class ConstraintClass { }
class SomeGenericClass<T> where T : ConstraintClass { }
class OtherGenericClass<T> where T : new() { }
class OtherGenericClass<T> where T : notnull { }
class OtherGenericClass<T> where T : unmanaged { }
// Java
class ConstraintClass { }
class SomeGenericClass<T extends ConstraintClass> { }
言語 > ジェネリクス > ジェネリクスの共変性と反変性

C#、Javaともに、ジェネリクスの共変性と反変性 (covariance and contravariance) を持つ。ただしC#における共変性・反変性のサポートはバージョン4.0以降である。
C#では、型定義側で共変性outあるいは反変性inを指定し、利用側では変性の指定を行わない。なお、C#の値型は不変 (invariant) であり、共変性・反変性は適用されない。
// C#
// System.Func<T, TResult> と同様のデリゲートを定義。
// 型定義側で変性の指定を行う。
public delegate TOut MyFunc<in TIn, out TOut>(TIn arg);

public class GenericsTest {
    public static void Main() {
        // 利用側では変性の指定を行わない。
        MyFunc<object, string> func1 = x => "<" + x + ">";
        MyFunc<string, object> func2 = func1;
        object ret = func2("test");
        System.Console.WriteLine(ret);
        System.Console.WriteLine(ret.GetType()); // System.String
    }
}
Javaでは、型定義側では変性の指定を行わず、利用側で共変性extendsあるいは反変性superを指定する。
Javaではさらに、上限と下限のいずれも指定しないワイルドカード?による型引数の指定が可能である。以下にJava 8の例を示す。
// Java
// java.util.function.Function<T, R> と同様のインターフェイスを定義。
// 型定義側では変性の指定を行わない。
@FunctionalInterface
interface MyFunc<TIn, TOut> {
    TOut apply(TIn arg);
}

public class GenericsTest {
    public static void main(String[] args) {
        // 利用側で変性の指定を行う。
        MyFunc<? super Object, ? extends String> func1 = x -> "<" + x + ">";
        MyFunc<? super String, ? extends Object> func2 = func1;
        Object ret = func2.apply("test");
        System.out.println(ret);
        System.out.println(ret.getClass().getName()); // java.lang.String

        // 変性の上下限いずれも指定しないこともできる。
        java.util.List<?> list;
    }
}
言語 > 型推論

C# 3.0でコンテキストキーワードvarによる限定された型推論が導入された。ローカル変数の宣言時に、型を右辺から推論できる。メソッド引数やフィールドには使えない。また、ラムダ式の戻り値および仮引数は型推論により決定される。ラムダ式の仮引数は型を省略することで型推論されるが、型推論が困難な場合には明示的に型を指定する。
Java 7で導入されたダイヤモンド演算子<>は宣言文の右辺ジェネリクスの型を省略できる程度のものでしかなかったが、Java 10ではC#同様に予約型名varによるローカル変数の型推論が導入された。Java 8で導入されたラムダ式では、仮引数の型を省略することで型推論されるが、さらにJava 11ではラムダ式の仮引数の型にvarを使用して型推論できるようになった。
言語 > 表記法と特殊な仕様

Java 1.5で、あるクラスの静的メソッド・静的フィールドを短い名前で使用するためにstatic import構文が導入された。これにより、例えばClassAクラスのfoo()メソッドを静的インポートして、無関係のClassBクラスにてClassA.foo()のように型名で修飾することなく、foo()を直接使用できる。C# 6.0でも同様の機能としてstatic usingディレクティブがサポートされた。
C#は静的クラス（Javaの静的内部クラスとは異なる）の構文をもち、これによってクラスは静的メソッドのみを持つことができるようになる。C# 3.0から、型に静的にメソッドを追加するための拡張メソッドが導入されている（Foo型のインスタンスfooについての処理を行うBar()拡張メソッドを定義することで、あたかもFooにインスタンスメソッドが追加されたかのように、foo.Bar()と記述できる）。この機能は、クラスの外部で定義した静的メソッドを、そのクラスのインスタンスメソッドであるかのように見せかけて呼び出せるようにする糖衣構文であり、またターゲットとなるクラスのプライベートメンバにアクセスすることはできないため、カプセル化は維持される。
言語 > 表記法と特殊な仕様 > イベント処理

Javaでは、Observer パターンの記述を容易にするために匿名クラスという糖衣構文が用意されている。匿名クラス構文により、クラス本体の定義とインスタンスの生成を同時に行なうことができ、また定義と生成がひとつの式として扱えるため、インターフェイス実装クラスのインスタンスを一度限りしか生成しない場面、例えば特定のインターフェイス実装（あるいは特定のスーパークラスのメソッドのオーバーライド）を要求するイベントハンドラーの設定時などによく用いられる。Java 8ではラムダ式がサポートされ、匿名クラスの代わりに使うこともできる。Java 7まではC#のデリゲートに相当するものは存在しなかったが、Java 8では類似機能としてメソッド参照がサポートされるようになった。
C#ではデリゲート (delegate) 型をはじめ、イベント処理をサポートするための機能が広範囲に渡って言語レベルでサポートされている。デリゲート型はメソッドへの型安全な参照であり、複数のデリゲートを結合してマルチキャスティングすることもできる。デリゲートを結合／分離するための+, -演算子、イベントハンドラーをカプセル化するためのイベント構文 (event, add/remove) や、イベントハンドラーを登録／削除するための+=, -=演算子が用意されている。デリゲートは共変性と反変性 (covariance and contravariance) をサポートし、完全なクロージャとしての性質をもつ匿名関数（匿名メソッドおよびラムダ式）を作成することができる。
言語 > 表記法と特殊な仕様 > 非同期処理

JavaおよびC#はともに標準ライブラリでスレッドをサポートしている。OSのスレッド（カーネルレベルのスレッド）に対する薄い抽象化を提供するクラスとして、Javaにはjava.lang.Thread、C# (.NET) にはSystem.Threading.Threadが用意されている。そのほか、セマフォなどの同期オブジェクトやアトミック演算なども標準ライブラリでサポートされている。
言語組み込みの同期構文として、Javaにはsynchronizedブロックおよびsynchronizedメソッドが用意されている。C#にはlockステートメントが用意されている。
C# 5.0以降はasync/awaitコンテキストキーワードによる非同期メソッド構文がサポートされた。このasync/await構文はFuture パターンをさらに発展させたもので、イテレータおよび.NET 4以降で追加されたタスク並列ライブラリ (Task Parallel Library; TPL) を実行基盤とする糖衣構文であり、非同期タスクの完了待機と実行結果の取得、そして後続処理（継続）をあたかも同期メソッドのように記述することができる。このasync/await構文はMicrosoft Visual Studio 2012と同時期にリリースされたVisual Basic .NET 11にも搭載された。その後、さまざまな言語で同様の構文がサポートされるようになった。
Java 1.5以降はjava.util.concurrent.FutureによるライブラリベースのFutureパターンをサポートするものの、async/await構文はサポートされていない。
言語 > 数値処理

数学・科学計算・金融分野のアプリケーション開発に十分対応するための言語仕様が、それぞれに存在する。
Java SE 1.2からJava SE 16までは、IEEE 754に準拠した厳密な浮動小数点計算を強制するためのstrictfpキーワードが存在した。これによってあらゆるプラットフォームで必ず同じ値が結果として得られることを保証することができた。1990年代後半の当時、この機能が必要とされた背景は、もともとIntelのx86アーキテクチャにおけるx87浮動小数点命令セットの残念な特性に起因していたが、x64アーキテクチャではスカラー浮動小数点演算にもSSE/SSE2命令を使用するようになったため、厳密な浮動小数点セマンティクスを余分なオーバーヘッドなしに自然にサポートできるようになった。Java SE 17以降は一貫して厳密な浮動小数点セマンティクスが必須となり、意味を失ったstrictfpの機能は廃止された。詳細はstrictfp（英語版）の記事も参照のこと。C#にはこれに相当する機能はない。
単精度浮動小数点数floatや倍精度浮動小数点数doubleといった二進表現の浮動小数点数は、多くの環境でCPU命令によるハードウェアサポートがあるため高速な処理に適しているが、「0.1」のような十進数の値を正確に表現することができないため、丸め誤差が生じてしまう。金融分野のアプリケーションソフトウェアでは、厳密な十進表現のサポートは必須である。C#には、十進数の厳密な浮動小数点計算に適した128ビットの組み込み型decimalが存在する。この型はSystem.Decimal構造体のエイリアスであり、速度性能および表現可能な値の範囲はfloatやdoubleに劣るものの、有効桁数が28桁と大きく、有効桁数の範囲内であれば十進数データの誤差が存在しないため、二進浮動小数点表現に存在する問題の多くが解決される。Javaでは、このような用途のためにjava.math.BigDecimalが導入されている。また、Java 1.1では巨大な整数を扱うためのクラス型としてjava.math.BigIntegerが導入されている。BigDecimalとBigIntegerは最大で約21億桁程度までの数を任意精度で表現できる。C#においては、.NET Framework 4よりSystem.Numerics.BigInteger型が導入されている。
Javaでは、BigDecimalや複素数型といったライブラリ定義の型をプリミティブ型と同じレベルで使用することは不可能である。また、Javaではユーザー定義型はすべて参照型扱いとなり、メモリブロックの実体はヒープに確保される。一方、C#は次のような機能をサポートする。
演算子多重定義やインデクサ。
暗黙的または明示的な型変換。C++のキャスト演算子オーバーロードに似た、ユーザー定義の型変換を定義できる。これにより、例えばプリミティブ数値型同士の変換と類似の機能を提供できる。
値型と値型に対するジェネリック型。値型はスタックに確保される。これは実行時の性能面に影響を及ぼす。
これらに加え、C#では数値処理アプリケーションのために、コード中の特定領域において整数型の算術演算および変換に対する算術オーバーフローの実行時チェックの有効・無効を制御するchecked/uncheckedキーワードを使用できる。
言語 > 数値処理 > 演算子多重定義

Javaは言語仕様をシンプルに保つため、また乱用による難読化を防ぐため、ユーザー定義の演算子オーバーロードをサポートしていない。一方でコードの書きやすさおよび直感性は犠牲になっている。
var myList = new java.util.ArrayList<Integer>(java.util.Collections.nCopies(10, 0));
myList.set(4, -100);
var gravityTable = new java.util.HashMap<String, Double>();
gravityTable.put("Mercury", 0.377);
gravityTable.put("Venus", 0.9);
gravityTable.put("Earth", 1.0);
double gravityOnVenus = gravityTable.get("Venus");
var b1 = new java.math.BigInteger(Long.toString(Long.MAX_VALUE));
var b2 = new java.math.BigInteger(Integer.toString(1));
var b3 = b1.add(b2);
C#は表記法の多くの点でJavaよりも多機能である。演算子多重定義やユーザー定義キャストなど、それらの多くはC++プログラマによって既に親しまれているものである。
C#はインデクサ（C++のoperator[]に相当）をサポートする。インデクサの定義構文はプロパティと似ているが、this[]という名前をもち、一つ以上の引数（インデックス）を持つ点が異なる。インデクサを定義する際、インデックスには任意の型を使用することができる。
var myList = new System.Collections.Generic.List<int>(new int[10]);
myList[4] = -100;
var gravityTable = new System.Collections.Generic.Dictionary<string, double>();
gravityTable["Mercury"] = 0.377;
gravityTable["Venus"] = 0.9;
gravityTable["Earth"] = 1.0;
double gravityOnVenus = gravityTable["Venus"];
C#は（論理的一貫性を保つための制限はあるものの）ユーザー定義の演算子オーバーロードをサポートしており、注意深く使用すれば簡潔で可読性の高いコードを記述することができる。
var b1 = new System.Numerics.BigInteger(long.MaxValue);
var b2 = new System.Numerics.BigInteger(1);
var b3 = b1 + b2;
また、C#では明示的メンバ実装 (Explicit Member Implementation) が可能である。これによって、インターフェイスメソッドの実装とクラス自身のメソッドの実装とを分離することができ、また同じシグネチャ（名前および引数の数と型の順序）を持つメソッドが異なるインターフェイスにそれぞれ存在した場合に、インターフェイス名を指定して区別することでそれらの実装を別々に行うことができる。
言語 > メソッド

C#のメソッドはデフォルトで非仮想（非virtual）であり、仮想メソッドにする必要がある場合は明示的にvirtualと宣言しなければならない。Javaのメソッドは常に仮想 (C#でvirtual指定された状態) であり、非仮想にすることはできないが、final修飾子を指定することでオーバーライドを禁止することはできる。
Javaでは、メソッドを非仮想的にする方法はない。これは、派生クラスが同名の無関係なメソッドを再定義することが不可能であることを意味する。これは基底クラスが別のプログラマによって書かれており、バージョン更新の際に、派生クラスに既に存在していたものと同じシグネチャのメソッドが追加されてしまった場合に問題になる。Javaでは、この場合どちらのプログラマの意図とも異なり、派生クラスのメソッドは暗黙的に基底クラスのオーバーライドになってしまう（基底クラスでfinal宣言されていた場合はコンパイルエラーになってしまう）。
これらのバージョン更新の問題を部分的に解決するため、Java SE 5.0では@Overrideアノテーションが導入された。これにより、基底クラスが同一シグネチャのメソッドを持ち、それが派生クラスで正しくオーバーライドされていることを保証することはできる。しかし後方互換性維持のため、この指定は必須ではない。従ってIDEやツールなしに上記のように思いがけずオーバーライドしてしまうような問題を防ぐことはできない。
C#では、派生クラスで仮想メソッドをオーバーライドする際には、明示的にその旨を宣言する必要がある。メソッドが基底クラスのオーバーライドである場合、override修飾子が指定されていなければならない。また、オーバーライドではなく同名の無関係なメソッドを派生クラスで再定義することができるが、コンパイラが警告を発する。コンパイラ警告を抑制したい場合、new修飾子を指定しなければならない。
| メソッド種別 | C# | Java |
| --- | --- | --- |
| 非仮想 | (指定なし) | N/A |
| 仮想 | virtual | (指定なし) |
抽象: abstract
| オーバーライド | override | @Override |
| 継承先でのオーバーライド禁止 | (指定なし：非仮想) | final |
| オーバーライド かつ 継承先でのオーバーライド禁止 | sealed override | @Override final |
| 隠蔽 | new | N/A |
→「オーバーライド」も参照
言語 > プリプロセッサ

JavaはC/C++でしばしば問題を引き起こしていたプリプロセッサを採用しなかった。一方でC#は限定的にプリプロセッサディレクティブを使用可能である。
言語 > プリプロセッサ > 条件付きコンパイル

Javaではプリプロセッサがサポートされないため、コンパイル時の分岐は不可能となっている。
一方、C#ではプリプロセッサディレクティブを用いた条件付きコンパイル (条件コンパイル、英: conditional compilation) が実装されている。また、指定されたコンパイル定数が定義されている時のみ呼び出されるようConditional属性 (System.Diagnostics.ConditionalAttribute) をメソッドに指定することができる。この方法によって、DEBUG定数が定義されている時のみ評価される表明（アサート）機能 (System.Diagnostics.Debug.Assert()メソッド) が提供されている。
Java 1.4からは実行時に有効・無効を切り替えられるassert文が言語仕様として導入されている。