stanford-oval/wikipedia huggingface dataset:
Phabricator

| --- | --- |
: ウィキペディアにおけるバグ報告相談については、「Wikipedia:バグの報告」をご覧ください。
| --- | --- |
 
 
作者:  エヴァン・プリエストリー
開発元:  Phacility, Inc
初版:  2010年 (15年前) (2010)
リポジトリ:  github.com/phacility/phabricator  
プログラミング 言語:  PHP
対応OS:  クロスプラットフォーム
対応言語:  英語
種別:  コードレビュー
ライセンス:  Apache v2
公式サイト:  phabricator.org
テンプレートを表示
Phabricator（ファブリケーター）とはウェブ型ソフトウェア開発協同作業ツールのスイートでDifferentialというコードレビューソフトウェア（英語版）、Diffusionというリポジトリブラウザ、Heraldという変更監視ツール、Maniphestというバグトラッカー、Phrictionというウィキが含まれる。現在、Phacilityが携わっており、当初はFacebookの内部ツールとして開発された。Apache Licenseバージョン2の下、FLOSSとして配布されている。
また、Git、Mercurial、Subversionと統合されている。
主要開発者はFacebook社員だったエヴァン・プリエストリーでPhabricatorの開発に専念するために退社し、Phacilityという新たな企業を立ち上げた。
顧客

以下、Phabricatorの顧客の一部である。
Blender
Bloomberg
DeviantART
Dropbox
Enlightenmentウインドウマネージャ
Facebook
FreeBSD
カーンアカデミー
LLVM
MemSQL（英語版）
Miraheze
Pinterest
Haskell
Quora
ウィキメディア財団
マイクロドライプリンタ

マイクロドライプリンタは、アルプス電気が独自開発し、自社ブランドで発売した個人用プリンター。
当初「Micro Dry Process（マイクロドライプロセス）方式プリンタ」と称したが、現在では「Micro Dryプリンタ」（マイクロドライプリンタ）と称して発売されていた。
「マイクロドライ」はアルプス電気が「電子応用機械器具及びその部品」「紙類，文房具，印字用インクリボン（交換用インクリボンを含む），アイロンの熱を利用してなる転写用シート」で商標登録している（それぞれ日本第4176758号、日本第4224141号）が、別分野でクラレ（日本第4212116号他1件）が商標登録している。
最新機種のMD-5500
2010年5月末日で販売終了であることがアナウンスされ、販売終了した。
概要・特色

最大の特徴は熱ヘッドである。マイクロDOSヘッドと呼ばれる、1ドットあたり直径約40マイクロメートルの円形シリコン単結晶熱ヘッドを用いたもので、インクジェットプリンターと比べて解像度で大きく劣るといわれていた、それまでの熱転写プリンターの欠点を大きく改善したものである。
またこの方式は、顔料系のドライインク（ワープロで用いられるのとほぼ同じインクリボンカセットを使用）を用いるため、インクジェットプリンターの欠点であるインクにじみが原理的に発生せず、耐水性や耐光性にも優れ、また印刷用紙を選ばず（ただ、腰のない薄い用紙や引っ張り強度の弱い紙を用いるとトラブルを生じることあり）、メタリックインクや白色インクといった特色印刷や、昇華型熱溶融印刷（一部機種）が可能という特長がある。またインクジェット方式のようなノズル詰まりが原理的に生じないことや、印刷中にインクが切れた際、インクカセットを交換し、印刷を続行できることも特長である。
特に特色印刷の機能を有する点は、その独特の発色と相まって、オフセット印刷に近い品質が得られるとして、商業印刷のカラー・カンプ作成用に重用される理由にもなっている。アルプス電気自身も、ホームページ上で「ALPSマイクロドライプリンタは、プロのデザイナーによって支えられてきました。それは、色再現性が評価されたためです。」と述べている。MD-5500商品概要
またインクの特質を生かし、マイクロドライプリンタを用いて模型用のデカールやインスタントレタリングを作成する事が可能であると知られている。
欠点としては、カラー印刷時は用紙を往復させて一色ずつインクを乗せてゆく方式であるため、カラー印刷で印字速度が遅いこと、また色ずれや、用紙の質によっては用紙を往復させる過程でトラブルを生じる場合があること、インクリボンに跡が残るためセキュリティ上の問題があること、写真印刷などではプリントにリボン跡が出ること、インクジェットプリンターと比べてランニングコストが高いことが挙げられる。
経歴と現状

最初の製品であるMD-2000は1995年6月に発売されたが、これはカラー印刷600×600dpi、モノクロ印刷600×1200dpiという解像度を持ち、10万円を切る価格設定とともに驚きをもって迎えられた。
モノクロ印刷の解像度は縦方向のスムージング処理によって得られたものだが、公称性能として1000dpi以上の解像度を得たのは、パーソナルプリンターとしてはMD-2000が世界初であったといわれている。当初からアイロンプリントの機能を有しており、アイロンプリント用のキットが存在したほか、アイロンプリント用インクでOHP用フィルムに印刷することもできた（ドライバの改良で、現在は紙用インクで可能）。また熱転写方式という構造を生かし、プリントゴッコのマスター製版を刷ることもでき、ドライバで色分解してフルカラー製版を行える機能もあった。またこうした機能に対応し、シートフィーダー部を水平に倒し、原稿を手差しとすることも可能であった。またアルプス電気独自の規格である「Labeca FREE（ラベカフリー）」対応のシートを用いたラベル印刷も、アルプス電気オリジナルのユーティリティソフト「PRINT STUDIO」によって可能であった（Labeca FREEシートはすでに販売を終了しているが、製造・販売はコクヨとエーワン株式会社が行っていた）。
外装のインダストリアルデザインは米国IDEO社によるもので、後の製品もIDEO社が担当した。MD-2000、2010、2300、4000では扇形を基調とした特徴的なデザインであったが、MD-1000からはキュービックなデザインに変更され、現在に至っている。MD-5000シリーズではiMacカラーをあしらったものもあった。
その後、オプションにより昇華型熱溶融印刷も可能になったほか、カラー印刷でのスムージングや横方向のスムージングができるように改良され、またインクジェットプリンターのようなバリアブル・ドット技術が開発されVDフォトプリンタに発展（現在は在来方式の製品がなくなったためか、単に「VDプリンティング」と称している）、解像度も2400dpi相当に引き上げられた。
カラー印刷はCMYKの四色グラビア印刷が基本で、同時セットできるカセットも4本であったが、VDフォトプリンタでは7本を同時セットできるようになっている。またこれまでどおり、用途に応じて使用するインクの組み合わせを変えることができる。またVDフォトプリンタではメタリック印刷が発展し、「金箔押し」の印刷も可能になっている。
過去には「スキャプリ」と称したイメージスキャナ内蔵の複合機も存在した。フラットベッド型ではなく、FAXなどのように原稿を送り込むドラムスキャナー方式で、MD-4000などがこれにあたる。「スキャプリ」はアルプス電気の登録商標（日本第4224302号・第4868718号）である。
またMD-2000、2010、2300、4000ではDOS/V用の「J」型、Macintosh用の「S」型があり、J型はパラレル（IEEE 1284）接続のESC/P・RGLプリンター、S型はSCSI接続のRGLプリンターであった（後に登場した「Micro Dry RIP」というソフトウェアインタープリタによりAdobe PostScriptに対応）。MD-1000、1300、1500、MD-5000シリーズではJ型を基本とし、Macintoshではアダプターを介してSCSI接続する方法に改められ（MD-1000、1300、1500ではアダプター付属のものをD型と称し、これもMicro Dry RIPによりMacintosh環境でのみPostScriptに対応）、1999年10月発売のMD-5500では、やはりそれまでアダプターを介して行われていたUSB接続が標準となった。
店頭販売からは2000年12月に撤退、ネット直販でMD-5500が販売されていたが、2010年5月末で販売を終了している。修理対応は2015年5月31日、サプライ品の販売は2016年5月31日をもって終了した。このほか、株式会社きもとの製品にマイクロドライプリンタの技術が供与されている（2004年までは沖データ製品MICROLINE 7050cにも、同様に技術供与された）。
またマイクロドライプリンタで開発された技術は、アルプス電気が電子部品のひとつとして製造・供給しているプリンター装置に生かされ、ワープロのプリンター（PhotoPrint技術）や、キヤノンなど他社で発売しているデジタルカメラ写真印刷用の昇華型熱転写プリンター（フォトプリンター）の心臓部に用いられている。
プリンタドライバは、Windows 7では32ビット版のみの対応となっている。
薩摩蒸気屋

