I think the default strategy for a sandboxed java in this environment would be to restrict network access completely. But there's an important reason why it's better to restrict network access and whitelist some local ports:
Interprocess communication: It would be possible to communicate with other processes like using named pipes already available in A2 (or the extension mechanism). The problem is, that it's not possible to create a named-pipe using java (although read/write works).
This would lead to a number of possible implementations:
- Relay data from local to a server via a small relay program on the clients pc: local port -> redirect to server on a network
- Log server scripts and help server admins by providing a remote commandline where commands are executed on the arma server
- Client helpers: GPS on second screen, Client statistics like driven distance
- More advanced addons: Imagine a mod which introduces a combat interface which can be used to transmit spotted enemys positions to your platoon lead: The interface now can run on the second screen of the client without interfere the combat awareness.
Sadly there's no java support right now, but i guess it's better to provide these requests now than later.