I have a question. How do you deal with resource protection?
I thought of the following:
The question is always how much effort do you want adding inconvenience.
Itâs impossible to 100% protect assets⌠so then you just have to decide how much is âenoughâ.
For most, j3o is probably enough. Especially if you have custom controls, the effort to read the j3o is not too far away from the effort to load your game in a JVM and extract the data from RAM.
I think , even with java you cannot access the files inside the zip without using ZipStreams ( i have gone through on android, it was not even encrypted) which extracts the zip file before doing anything , so for encrypting zipping will be the best choice if you have paid assets but also there would be possible performance issue & increased loading time , though you need to pack them again after the game finishes but if the game is actually not responding , your files are endangered because your project as decrypted them 
,
So , I donot really know if you can attach your assets to an asset pack git private project & do runtimeOnly 'project:assets3.2' I didnât try this , but I know that , some IDEs like IDEA can extract your libraries in a form of jar files (artifiacts) , should you try this & report ?
EDIT if you are building a game on android studio then you can use the Play ASSET Delivery API ( obb files) , that will do everything for you.
@Pavl_G but Jar can be just opened using zip.
Generally like Paul said, its impossible to 100% protect.
But what worth, would be customize j3o format yourself or customize VM(provided along with game) to do some hidden things. It would be high protect imo.
From a desktop focus:
Raw on disk: anyone can access it
In a zip: anyone can access it
In a jar: anyone that knows a jar is a zip can access it
In a j3o: only folks who know what a j3o is and how to access that in a JME application can access it. (A significantly smaller set of people than the above.)
Rename extension to .foo but itâs still a .j3o: only highly motivated folks who bother to look deeply enough to figure out that it is the same can access it.
âŚnow we are already in the realm of âJME developerâ level person.
.j3o/.foo with custom control: only a JME developer who knows how to link in your .jars into their custom app can access your assets
literally any other protection you can think of short of decription in the shader: a JME developer who knows how to run your application within their application and/or hook into your application (add a key mapping in input manager for example) can access and dump anything they want. (And note that decryption in the shader is only a âtakes a little longer to figure outâ style stumbling block)
How much effort do you want to expend to work towards diminishing returns. Already a j3o cuts out most of the worldâs population.
@Pavl_G @pspeed @oxplay2 Thank you everyone. These suggestions are helpful to me. I think I might write a custom Loader to load resources to protect resources. 
Yeah, if itâs a desktop application that will add at least 30 minutes to the time it takes to get the resources out of the app⌠for a very motivated person.
I remembered now my old development days , I was using windows & wrapping jar files to .exe with launch4j , but I thought now , what if you can do this with encrypted or encoded exe instead , I donot know really if something like that exists (it would be the same as running .sh with restricted permissions) ,
See ( I found they have encrypted jar for exes):
EDIT : Back in 2018 , I have coded an Electronic Test project , it was in swing , I was training on data hiding , AES , cryptography & java File IOs , so , in the password file , I encrypted it using AES but it was plain txt file , other data are hidden by a powershell script & changed the folder names to something like .~name when my java code is not using it , i remember this cannot be opened by the windows file manager , also you have the opportunity to work around for a powershell script to overcome this part by some permissions , but it can be opened in Linux .
Thanks for sharing!
I thought the whole purpose of java modules was to give you the control of what is viewable from a user aspect?
If its not a public class in a public module wouldnât it be unusable by others trying to hack?
Strong encapsulationâThe packages in a module are accessible to other modules only if the module explicitly exports them. Even then, another module cannot use those packages unless it explicitly states that it requires the other moduleâs capabilities. This improves platform security because fewer classes are accessible to potential attackers. You may find that considering modularity helps you come up with cleaner, more logical designs.
I suppose we talk about âresource encryptionâ not code and anyway accessibility have nothing to do with it.
but its still JVM that manage it right?
if someone would modify JVM he would still be able to access.
But again its same, nothing can be 100% protected, even Windows source once was back-step gathered as i heard.
My bad.
I return you to your regular programming.
i feel like i did something bad 
guess we can continue code security topic here too, just mentioned that OP post was just about resources.
No, thatâs not quite the case⌠if you have modular code and youâre running your JVM with the standard module options, then yes, you can do some code hiding (though I look at this as more of a software design benefit than a security benefit - if someone untrusted is able to execute code unsandboxed in-process with your code youâre already in trouble). When someone else is running the JVM, itâs easy to bypass module protections and open up whatever you want to.