虛擬Java JAR命名約定

我在Sun官方文檔（或Sun在線教程）中閱讀了關於jar歸檔的虛線命名。是否曾鼓勵將名稱爲jar的工件稱爲com.company.project.smallestdistributable.jar？虛擬Java JAR命名約定

2012-06-21 Mykhaylo Adamovych

通常情況下，這種情況會不時發生，因爲虛線命名約定可以模擬系統中名稱空間，它並不真正處理名稱空間。

在你的情況下，你將模擬文件系統中的「com.company.project」命名空間，其分辨率爲「smallestdistributable.jar」。

我沒有看過Java文檔（從1.2版開始）曾經建議使用類似這樣的命名系統來處理JAR文件。雖然人們無法確定它爲什麼從未被推薦，但人們可以猜測。早期的系統沒有將虛線擴展看作是名稱的一部分，但有時將它們看作是分類器。在最早的系統中，名稱和分類器對允許的字符數有非常嚴格的限制，文件系統只允許使用[NAME]。[CLASSIFIER]模式。一個JAR文件（順便說一下，它是3個字符，因爲如果你希望文件名是可移植的，這是文件系統中最短分類器可用的最長分類器），如果包含額外的時間段會破壞文件系統對文件的理解，所以

com.company.project.smallestdistributable.jar

將被視爲

file: com 
extension: company.project.smallestdistributable.jar

實際上，除了它甚至不會走到這一步，因爲擴展不可能有擴展。

我見過一些較新的項目，不關心[8]。[3]命名約定會將名稱空間添加到jar文件名中，但它似乎是一個新想法，而不是在這些開發領域之外明確提出的。

來源

2012-06-21 17:45:17

這種方法在Eclipse中成功使用，我非常自信我已經在Sun在線教程中閱讀了這個內容，但是現在找不到這樣的東西。多年以前，當C＃抓住所有他們的想法時，我爲java感到自豪，並且已經看到了這種用於C＃DLL的方法。我總是想知道爲什麼像maven這樣的項目不遵循這個規則，因爲儘管所有的庫在庫中一起都很好地運行，但一旦部署到執行環境中，你總會有一些非唯一名稱的風險（這真的發生在我參與的一個項目中）。 –

@MykhayloAdamovych我相當（100％）確信這種方法在任何Sun在線教程中都是__not__，因爲我已經在Eclipse中看到了這一點，並且SUN指示人們不要包含那些使它們的Java無可移植性的奇怪事物，比如命名它[8]上不能存在的東西。[3]文件系統。也許你已經看到了在其他地方使用的技術，並且錯誤地用文件名來標識它，因爲在許多情況下它是由SUN推舉的，但不包括文件名的情況。 –

虛擬Java JAR命名約定

回答

相關問題