Please don't. JRE (and plugins) is a huge annoyance for users. You may want to look into JS and the HTML5 canvas instead. There's plenty of material available for that. Just google HTML5 game development and see what comes up.
Let me analogize this: You're suddenly asking if it's possible to make a car more efficient by removing the wheels.
You can play around with the loop, but there's no reason to. It's already possible to surpass human limitations for responsiveness. If you're handling input sanely and your frame rate is high enough that the player can see what's happening then the only really good way to screw up responsiveness is to render several frames behind or possibly to just have a crappy control layout. Control issues are usually related to poor game design or implementation issues with things like colliders not matching models or sprites. Networking tricks can also cause trouble if they're implemented incorrectly, but these are all cases where the output is not correctly representing the game state rather than cases where the rendering or input is not being handled fast enough.
At 60 FPS the game is presenting you information every 16ms or so.
Even if you float a frame (so that the CPU and GPU can work better in tandem) you only lose a little temporal fidelity. Stretching beyond one frame becomes a timing issue, but 0.016 seconds is barely even detectable, especially for fast moving objects.
Moreover, you're talking about a 3-stage process that loops. Your options are limited here:
But then when you consider that they're looping:
ABC == BCA == CAB
ACB == CBA == BAC
You've only got two options. Treating rendering as the divider you have input-update or update-input.
If you're polling then default to polling before updating because it makes sense to respond to input when you have it. If you're on an architecture that will delay on polling then you may consider moving it to after updating depending on how much time your GPU is taking compared to how much time the CPU takes.
On the other hand, if your input is handled by something similar to messaging then you don't even have to mess with it as updating includes processing queued inputs.
Regardless, even if you poll in the 'wrong' order you shouldn't be able to detect the difference without instrumentation.
tl;dr - If you want your game to feel responsive focus on precise collision and well designed character reactions instead.