| --- | --- |
種類:  有限会社(特例有限会社)
本社所在地:   日本 〒890-0053 鹿児島県鹿児島市中央町11－2
設立:  1988年（昭和63年）6月16日
業種:  食料品
法人番号:  4340002004408 
事業内容:  かすたどん・かるかんなどの和菓子を中心とした製造・販売
代表者:  山口学(代表取締役)
外部リンク:  http://www.jokiya.co.jp/
テンプレートを表示
店舗例（天文館店）
かすたどん
有限会社薩摩蒸氣屋（さつまじょうきや）は、鹿児島県鹿児島市に本社を置く、かすたどん・かるかんなどの和菓子を中心とした製造販売業者である。
宮崎県、福岡県に販売店舗を持つほか、子会社として株式会社元祖鶏卵素麺松屋などを持つ（後述）。
店舗

鹿児島県
鹿児島市 - かるかん本舗天文館店、菓々子横丁、かるかん本舗中央駅前店（季節限定で若鮎の製造取扱あり）、JR鹿児島中央駅店、ケーキ園トレーンベル、鴨池店、谷山店
薩摩川内市 - 薩摩川内店、川内駅店
いちき串木野市 - 串木野店
姶良市 - 姶良店
霧島市 - 国分店、隼人店、霧島民芸村店
宮崎県
都城市 - 都城東町店、都城川東店、都城鷹尾店
宮崎市 - 宮崎駅東口店、宮崎神宮東店、宮崎大坪店
福岡県
福岡市 - 博多蒸氣屋中洲店
工場・空港・デパート売店
工場売店 - 鹿児島県鹿児島市小山田町
鹿児島空港2F　ロイヤル売店内 - 鹿児島県霧島市
福岡空港第2ターミナルビル2F　ANAフェスタ売店内 - 福岡県福岡市博多区(※取扱商品はかすたどん・かるかんのみ。)
博多阪急地下1F(JR博多駅、JR博多シティ内) - 福岡県福岡市博多区(※取扱商品はかすたどん・かるかんのみであるが、博多焼どうなつも販売している。)
福岡三越地下2F　博多蒸氣屋 - 福岡県福岡市中央区
元祖鶏卵素麺松屋

1673年（延宝元年）に創業し鶏卵素麺で知られた福岡市西区橋本の「松屋菓子舗」が2012年に自己破産した際に本社工場等を薩摩蒸気屋が引き取り2013年に同所に設立された会社（法人番号：4290001062552）である。松屋菓子舗の一部従業員を引き取り鶏卵素麺などを販売している。西区橋本の本店、博多蒸気屋の直営店での取り扱いがあるほか、岩田屋本店、博多阪急に売り場を持つ。
「松屋菓子舗」の元の経営者は破産後新たに「松屋利右衛門」を設立、こちらも鶏卵素麺を製造販売している。しかしながら博多祇園山笠の名物として知られる「祇園饅頭」の販売権は「元祖鶏卵素麺松屋」が引き継いでおり、「松屋利右衛門」では販売していない。
山口青邨

山口 青邨（やまぐち せいそん、1892年〈明治25年〉5月10日 - 1988年〈昭和63年〉12月15日）は、日本の俳人・鉱山学者。岩手県出身。東京大学名誉教授。
本名は吉郎（きちろう）。初号は泥邨。高浜虚子に俳句を師事、工学博士として東京大学に勤めながら俳誌「夏草」を主宰した。
経歴

