If we look into [the source code of the JDK 11](http://hg.openjdk.java.net/jdk/jdk11/file/e429a304c97d/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java) where this feature was introduced, we can see it is based on RFC 7539, not on RFC 8439. However, a quick look showed that they may be compatible none-the-less.

 - although the Poly1305 MAC is defined using AES, the AEAD cipher is not;
 - the AEAD construction is defined in section 2.8 and points to [2.6: Generating the Poly1305 Key Using ChaCha20](https://tools.ietf.org/html/rfc8439#section-2.6). 

So the nonce is taken directly as parameter, and it is not generated by the application *at all*. However, the Poly1305 *key* is generated from this nonce. Note that a MAC does not require an IV or nonce otherwise, only a key. For Poly1305 that key needs to be unique, which is why it is *calculated* from the nonce used by the ChaCha20-Poly1305 AEAD cipher.

---

So the authentication tag is protected using a ChaCha20 block encrypt rather than AES:

        authenticator = new Poly1305();

        // Derive the Poly1305 key from the starting state
        byte[] serializedKey = new byte[KEYSTREAM_SIZE];
        chaCha20Block(startState, 0, serializedKey);

        authenticator.engineInit(new SecretKeySpec(serializedKey, 0, 32,
                authAlgName), null);

In other words, the [`ChaCha20Cipher`](http://hg.openjdk.java.net/jdk/jdk11/file/e429a304c97d/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java) class which implements the  ChaCha20-Poly1305 AEAD cipher (using the [`Poly1305`](http://hg.openjdk.java.net/jdk/jdk11/file/e429a304c97d/src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java) authenticator class) doesn't mention or reference the AES or any other block cipher.

---

Note that I've previously mentioned in a deleted answer that stream ciphers can generally not be used to perform this kind of key derivation from the nonce. This is correct; however, ChaCha20 operates on blocks underneath, which makes these kind of operation possible none-the-less.

What was correct in the deleted answer is that the block encrypt for creating the key for Poly1305 is performed *only once*, so any speed difference between block ciphers to derive the key is inconsequential for larger messages. Only the Poly1305 calculation is performed over the whole message - that's the whole idea of these fast MAC implementations that enable ["1.5 pass authenticated ciphers"](https://crypto.stackexchange.com/questions/46595/what-is-meant-by-a-1-5-pass-cipher).