Java 開發環境中的數個工具可幫助 dependency 管理：Apache Ant 和 Apache Maven 這兩個 build system 皆包含特別用來幫助管理 dependency 的功能，而 Apache Ivy 則開發為 dependency 管理員。儘管它們的運作方式有差異，但這些工具皆共用一般的功能，即會自動下載在建立過程中所指定的外部 dependency。這樣一來，不同的開發人員要用一樣的方式來建置軟體會變得更容易。開發人員只需在建置檔中儲存 dependency 資訊，這表示每位開發人員和建置工程師都使用相同的方法來取得 dependency、編譯程式碼以及部署，不需要進行混亂的手動 dependency 管理。以下的示例說明如何在建立過程中，用 Ivy、Ant 和 Maven 來管理外部相依性。

使用 Ivy 時，開發人員會指定 dependency 名稱和版本，而不是列出從中擷取 dependency 的明確 URL，Ivy 依靠其基本組態來識別要從中擷取 dependency 的伺服器。使用共同的元件使得開發人員節省了搜尋 dependency 位置的時間。

範例 1：以下來自 Ivy ivy.xml 檔案的摘錄顯示了開發人員如何使用名稱和版本來指定多個外部相依性：

<dependencies>
  <dependency org="javax.servlet"
             name="servletapi"
              rev="2.3" conf="build->*"/>
  <dependency org="javax.jms"
             name="jms"
              rev="1.1" conf="build->*"/>  ...
</dependencies>

兩個不同類型的攻擊情況會影響這些系統：攻擊者可能會危害控制 dependency 的伺服器，或危害 DNS 伺服器，建置機器用其來將控制 dependency 伺服器主機名稱的要求重新導向到攻擊者所控制的機器。此兩種情況都會使得攻擊者可將 dependency 的惡意版本插入到未受危害的機器上所執行的建置中。

不管攻擊者用來傳遞 Trojan dependency 的手段是什麼，這些情況都存在一種共同要素，即 build system 盲目的接受惡意的二進位程式並把它包含在建置中。因為 build system 無法拒絕惡意的二進位程式和現有的安全機制 (例如程式碼審核)，所以通常會著重於內部開發的程式碼而非外部的 dependency，此類攻擊可在不易察覺的情況下傳播到開發環境並潛進產品中。

雖然手動建置過程中存在 dependency 受到危害的風險，但由於自動化 build system 有從外部來源擷取 dependency 的趨勢，使得每次 build system 在新環境中執行時，會增加攻擊者的攻擊機會。攻擊者只需在 dependency 伺服器或 DNS 伺服器擷取 dependency 時造成一次危害，便會危害執行建置的機器。

Java 開發環境中的數個工具可幫助 dependency 管理：Apache Ant 和 Apache Maven 這兩個 build system 皆包含特別用來幫助管理 dependency 的功能，而 Apache Ivy 則開發為 dependency 管理員。儘管它們的運作方式有差異，但這些工具皆共用一般的功能，即會自動下載在建立過程中所指定的外部 dependency。這樣一來，不同的開發人員要用一樣的方式來建置軟體會變得更容易。開發人員只需在建置檔中儲存 dependency 資訊，這表示每位開發人員和建置工程師都使用相同的方法來取得 dependency、編譯程式碼以及部署，不需要進行混亂的手動 dependency 管理。以下的示例說明如何在建立過程中，用 Ivy、Ant 和 Maven 來管理外部相依性。

使用 Maven 時，開發人員會指定 dependency 名稱和版本，而不是列出從中擷取 dependency 的明確 URL，Maven 依靠其基本組態來識別要從中擷取 dependency 的伺服器。使用共同的元件使得開發人員節省了搜尋 dependency 位置的時間。

範例 1：以下來自 Maven pom.xml 檔案的摘錄顯示了開發人員如何使用名稱和版本來指定多個外部相依性：

<dependencies>
  <dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1</version>
  </dependency>
  <dependency>
    <groupId>javax.jms</groupId>
    <artifactId>jms</artifactId>
    <version>1.1</version>
  </dependency>
  ...
</dependencies>

兩個不同類型的攻擊情況會影響這些系統：攻擊者可能會危害控制 dependency 的伺服器，或危害 DNS 伺服器，建置機器用其來將控制 dependency 伺服器主機名稱的要求重新導向到攻擊者所控制的機器。此兩種情況都會使得攻擊者可將 dependency 的惡意版本插入到未受危害的機器上所執行的建置中。

不管攻擊者用來傳遞 Trojan dependency 的手段是什麼，這些情況都存在一種共同要素，即 build system 盲目的接受惡意的二進位程式並把它包含在建置中。因為 build system 無法拒絕惡意的二進位程式和現有的安全機制 (例如程式碼審核)，所以通常會著重於內部開發的程式碼而非外部的 dependency，此類攻擊可在不易察覺的情況下傳播到開發環境並潛進產品中。

雖然手動建置過程中存在 dependency 受到危害的風險，但由於自動化 build system 有從外部來源擷取 dependency 的趨勢，使得每次 build system 在新環境中執行時，會增加攻擊者的攻擊機會。攻擊者只需在 dependency 伺服器或 DNS 伺服器擷取 dependency 時造成一次危害，便會危害執行建置的機器。

即使 Castor 在物件上建立鎖定，也無法阻止其他執行緒讀取或寫入該物件。跟預設共享模式比較起來，唯讀查詢的速度大約快了七倍。

範例 1：下列範例指定查詢模式為 SHARED，允許讀取與寫入權限。

results = query.execute(Database.SHARED);

依照預設，Castor 會在共享模式中執行查詢。因為共享模式允許讀取與寫入權限，無法得知該查詢要使用哪一種作業。如果要在唯讀環境中使用該物件，共用存取就會加重額外不必要的效能負荷。

範例 1：下列範例不會指定查詢模式。

results = query.execute();    //missing query mode

ClassLoader manipulation 允許攻擊者存取及修改基本應用程式伺服器設定。在 Tomcat 8 等特定應用程式伺服器上，攻擊者可能改變這些設定來上傳 Web shell 及執行任意指令。

從位元組陣列將資料轉換成 String 時，未指定任何資料超出適用的字元集時將會發生什麼情況。這可導致資料遺失，或是當需要二進位資料來確保遵循正確的安全措施時，這可導致安全等級降低。

範例 1：以下程式碼會將資料轉換成字串以建立雜湊。

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

假設檔案的大小低於 BUFSIZE，只要 myFile 中的資訊編碼方式與預設字元集相同，這就可以正常運作，但是如果使用的是不同的編碼，或是這是二進位檔案，將會遺失資料。這進而會導致產生的 SHA 雜湊較不可靠，並且可能表示，比較容易造成衝突，尤其是以相同的值 (例如問號) 表示超出預設字元集的任何資料時。

藉由呼叫 notify()，無法指定要喚醒哪一項執行緒。

範例 1：在下列程式碼中，notifyJob() 呼叫 notify()。

public synchronized notifyJob() {
flag = true;
notify();
}
...
public synchronized waitForSomething() {
while(!flag) {
    try {
        wait();
    }
    catch (InterruptedException e)
    {
        ...
    }
}
...
}

在此案例中，開發者想要喚醒呼叫 wait() 的執行緒，但 notify() 可能會通知不同的執行緒，而不是預期中的執行緒。