岩手県盛岡市出身。父は士族の家柄。5歳のときに母が死去し、母方の叔父笹間夫妻の元で育った。岩手県立盛岡中学校卒業、1910年、第二高等学校入学。野球部でキャプテンを務めた。1916年、東京帝国大学工科大学採鉱科卒業。古河鉱業に入社。1918年、退社し農商務省技師として鉱山省に勤務。19年にはシベリア炭鉱を調査した。1921年、東京大学工学部助教授。1922年結婚。1927年から1929年までベルリンに留学。1929年、東京大学工学部教授。1953年、東大教授を定年退職し名誉教授。東大教授を定年退職して後は、公職につかず、毎日俳壇など各種の新聞・雑誌で選者を務めた。
二高時代にドイツ語教授の登張竹風から文学上の影響を受ける。1920年に石原純、山中登らと、文芸誌「玄土」を創刊、シュトルムの「湖」を日本で初めて訳し、「蜜蜂の湖」の題で発表した。1922年より高浜虚子に師事。「山会」に参加し、はじめは写生文の書き手として頭角を現した。また同年に水原秋桜子、山口誓子、富安風生、高野素十らと東大俳句会を結成。1923年、「芸術運動」発刊。「ホトトギス」の僚誌「破魔弓」にも参加し、同誌が1928年7月号から改題により「馬酔木」となった際には、水原秋桜子らとともに同人のひとりであった。
1928年、ホトトギスの講演会で「どこか実のある話」と題する講演。この中で「東に秋素の二Sあり！ 西に青誓の二Sあり！」と語ったことで、水原秋桜子、高野素十、阿波野青畝、山口誓子の四人が「ホトトギス」の「四S」として知られるようになる。当時虚子・素十と秋桜子との対立が始まったことを慮っての発言であったが、間もなく秋桜子と誓子は「ホトトギス」を離れていくことになった。
1929年、「ホトトギス」同人。以後終生「ホトトギス」の同人であった。1930年、盛岡市で「夏草」を創刊、選者ののち主宰。「夏草」ではのち古舘曹人、深見けん二、小原啄葉、有馬朗人、斎藤夏風、黒田杏子などが育つ。また写生文の掲載も特徴であった。1931年、東京・杉並区和田本町に転居。多くの植物を愛で、のちにみずから「雑草園」と称し句集の題にも取った。1934年、東大ホトトギス会を興し学生を指導。
1988年死去。没後、蔵書は日本現代詩歌文学館に収蔵された。また長く住んだ「雑草園」の住居部分「三艸書屋」も同館の別館として移築・保存されている。墓所は、岩手県盛岡市の東禅寺。
作品

みちのくの町はいぶせき氷柱かな
祖母山も傾山も夕立かな
たんぽぽや長江濁るとこしなへ
銀杏散るまつただ中に法科あり
外套の裏は緋なりき明治の雪
などが代表句として知られる。66年間の句行で『雑草園』『雪国』『露團々』『花宰相』など13句集を刊行、収録数は合わせて1万句を超える。幼児より親しんだ漢詩文の影響が強く、句風は典雅・高潔。科学者としての目も生かした写生・観察に加え、省略や象徴、季語の活用によって複雑なものを単純化することを目指した。
また東北の故郷を愛し「みちのく」として詠んだ。ことに第一句集、第二句集にみちのくの風土を詠んだ句が多い。上掲「みちのくの」の句は1929年に「ホトトギス」初巻頭を取ったときの句で、青邨の「みちのく」句の嚆矢となった句である。山本健吉はまたこの句が「俳人の「みちのく」流行の発端をなしたものと思う」としている。「祖母山も」は1933年作で、大分県の尾平鉱山を訪れた際に作った馬上吟であったという。
青邨は海外詠の先駆者でもあり、ベルリン留学の際に多くの海外詠を試みている。「たんぽぽや」の句は留学の帰途に上海で作ったもので、「ホトトギス」巻頭をとり当時の俳壇に衝撃を与えた。
写生文・随筆の書き手としても知られた。随筆集に、『堀之内雑記』『草庵春秋』などがある。
著書

『山口青邨季題別全句集』（夏草会、1999年）による。
著書 > 句集

『雑草園』（龍星閣、1934年）
『雪國』（龍星閣、1942年）
『花宰相』（龍星閣、1950年）
『庭にて』（龍星閣、1955年）
『冬青空』（近藤書店、1957年）
『乾燥花』（竹頭社、1968年）
『粗餐』（夏草発行所、1973年）
『薔薇窓』（中央公論美術出版、1977年）
『不老』（夏草発行所、1977年）
『繚亂』（夏草発行所、1981年）
『寒竹風松』（夏草発行所、1984年）
『日は永し』（夏草会、1992年）
『山口青邨季題別全句集』（夏草会、1999年）
著書 > 自句自解

『山雨海風』（夏草会、1951年）
『自選自解山口青邨句集』（白鳳社、1970年）
『自註現代俳句シリーズ　第一期　山口青邨集』（俳人協会、1979年）
親族

妻・イソ（1902年生） - 及川古志郎の妹、大島高任の孫
子・山口梅太郎 - 東京大学名誉教授（鉱物学）、日本鉱業会会長
他に、一男二女がいる。
句碑

山口青邨句碑（盛岡市中央公民館）
出典・脚注

1 2 3 4 5 6 7 8 9 10  藺草慶子 「山口青邨」 『現代俳句大事典』 574-575頁
↑  秋尾敏「水原秋桜子と『馬酔木』」『俳壇』第11号、2000年、2012年2月6日閲覧。
1 2  『図説 俳句』 118頁
↑  大屋達治 「山口青邨」 『現代俳句ハンドブック』 99頁
↑  『定本現代俳句』 229頁
↑  『定本現代俳句』 230頁
1 2  大島家家系図コンノ電器総合研究所
↑  92歳「念願かなった」…熊谷で父の句碑と対面　「ホトトギス」の代表俳人・山口青邨氏の長男、梅太郎さん埼玉新聞、2023/05/21
↑  “もりおか近郊自然歩道ガイドブック”.   盛岡市. 2022年11月8日閲覧。
関連文献

古舘曹人編著　『山口青邨の世界 昭和俳句文学アルバム』　梅里書房、1991年　ISBN 978-4872270198
長崎バスジャック事件

| 長崎バスジャック事件 |
| --- | --- |
場所:   日本・長崎県長崎市
標的:  西肥自動車の路線バス
日付:  1977年（昭和52年）10月15日
概要:  バスジャック（人質16名）
武器:  銃、爆弾
死亡者:  1名（犯人）
負傷者:  1名（犯人）
犯人:  「阿蘇赤軍」を名乗る2人組の男
対処:  長崎県警察の警察官がバスに突入し犯人1名を射殺、人質を救出した。
テンプレートを表示
長崎バスジャック事件（ながさきバスジャックじけん）とは、1977年（昭和52年）10月15日に長崎県で発生したバスジャック事件。北九州バスジャック事件（きたきゅうしゅうバスジャックじけん）とも呼ばれる。
本事件は犯人の男2人によって引き起こされ、犯人の1人は射殺され、人質は全員救出された。2000年に西鉄バスジャック事件が発生するまでは、この長崎バスジャック事件が日本史上最大規模のバスジャック事件であった。
なお、本事件の通称は「長崎バスジャック事件」だが「長崎県内で発生したバスジャック事件」の意であり、長崎バス（長崎自動車）の車両がバスジャックされた事件ではなく、被害に遭ったのは西肥自動車のバスである。また、事件が発生した平戸 - 佐世保 - 長崎間の路線バスは既に廃止となっている。
経過

