The default Java Graphics instance does have a translate method.
Basically all you would do is translate by the camera position, then translate back (negative camera position) to render UI stuff. This way you don’t have to pass in camera coordinates for each renderable.
Update:
Managed to get translate working, but couldn’t figure out a way to update co-ords for interacting with the level once it had been translated.
I have now resorted back to trying to figure out a way of doing this via changing the for loops in render and tick inside level to somehow render tiles based on camera co-ords.
I haven’t managed to get any of this working yet! 
Gyfcat: https://gfycat.com/GregariousIllinformedBonobo
Gist: https://gist.github.com/AndreasElia/bf9c714923873f7266e5
OK, what isn’t working? I don’t actually understand what’s going on in that gif. If I do understand it correctly it looks like the “player” is moving and then snapping back to the start location. Which means there’s something wrong elsewhere in your code.
OFF TOPIC: Your getTile() method is bad, if it returns null the render method will still crash, it would be better to have something like a renderTile() method that would render the tile if it existed.
Hey! Sorry I forgot to update this post, but managed to get this working the way I wanted to without using translate(). Instead, I have a custom class named Camera that extends Rectangle. All entities, tiles and anything else that moves with the camera extend the Camera class. This means I can move everything at once since they all extend the same class. To make everything move, I have a “moveWith()” method in the Camera class that needs to be called before the tick of whatever needs moving.
On top of that, the game never ticks or renders off-screen tiles unless there’s a specific boolean set in the tile (setUpdatesAlways(true);). This gives a HUGE improvement, and as I am not interacting with off-screen tiles, I can generate a near infinite world (if I didn’t simply manually generate the level array, since this crashes and FPS drops somewhere after 13 million tiles).
You can even do better by laying-out/clustering the small tiles into big tiles (say 64x64) and render visible “big tiles” only once into a BufferedImage (or even a VolatileImage) when they become visible, instead of rendering the small tiles every frame.
Then you only need to blit/draw the BufferedImages of the (at most) 4 visible big tiles.
This will give another heavy performance boost.
The issue I see with that is that the player can interact with tiles, e.g. replace one tile with another tile of a different type. Having the tiles be clumped into a BufferedImage would require the stored image to be reset. Not sure how much of a hit re-creating the BufferedImage would be. Thanks for the suggestion.
Yes, I figured. That does not change anything to the solution. 
First: You don’t have to “recreate” the BufferedImage, if by that you mean: Instantiating a new one. You simply have to rerender its content.
But you would rerender everything anyways without using a BufferedImage (you rerender onto the Canvas/Panel/Component every frame then). So think of your Component as being a BufferedImage that loses/invalidates its content every frame.
Then using a BufferedImage is always a performance win, as long as the user does not alter a tile every frame (possibly 60 times a second).
Oh, I see now! Thanks again, I love squeezing out as much performance as possible.