For 3DES using PKCS5Padding the encrypted length for N hex characters is calculated along the lines of
1) Converting the cleartext characters to bytes. Since you decode the Hex cleartext characters using utf-8 and don't Hex decode them your N hex characters will convert to N bytes and not N/2. For your example this will be 16 bytes.
2) The PKCS5Padding will add between 1 and 8 padding bytes so the cleartext length after padding will be ((N+8)/8)*8 bytes (integer division that ignores the remainder). For your example this will result in 24 bytes.
3) The ciphertext length will be the same as the padded cleartext length i.e. ((N+8)/8)*8 bytes.
4) Hex encoding of the raw ciphertext will produce 2 characters for every one byte of ciphertext so you will end up with 2*((N+8)/8)*8 characters. For your 16 hex character cleartext example this will result in 48 characters.
It seems to me that before encrypting you should first hex decode the hex bytes of the cleartext. This will then result in just 32 Hex characters of ciphertext.
You can get a further saving if you Base64 encode the ciphertext rather than Hex encode it and an even bigger saving use ASCII85 encoding.
Note - it is normally better to leave ciphertext as bytes and not turn them into text at all. Do not even think about just converting them to a
String without some form of encoding; String is not a suitable container for binary data and raw ciphertext is most definitely binary data.
Note 1 - you use a fixed IV of 8 zero bytes. This has security implications since it allows an observer to tell whether or not two ciphertext have the same first 8 bytes of cleartext. To get round this it is normal to use a random IV and either include the IV as a prefix to the ciphertext or store it separately.