1977年10月15日午前、長崎県平戸発佐世保・大村経由長崎駅前行きの西肥自動車の路線バス（三菱ふそうMP517M、F623号車、登録番号：佐世保22か・344）が、途中の大村市内を走行中、改造銃や手製爆弾で武装した白い覆面姿の2人組の男に乗っ取られた。その後、バスは給油のため長崎市茂里町にある南国殖産のガソリンスタンドに立ち寄ったが、スタンド従業員からの通報を受けた長崎県警察はバスのエンジンスターターを不作動にする措置を行い、バスを包囲した。
犯人たちは乗客5人の解放と引き換えに食料（寿司30人前）や飲料（コーラ30人前など）、毛布50枚を要求した。また、法務大臣の瀬戸山三男と新自由クラブ（当時の野党）代表の河野洋平、政治評論家の細川隆元を連れて来なければ交渉には応じない、などと主張した。この時に犯人たちは自らを「阿蘇赤軍」と極左を想起させる団体名を名乗ったが、右翼的な論調が目立つ保守派の細川を「先生」と呼ぶなど、思想的な見地からは矛盾する発言が目立ち、長崎県警察では早い時点で犯人は赤軍派とは無関係と判断していた。実際に政治思想とは何ら関係ない身代金を狙った場当たり的な犯行であった。
犯人は人質の女性の首に爆発物のようなものを巻き付け、また車内の窓に針金のようなものを張り巡らし「窓が一枚でも割れたら爆発する」などと脅迫していたが、警察官が差し入れを行った際に針金の一部が外れたものの爆発しなかったことから、女性の首に巻かれた爆発物が偽装であることを警察に把握されていた。
警察は犯人たちに対し説得を行ったが、人質の体力が限界に達したとして、事件発生後18時間経過した翌16日午前4時25分、警察官の一人が説得しながら最終的に「撃つなら撃て、俺を撃ってみろ!」と犯人を挑発したところ、主犯格の男が手製爆弾を投擲。爆発した瞬間に突入部隊は一斉にバス内部へ突入した。この時警官3名が拳銃を発砲し（合計7発）、被弾した主犯の男が20分後に死亡、もう1人の犯人は重傷を負った。人質16人は全員無事に救出された。
犯人射殺による人質事件の解決は、1970年5月12日に発生した瀬戸内シージャック事件以来2例目となった。また本事件の約1年3ヵ月後の1979年1月26日に発生した三菱銀行人質事件以降、日本国内における人質立てこもり事件で犯人射殺により解決に至ったケースは存在しない。
また、警察は朝食として味噌汁を差し入れ、犯人の一人が味噌汁の入った鍋の取っ手をつかんだと同時に犯人を取り押さえ、バスに突入する作戦を検討していたが、事件発生翌日の明け方の時間帯に突入が行われたため、この作戦は実施されなかった。
重傷を負った犯人には、懲役6年の判決が言い渡された。
報道

この事件は長崎放送とテレビ長崎が、突入から逮捕、人質救出までの様子を全国に中継しているが、後側からズームカメラで写した映像がVTR保存されており、この映像は鮮明に写っている（近距離の映像は16mmフィルムで撮影されているため不鮮明である）。当時の長崎県内の民放テレビ局はこの2局だけで、テレビ長崎は当時日本テレビ系列とフジテレビ系列のクロスネット局だった（突入が行われた時間帯は日本テレビ系列の番組をネット）。またNHK長崎放送局もバス運転席側から突入の瞬間を撮影している。
長崎放送では事件発生当日夜に、パトカーに対するカージャックを題材にした映画『続・激突!/カージャック』が、テレビ朝日系列フルネット局において同年7月に『日曜洋画劇場』として放送されたものを『ゴールデン洋画劇場』として放送していたが、その番組を中断してこの事件の生中継が放送された。長崎放送では事件発生当日にフィルムカメラのオーバーホールが行われており、また中継車を翌日のゴルフ中継のために準備させていたが、最終的にゴルフ中継に支障が出るとしても中継車を事件現場に投入すべきとの意見が通り、人質救出の様子を中継することとなった。
また、テレビ長崎が日本テレビ系列局として日本テレビに送ったこの事件の取材映像が、日本テレビ制作の朝のワイドショー番組『ミセス&ミセス』でも使われたが、この番組がテレビ長崎ではなく長崎放送で時差ネットされていたため、テレビ長崎の取材映像が長崎放送で放送されることとなった。当時は取材がフィルム主体で前述のオーバーホールで出遅れ気味だった長崎放送に比べ、取材を優位に進めていたテレビ長崎では、社内で当該番組を見た全員が驚いたという。
事件後

バスジャックに遭った車両は、警察の捜査後に西肥自動車へ返還され、修理を受けて営業用に復帰し、1995年（平成7年）まで使用された後に廃車された。[要出典]
その後、当該車両は個人の手に渡り、長崎県内の山中に置かれ、物置きとして使われていることが、事件から40年以上経った2018年に報じられた。バスは朽ち錆びてボロボロになっていたが、車体には事件当時の広告が貼られたままであった。
Javaに対する批判

Javaに対する批判（ジャバにたいするひはん）では、プログラミング言語Javaと、その主たる実装であるJDKやその他の実装に関する批判、およびJavaプラットフォームの性能に対する批判について説明する。Javaプラットフォームの性能に関する、批判以外の内容については「Javaの性能」を参照のこと。
Javaは優れた技術だと評価する人々がいる一方で批判も少なくない。Javaはソフトウェアに関する複雑さを管理する問題に対して革新的な方法を提供するという目標のもとで開発された（ないし、そのように信じられている）。多くの人々[誰?]は、Java技術はこの期待に対して満足できる答えを提供したと評価している。
しかしJavaにも欠点が無いわけではないし、どのようなプログラミング作法にも適応しているというわけでもない。また、どのような環境や要件にも普遍的に適応しているというわけでもない。
ソースコードレベルでのプログラミングパラダイムの追加や記述性の改善を求めて、Java仮想マシン (JVM) 上で動作するScalaやKotlinといった後発言語も出現しているが、JVMベースの互換言語であるがゆえに、JVMに存在する制約もまた残されている。
クラスパス

Javaプログラムを実行する際、すべてのサードパーティーのライブラリはクラスパスに存在する必要がある。これは移植性の障壁となる。なぜならばクラスパスの文法はプラットフォームに依存するからである。例えばWindowsベースのシステムはサブディレクトリを区切るためにバックスラッシュ "\" を使用し、パス区切りにセミコロン ";" を使用している。だが一方、他の多くのプラットフォームではサブディレクトリ区切りにスラッシュ "/" を使用し、パス区切りにコロン ":" を使用している。
各々の.jarや.zipアーカイブはクラスパスにおいて明示的に名前がつけられる必要がある。この抜け道としてアスタリスク(*)で終わるクラスパスを指定することで、そのディレクトリにある.jarや.JARで終わるすべてのファイル名にマッチさせることができる。しかしながら、.zipや.classファイルのようなものはマッチしない。
クラスパス > 解決策・代替策

