Add intergalactic transmission

[jagdish-15]

pull request

closes #2967

---

Reviewer Resources:

Track Policies

[jagdish-15]

@kahgoh, let me know if there are any changes you'd like me to make! Also, could you please advise on the appropriate difficulty level to set for this exercise?

[kahgoh]

The difficulty can be subjective at times 😅. The easiest is using the same as other tracks (6 on C#, Vlang and x86-64 assembly).

Not so much a change, but a question - I noticed the data is given as List<Integer>, although the story and instruction talks in terms of bytes. I was wondering if you considered using Java's byte instead (e.g. List<Byte>)?

[jagdish-15]

The difficulty can be subjective at times 😅. The easiest is using the same as other tracks (6 on C#, Vlang and x86-64 assembly).

Sure, I'll make the change!

Not so much a change, but a question - I noticed the data is given as List<Integer>, although the story and instruction talks in terms of bytes. I was wondering if you considered using Java's byte instead (e.g. List<Byte>)?

Actually, since List.of() infers types based on the arguments, we'd need to cast each element to byte for it to work with List<Byte>. So the current implementation List<Integer> expected = List.of(0x03, 0x00); would have to be updated to List<Byte> expected = List.of((byte) 0x03, (byte) 0x00);.
Do you know any workaround for this?

[kahgoh]

Try using Arrays.asList (e.g. List<Byte> theList = Arrays.asList(new Byte[]{0x01, 0x03});).

Alternatively, it might be easier to use a byte array (e.g. byte[] data = new byte[]{0x01, 0x02}) directly instead of a list and using byte array for binary data is common in Java.

[jagdish-15]

In Java, byte is signed by default (unlike C#), which means it only supports values from -128 to 127. So for any value above 127 (i.e. from 0x80 to 0xFF), we must explicitly cast it using (byte), and it's stored in 2's complement form.

Manually figuring out and casting each of these values can become tedious and error-prone, especially when writing long byte arrays in tests or encoding logic.

Is there a cleaner or more efficient way to handle such inputs?