First of all, you are Doing It Wrong™. There is something fundamentally wrong with the way you are trying to go about this. Your software will be better off if you try to understand the normal unix security and permissions model and work WITH it instead of fighting/breaking it.
The only way I can think of to do what you want without blowing a thousand holes in the file system permissions is to set the folder in question up with a group and group-based permissions, then mount it somewhere else using a bind-mount so that it can be accessed by a user-accessible path instead of inside /root. The data can stay there, but non root users shouldn't be able to stick their head in there, so it needs a handle elsewhere in the file system. You can't symlink to it beccause that will just route you back through /root, but a bind mount setup ahead of time by root should provide an alternate path that it can be reached by as a non-root user.
Edit: In the case clarified in comments of having an application with a hard coded path, none of the things I or Alkdae suggest will actually work. As a temporary work around, I suggest making sure anything in root that is sensitive such as
/root/.ssh is owned as
root:root and marked as
0600 or other such restrictive permissions. Then move anything in
/root that doesn't need to be there into a subfolder such as
/root/root_files and make sure that is
root:root 0600 too. Once you are sure there is nothing there to be seen or exploited, set the group ownership on
/root to some special group like temproot and set it to be browsable by that group (but NOT world or the normal users group!). Then add your special users to that group, and set the files in
/root used by that java app as owned by
root:temproot with group write/execute permissions as appropriate.
As soon as you can fix the offending java app, chown everything in root back to