これらのクラスパス問題は環境変数CLASSPATHを使用せず、サン・マイクロシステムズが推奨する-classpathオプションを使用することで解決する。開発時は、-classpathオプションはバッチファイルやmakeや Apache Ant や統合開発環境を使うことで便利に指定することができる。Javaアプリケーションを利用する実行エンドユーザに対しては、開発者がマニフェストファイルにクラスパスを記述するか、FatJarやOneJarという、複数のjarファイルを一つにまとめるツールを使うことで解決できる。
ライセンス

サン・マイクロシステムズ（サン）のJavaの財産的価値は自由ソフトウェアコミュニティで議論を呼んだ。なぜならばサンのJavaの実装は自由ソフトウェアではなかったため、自由ソフトウェアや主にDebianや$100ラップトップ、Fedora CoreのようなGPL互換ライセンスが要求されるプロジェクトにはサンのJavaを含めることはできなかった。
サンは JavaOne 2006 で、Javaはオープンソースソフトウェアになるだろうと公表した。この声明はSun Softwareの上級副社長Rich Greenによって公表された。「オープンソースソフトウェアにするか否かという問題はない。どのような方法でオープンソースにするかが問題である。つまり我々はこれを実行する。」
2006年7月には、サンの最高技術責任者Robert BrewinはJavaは2007年6月に部分的にオープンソースになるが、全体のプラットフォームが完全なオープンソースになるには時間がかかるだろうとコメントしている。
2006年11月13日、サンは標準版Java実行環境は2007年3月にGPLの下でリリースされる予定であることを公表した。Java実行環境のソースコードはGPLの下で利用可能になる予定である。リチャード・ストールマンによると、これはJavaの罠の終焉を意味するとのことである。マーク・シャトルワースはJavaのオープンソース化についての最初のSunによる発表を「自由ソフトウェアコミュニティにとっての確かなマイルストーン」と評価した。
ライセンス > 解決策・代替案

Javaのライセンスの問題は徐々に解決されつつある。時間が解決していると言える面もあるといえる。今後も新たなライセンスの問題に直面しそうであれば、Java Community Process に提案するよう働きかけてみるという手段もある。フリーソフトウェア財団や Eclipse Foundation など他のオープンソースコミュニティの助けを借りることで問題を解決に向けて進めることができる可能性がある。
リソース管理

Javaはメモリを管理するが、他のリソース（ファイルやJDBCデータベース接続など）は管理しない。これらはC言語およびC++でヒープに動的確保したメモリを明示的に解放する必要があったのと同様、プログラマによって解放されなければならない。
リソース管理 > メモリ管理

Javaはガベージコレクションによるメモリ管理機能を備える。これによって、完全ではないもののプログラマがメモリリークを起こすようなプログラムを作ってしまう危険性を減らした。Javaではオブジェクトは常にヒープ領域に（JITコンパイラによって最適化されてスタックやレジスタに割り当てられない限り）確保される。ローカル変数はスタックやレジスタに確保される。C++ではオブジェクトをヒープ領域に割り当てるかスタック領域に割り当てるかをプログラマが選択することができたが、Javaではそれが不可能になっている。
オブジェクトはガベージコレクションによって管理されるが、Javaはプログラマにガベージコレクションがいつ起こるかを保証しない。プログラマはガベージコレクションを阻止することができないし、たとえSystem.gc()を用いても任意のオブジェクトを任意のタイミングで解放することはできない。これはプログラミングを簡易にしメモリリークの可能性を軽減するが、決定論的でより効果的なメモリ処理を行うための柔軟性が犠牲になっている。C言語やアセンブリ言語のような低水準言語はこの柔軟性を提供する。
C++などで書かれた多くのプログラムはメモリリークの犠牲になりがちだが、問題はメモリリークだけではない。ファイルハンドルやデータベース、ネットワーク接続のような他のリソースのリークは特に例外が投げられたときに常に起こりうる。C++ではRAIIと呼ばれるイディオムによっていずれの問題も克服することができるが、Javaプログラマは忘れずにfinally節でリソースを解放する必要があり、Javaが何を解放するかということとプログラマは何を解放しなければならないのかということをきちんと理解する必要がある。
リソース管理 > 解決策・代替案

この問題は、メモリを増設する、最大ヒープメモリサイズを拡大するなどで解決できるケースもある。弱い参照 (WeakReference/SoftReference/PhantomReference) を用いることで多少の解決策になることはある。だが、JREやJDKのバージョンが特定の古いものであることが要因となっていることもある[要説明]。最新版のJREやJDKで実行、開発すれば問題発生率を下げることもできる。
finally節の問題は、場合によっては、ライブラリやフレームワークによって解決できることもある。ファイル入出力の場合はApache Commons IOを、データベース接続の場合はApache Commons DBUtils、HibernateやApache Cayenneなどのオブジェクト関係マッピングフレームワークを用いることでfinally節のことをあまり多く気にしなくても良いようにする手段がある。Java 7ではtry-with-resources文でこの問題に対処している（例外安全の確保）。
言語選択 > プリミティブ対オブジェクト / オートボクシング

Javaの設計者らは、現在他の言語にあるいくつかの機能（多重継承、演算子多重定義、タプルなど）を実装しないことを決めた。
総称型（ジェネリクス）がJava 5.0に導入されたとき、すでにJavaにはクラスの大規模な枠組みがあった（それらの多くはすでに非推奨となっていた）、そして後方互換性を保つため、総称型の実装方法として既存のクラスを維持することを可能にする（コンパイル時の）型消去（型削除、type erasure）が選ばれた。これは、他の言語と比べると、総称型の導入によって提供される機能を限定してしまう結果になった。
Javaのプリミティブ型はオブジェクトではない。プリミティブ型は値への参照ではなく値そのものをスタック領域に保持している。この設計選択はパフォーマンス上の理由により行われた。このためJavaは純粋なオブジェクト指向言語と見なされていない。またこのことによりリフレクションがより複雑になっている。配列を除き、Javaのコレクションクラスはプリミティブ型を直接扱うことができず、プリミティブラッパークラスへのボックス化が必要となる。この制約はジェネリクスにおいても変わりない。Javaのジェネリクスは型安全性が担保されるだけであり、ジェネリクスを使わない場合と比べてパフォーマンス上のメリットはない。
また、Java 5.0は、コンパイル中に要求された場合にプリミティブ型を対応するプリミティブラッパークラスのオブジェクトに自動変換する機能（オートボクシング）をサポートしているが、オートボクシングではNullPointerExceptionが投げられる可能性がある。オートボクシングは暗黙のうちに起こる（キャストやメソッド呼び出しを伴わない）ため、このNullPointerExceptionという非チェック例外はJavaプログラムのコードに目を通しただけでは明確にはならない恐れがある。
言語選択 > 非virtualメソッド

Javaはメソッドを非virtualにする手段を提供しない（オーバーライドを禁止するためにfinal修飾子を使用することで封印することはできる）。これは派生クラスに、同じ名前の関係の無いメソッドを定義させる方法がないことを意味する。これは基底クラスが別の人間によって設計されるときに問題となることがあり、また、新しいバージョンが、派生クラスで同じ名前のメソッドがすでに存在するときに、同じ名前とシグネチャのメソッドを導入することで問題となることがある。これは、どちらのクラスの設計者の意図にも反して、派生クラスのメソッドが基底クラスのメソッドを暗黙のうちにオーバーライドするであろうことを意味する。これらのバージョン問題にある程度適合するためにJava 5.0は@Overrideアノテーションを導入しているが、後方互換性を保つには、それをデフォルトでは強制できない。
言語選択 > 単一パラダイム

Javaは主にオブジェクト指向の単一パラダイム言語である。すべてのデータと処理は必ず何らかのクラス内に記述しなければならないため、必要以上にコードが冗長になってしまうことがある。Java 5.0で追加された静的インポート (static imports) はこれまでのJavaよりも手続きパラダイムによりよく順応する。
言語選択 > 例外処理

JavaではC++でオプションとされていた例外処理の仕様を取り込んだが、この際チェック対象の例外に対応するthrows文を必須とした。例外のチェックは小規模なシステムにとっては役立つが、大規模なシステムについても有益であるかどうかについては統一的な見解には至っていない。特に上位のコードでは下位のコードから発生するエラーを意識したくない（例としては、名前解決例外であるNamingException）。名前クラスの作成者は名前解決例外をチェック対象の例外として上位コードに対応を強制するか、コンパイル時のチェックを使わずに下位のコードからの例外を連鎖的に通知するかを選択する必要がある。
言語選択 > クロージャ

Javaでは、内部クラス、ローカルクラス、匿名クラスを使用することで、基本的なクロージャに近い記述が実現できる。しかしこれは完全ではなく、ローカルクラス／匿名クラス外の変数に対する参照を、ローカルクラス／匿名クラスのフィールドとして暗黙キャプチャできるように、final修飾子付きで宣言する必要がある。これは、変数のスコープを抜けたときに削除できるような、様々な寿命に対応したスタックモデルをJVM実装者が選択できるようにするためである。Java 8では実質的にfinalとみなせる変数は明示的にfinal修飾する必要がなくなったが、依然として再代入は許可されない。
また匿名クラスの構文も冗長であり、例えばRunnableインタフェースを要求する場面で、同インタフェースを実装する匿名クラスを定義する場合、単純なコードブロックとして定義することはできず、Runnable.run()メソッドを実装するようなクラスのブロックを定義する必要がある。Java 8ではラムダ式と関数型インタフェースによりこの問題を改善している。
言語選択 > メソッド参照

Java 7以前にはC/C++の関数ポインタやC#のデリゲートに相当するメソッド参照の機能がなく、インタフェースで代用するしかなかった。Java 8ではメソッド参照が追加された。
浮動小数点演算

Javaの浮動小数点演算は主にIEEE 754（二進化浮動小数点数演算標準）をベースとしているが、例えばIEEE 754に必須とされる例外フラグや方向指定の丸めなどの、いくつかの機能については"strictfp"修飾子を指定した場合でもサポートされない。Javaの仕様として知られているものはJava自体の問題ではないが、浮動小数点数演算を行う上で避けて通れない問題である。
ルックアンドフィール

Java用のクロスプラットフォームなウィジェットツールキットのひとつにSwingがある。Swingを使って書かれたアプリケーションのグラフィカルユーザインタフェース (GUI) のルック・アンド・フィール（look and feel、直訳すると「外観と操作感」）は大抵、各プラットフォームネイティブのアプリケーションのものと異なる。プログラマはネイティブのウィジェットを表示するAWT（ネイティブであるためOSのプラットフォームと同じ見た目を提供する）を使うことを選択することができる。しかしAWTツールキットは、高度なウィジェットのラッピングを必要とし、かつ様々なサポートされたプラットフォームで移植性を犠牲にしない高度なGUIプログラミングには向いていない。そして、SwingとAWTにはとりわけ高水準ウィジェットにおいてAPIが大きく異なる。
Swingツールキットは全てJavaで実装されている。Swingツールキットはネイティブアプリケーションとは異なるルックアンドフィールを持つという問題がある。一方でSwingツールキットのウィジェットはネイティブなツールキットの機能に限定されないという利点がある。この利点は全てのプラットフォームで利用できることが保証される最も基本的な描画機構を使ってウィジェットを再実装していることによる。不幸にも、（2006年8月の時点で）Java実行環境 (JRE) のデフォルトのインストールでは、Swingデフォルトの埋め込みMetal (メタル) ルックアンドフィールの代わりに、システムの「ネイティブ」なルックアンドフィールを使わなかった。プログラマがUIManagerを使ってシステムネイティブなルックアンドフィールを設定しなかった場合、ユーザーは外観がネイティブアプリケーションのそれとは非常に異なるアプリケーションに遭遇するだろう。 macOSの配布元に限って含まれるApple自身のJava実行環境の最適化バージョンは、デフォルトで「デフォルト」をセットし、"Aqua" のルックアンドフィールを実装し、Macintosh上のSwingアプリケーションは、ネイティブなソフトウェアに似た外観を提供している。macOSの環境でさえ、プログラマはそのアプリケーションがAquaのように見えることを確実とするために、若干の余分の作業をまだしなければならない（例えば、メニューバーをWindowsのように各アプリケーションウィンドウ内部に表示するのではなく、macOSのメニューバー内部に表示させるために、システムプロパティをセットする必要がある）。
ルックアンドフィール > 解決策・代替案

この問題は、開発者がJavaのバージョンを Java SE 6以降にアップグレードすることで解決する。Java SE 6になってからJavaのデスクトップまわり、GUI環境は一新され、開発効率は高まっているため、以前のバージョンよりも開発の手間はかからなくなっている。
パフォーマンス

→「Javaの性能」を参照
パフォーマンス > 一般

Javaプログラムのパフォーマンスに関して一般論を述べることは不可能である。なぜなら、実行時の性能は、言語自身が持つ固有の特性よりも、JavaコンパイラやJava仮想マシンの品質に非常に大きく影響されるからである。Javaバイトコードの実行方法は、仮想マシンによって実行時に翻訳して実行する方法と、ロード時もしくは実行時に機械語にコンパイルしてハードウェアによって直接的に実行する方法がある。前者の翻訳実行する方法は機械語の実行よりも遅く、後者のロード時もしくは実行時にコンパイルして実行する方法は、最初のコンパイル時にパフォーマンスが犠牲になる。これはJavaにかぎらず、.NET Frameworkなど他の仮想マシンベースのプログラミング環境においても同様である。
コンピュータハードウェア性能の向上と、Javaのバージョンアップに伴う最適化技術の進歩によって、Javaプログラムの初回起動時のオーバーヘッドなどは誤差の範囲内になりつつあるが、ヴィルトの法則が示すように、総じてソフトウェアの複雑化やシステム要求の上昇にハードウェアの性能向上が追い付いていないのが現状である。C/C++ではJavaよりも細やかな最適化を手動で施すことができるが、プログラマが手作業で施した最適化よりも、JITコンパイルによる自動最適化のほうが性能面で上回るケースもすでに存在する。C/C++でJavaの実行時最適化技術を真似することは困難である。
パフォーマンス > 一般 > 言語仕様による制約

Javaだけに限ったことではないが、パフォーマンス上の障壁となる言語仕様や言語仕様の欠落がいくつか存在する。それは例えば配列境界チェックや実行時型チェック、非仮想メソッドの欠如などである。ただしコードの安全性と性能はトレードオフの関係にあるため、チェック機構が一概に悪とは言えない。また、コンパイル時の最適化やJVMの実装次第で解消できるものもある。そのほか、Javaは構造体（ユーザー定義の値型）および矩形配列（真の多次元配列）を持たず、それぞれクラス（参照型）およびジャグ配列（配列の配列）などで代替する必要がある。また、Javaではメソッドから複数の値を返すためにはクラスや配列といった参照型を使用する以外の方法がない。これらの制約によってJavaのプログラムコードは、他の言語で書かれたコードよりも頻繁にヒープを使用しなければならなくなっている。
パフォーマンス > ガベージコレクション

不要オブジェクトの自動回収を行うガベージコレクションは明示的なメモリ解放に比べそのオーバーヘッドは大きいが、ガベージコレクタの実装やアプリケーションでのオブジェクトの利用状況によってその影響はまちまちに変化する。多くのJava仮想マシンは世代別ガベージコレクションの採用によって動的メモリ管理を高速化しているため、多くのアプリケーションでは高い性能を示している。
パフォーマンス > バイトコード対ネイティブコンパイル

一般に、プログラミング言語とその実行方法は、直交するのが普通で、コンパイラだったり、インタプリタだったり、バイトコード方式だったりする実装があっても構わないはずである。しかし、Javaには、実装上制限があり、あまりに自由度がない。
ジャストインタイムコンパイル（JITコンパイル）とネイティブコンパイルの性能差はほとんど無いとされるが、よく議論の種にもなる。JITコンパイルには時間が掛かるため、短時間で起動終了することが求められるアプリケーションや、起動と終了を頻繁に繰り返すアプリケーション、またプログラム内容が巨大なアプリケーションでは問題となる。しかし、一旦ネイティブコードに変換すれば数値計算においてもネイティブコンパイルと同等の性能を示す。
Javaはメソッド呼び出しの明示的なインライン化をサポートしないものの、多くのJITコンパイラではバイトコード読み込み時にインライン展開を行い、また実行時のプロファイリングを利用してその効率をより高めている。HotSpot仮想マシンが採用している動的再コンパイルでは、実行時でしか取得できない情報を利用することで、多くのプログラミング言語が採用する静的コンパイル方式を超える性能を得る場合もある。
ハードウェアインタフェース

Javaはセキュリティと移植性を重視して設計されたので、Javaではマシンアーキテクチャとアドレス空間への直接アクセスをサポートしていない。スキャナ（デジタルカメラ、オーディオレコーダ、ビデオキャプチャ）ないし実質的に直接メモリ空間の制御（一般的に、ドライバインストールを必要とするハードウェアやそれらの部品）を必要とする特定の一部のハードウェアを動かすことはJavaでは容易に実現できないことを意味する。この問題の実例はJavaのバージョン1.0で見られた。様々なプリンタドライバへのインタフェースコードがこの初期のJava実行環境に含まれず、プリンタへのアクセスが可能でなかった。
ハードウェアインタフェース > ネイティブコードとインタフェース

ハードウェアに直にアクセスするクライアントサイドまたはサーバシステムは、ネイティブコードとJavaライブラリを橋渡しするJava Native Interface (JNI) を使って、C/C++およびアセンブリ言語とJavaを組み合わせる方法を取る。また、ハードウェアアクセスを担うネイティブコードとJavaとの通信をファイルやデータベース、共有メモリやソケットを介して行う方法もあるが、理想的なやり方ではない。
JNIを使うことで、プラットフォーム依存性、潜在的なデッドロック、メモリリーク、場合によっては性能の著しい劣化などの問題が発生しうる。また、2つの異なるコードベースをメンテナンスするために必要となるコードの複雑性は、言うまでもない。しかし、それは、例えば.NET Frameworkの共通言語ランタイムにおけるP/Invokeのように、他の仮想マシン環境と共通する事例である。
ハードウェアインタフェース > 解決策・代替案

現在では今のところ、Javaはまだまだハードウェア開発、デバイスドライバ開発には適していない点が多い。この問題について、JavaでUSBドライバ開発ができる Java Communication API という技術がすでにある。他にも、Jini対応機器を端末に接続すると、サーバから自動的にJava製ドライバを端末にダウンロードしてその機器を使うことができる技術Jiniというものが考えられている。なおこのJiniは、Java Native Interfaceを意味するJNIとは別物である。
一貫性のないJava仮想マシン実装

Javaは、Java仮想マシン (JVM) の上部で動くバイトコード言語である。異なるプラットフォームで実行できる能力と言語の互換性は、最終的にはJVM実装の安定性とJVMのバージョンに依存している。Javaは非常に様々なシステム上で動くとうたわれているが、最新のJVM（とJRE）はWindows、Linux、Solaris対応だけ活発に更新されている状況である。HP-UX（Java for HP-UXなど）とIBM (for MVS、AIX、OS/400) は、それぞれのプラットフォームファミリー独自の実装を提供するが、必ずしも最新のサン・マイクロシステムズのリリースを反映していない。他のプラットフォームにおけるJVM実装も、たいてい今後も続くが、時々一般の実装例よりも何年か何ヶ月か遅れるので、互換性問題が生じる。具体的な例を示すと、Java 2 Platform Standard Edition 1.5 (J2SE 1.5) をサン・マイクロシステムズがリリースしたのは2004年9月30日だが、Mac OS X用J2SE 1.5をAppleが公開したのは2005年3月であり、5か月余りの差が生じている。
移植性・互換性

"Write once, run anywhere"（WORA、一度書けばどこでも動く）という言葉があるとおり、Javaの目標の一つにプラットフォーム非依存があげられる。JavaコンパイラはJava仮想マシン用の中間言語（Javaバイトコード）を生成する。コンパイルされたJavaのプログラムは、Java仮想マシンを実行環境として動作する。この仮想マシンがハードウェア間の差異を吸収することで、プラットフォーム非依存を実現している。ただし、現時点では一部にプラットフォーム依存の部分があり、完全なプラットフォーム非依存ではない。
また、マルチプラットフォームにするということは、一部のプラットフォームにしかない独自の機能はJavaから使えないことを意味する。
例えばWindows用のマルチメディアAPIであるDirectXや、3DグラフィックスAPIであるDirect3DはJavaから直接呼び出すことはできない。そのため、橋渡しをするための拡張APIが提供されている。
またJavaではバージョン間の前方互換性・後方互換性の問題が議論の対象になっている。Javaではバージョン間の互換性をある程度の水準まで達成している。しかし、バージョンの異なる実行環境の取り扱いには課題が残っている。例えばJ2SE 1.4実行環境用に書かれたプログラムは、実行環境にJ2SE 1.3を想定すると明示的に指定してコンパイルしなければJ2SE 1.3実行環境では動かず、利用するライブラリがJ2SE 1.4以降から追加されたものである場合にはJ2SE 1.3実行環境での実行を諦めなければならない。J2SE 1.3に対する後方互換性は、2世代先であるJ2SE 5.0まで保証されている。J2SE 1.3以降のJavaプログラムでは前方互換性は保証されないが、Java実行環境 (JRE) の自動アップデート機能によって仮想マシンを最新バージョンにアップデートすれば解決できる。JDK 1.1、J2SE 1.2 時代のJavaプログラムは、現在[いつ?]となっては古いため、後方互換性問題に引っかかる可能性がある。例えば、古いプログラムが新しいバージョンのJDK/JREで廃止されたAPIを使用している場合に問題となる。その場合は、そのJavaプログラム開発者に最新版のJavaコンパイラでもコンパイルが通るように修正してもらうしかない。
移植性・互換性 > 解決策・代替案

この問題も、サン・マイクロシステムズのJavaコーディング規約をJavaプログラマが守っていればほぼ起きることがなく、Javaソースコード上のimport宣言や新しく加わったJavaキーワード（enumやassert）と重複するものが無ければほぼ心配することもなくなる。とくに、多くの場合において、これらの問題はコーディング規約だけでなく、統合開発環境やCheckStyle、FindBugsなど各種ツールなどによって解決できるケースがある。Javaプログラマは、日頃からCheckStyleやFindBugsを使ってプログラミングしていれば、後方互換性の問題につき当たる可能性は下がる。しかし、Javaアプレットなどのように、方針転換による大規模な機能廃止もありうる。JDK/JREにはサポート期間が定められており、古いJDK/JREを永久に使い続けることはできないため、廃止予定となったAPIが完全廃止される前に代替技術に移行するなど、最新のJava技術動向に追随していく必要がある。
兼松煕

|  大日本帝国の政治家兼松 煕かねまつ ひろし |
| --- | --- |
 肖像写真
生年月日:  万延元年12月28日 （新暦：1861年2月7日）
出生地:   江戸幕府 美濃国加茂郡酒倉村 （現・岐阜県加茂郡坂祝町）
没年月日:   (1952-06-28) 1952年6月28日（91歳没）
前職:  佐賀郡長
所属政党:  無所属
称号:  従七位勲四等
 衆議院議員
選挙区:  佐賀県郡部→岐阜県郡部
当選回数:  2回
在任期間:  1903年3月1日 - 1908年3月1日
テンプレートを表示
兼松 煕（兼松 凞、かねまつ ひろし、万延元年12月28日〈1861年2月7日〉 - 1952年〈昭和27年〉6月28日）は、明治末期から昭和初期にかけて活動した日本の政治家、実業家である。岐阜県出身。
内務省官吏や郡長などを経て政界入りし1903年（明治36年）から1908年（明治41年）まで衆議院議員を務める。その後実業家に転身して主として東海地方の電力業界で活動し、1930年代には豊田式織機（現・豊和工業）社長を務めた。
経歴 > 衆議院議員当選

兼松煕は万延元年12月28日（新暦：1861年2月7日）、農家兼松勝介の長男として生まれた。出身地は美濃国加茂郡酒倉村（現・岐阜県加茂郡坂祝町）。木曽川対岸の犬山にて漢学者村瀬乙太（頼山陽門下）が開いていた私塾にて学ぶ。21歳のとき郷里の戸長に選ばれた。
戸長から郡書記、次いで岐阜県属官となり、さらに中央に出て内務省属官を経て拓殖務省が発足するとその事務官に転ずる。その後台湾における鉄道建設計画に参加し実業界進出を志すが、計画自体が頓挫したため方向を転じ、佐賀県へ赴任して佐賀郡の郡長に就任した。就任は1899年（明治32年）1月11日付、休職は1900年（明治33年）2月17日付、免官が同年9月3日付である。
郡長退任後九州における炭鉱事業の計画に参加するがこれも流れたため実業界入りを再び断念。その後は政界入りを目指し、1903年（明治36年）3月実施の第8回衆議院議員総選挙にて佐賀県郡部選挙区から無所属で立候補し当選、衆議院議員となった。翌1904年（明治37年）3月実施の第9回総選挙では出身地の岐阜県郡部選挙区に鞍替えし、第2位の得票数で再選を果す。議員在任中、日露戦争開戦前は「対露同志会」に参加し、開戦後は日本軍向けのたばこ輸出事業を思いつき利益を挙げたという。1908年（明治41年）3月に衆議院議員任期満了となった。