running game project in the SDK sometimes gets more time about 2-3 minutes.
This note is shown in the Netbeans IDE output section: Note: class ro.fortsoft.pf4j.processor.ExtensionAnnotationProcessor init
Recently I started to use SDK 3.3.2, and I also encountered the same problem. What caused this? @yn97@Pavl_G
I have found the reason why the operation will be delayed. It seems that SDKv3.3.2-stable does not install the nb-javac plug-in by default. Maybe it is because SDKv3.3.2 is not a released version, so this plug-in is not installed by default. After installing this plug-in, when you open the save Compile and run quickly.
Does this happens on each run or the first time only , I see you saying sometimes but when exactly , because there are libraries when included they extend the compile time !
I used the sdk3.3.0-beta1 version before, it did not have this situation. Then I installed sdk3.3.2 a few days ago and there was a configuration confusion, and then I solved it, but when I use sdk3.3.2, it takes 2-3 minutes to run a project, and occasionally it will be faster. This is very strange, there is no such situation in sdk 3.2.4.
Another problem is that I configured the sdk startup memory in etc/.conf, but it does not seem to work, but these configurations can work in sdk 3.2.4, as follows:
I configured the .conf file, but when using SDK 3.3.2, when the memory reaches 300m, an error will be reported and the cache will leak directly.
Is it weird to configure the .conf file like this? Why it doesn’t work. These configurations are available in SDK 3.2.4.
From my experience… You shouldn’t need to configure anything anymore. NB 12 / SDK 3.3 will use the memory pretty ok. For me it starts with 3GB reserve. If you really need to, remember that Google with Netbeans 12 info.
It should ask to install the nb-javac on the first run. It is recommended to be installed.
Some points maybe still apply but that actually covers SDK 3.2 and older. But for 3.3 things maybe very different. The antivirus scans are maybe a valid point…? That at least destroys all performance for me at work. And typically I place the blame on Visual Studio…
I actually tried the possible methods, but I still get a direct cache error when I use SDK 3.3.2.
The maximum memory here can only reach about 300m. My computer has 8G memory. I don’t understand why I can’t configure effective startup memory in etc/.conf.
I think the SDK was using the JDK we bundle there, an oldish Java 11 SDK. You could try to get the latest Java SDK (AdoptOpenJDK) and set the SDK to use that. That’ll be in the conf file you already found. See if it makes any difference.
The about box tells you what Java version the SDK is using.
Just checked this morning, on Linux I seem to use the bundled Java JDK 11.0.6. And on Windows I use my manually installed 11.0.9. Both do work for me. Without any memory tweaking.
What kind of error you get when you run out of memory?
java.lang.OutOfMemoryError: Direct buffer memory
at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:118)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
at com.jme3.util.ReflectionAllocator.allocate(ReflectionAllocator.java:178)
at com.jme3.util.BufferUtils.createByteBuffer(BufferUtils.java:989)
at com.jme3.texture.plugins.AWTLoader.load(AWTLoader.java:121)
at com.jme3.texture.plugins.AWTLoader.load(AWTLoader.java:183)
at com.jme3.texture.plugins.AWTLoader.load(AWTLoader.java:192)
at com.jme3.asset.DesktopAssetManager.loadLocatedAsset(DesktopAssetManager.java:260)
at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:374)
at com.jme3.asset.DesktopAssetManager.loadTexture(DesktopAssetManager.java:391)
at com.jme3.texture.Texture.read(Texture.java:617)
at com.jme3.texture.Texture2D.read(Texture2D.java:215)
at com.jme3.export.binary.BinaryImporter.readObject(BinaryImporter.java:342)
at com.jme3.export.binary.BinaryInputCapsule.readSavable(BinaryInputCapsule.java:457)
at com.jme3.material.MatParam.read(MatParam.java:374)
at com.jme3.material.MatParamTexture.read(MatParamTexture.java:104)
at com.jme3.export.binary.BinaryImporter.readObject(BinaryImporter.java:342)
at com.jme3.export.binary.BinaryInputCapsule.resolveIDs(BinaryInputCapsule.java:483)
at com.jme3.export.binary.BinaryInputCapsule.readStringSavableMap(BinaryInputCapsule.java:667)
at com.jme3.material.Material.read(Material.java:1069)
at com.jme3.export.binary.BinaryImporter.readObject(BinaryImporter.java:342)
at com.jme3.export.binary.BinaryInputCapsule.readSavable(BinaryInputCapsule.java:457)
at com.jme3.scene.Geometry.read(Geometry.java:727)
at com.jme3.export.binary.BinaryImporter.readObject(BinaryImporter.java:342)
at com.jme3.export.binary.BinaryInputCapsule.resolveIDs(BinaryInputCapsule.java:483)
at com.jme3.export.binary.BinaryInputCapsule.readSavableArray(BinaryInputCapsule.java:471)
at com.jme3.export.binary.BinaryInputCapsule.readSavableArrayList(BinaryInputCapsule.java:587)
at com.jme3.scene.Node.read(Node.java:748)
at com.jme3.export.binary.BinaryImporter.readObject(BinaryImporter.java:342)
at com.jme3.export.binary.BinaryInputCapsule.resolveIDs(BinaryInputCapsule.java:483)
at com.jme3.export.binary.BinaryInputCapsule.readSavableArray(BinaryInputCapsule.java:471)
at com.jme3.export.binary.BinaryInputCapsule.readSavableArrayList(BinaryInputCapsule.java:587)
at com.jme3.scene.Node.read(Node.java:748)
at com.jme3.export.binary.BinaryImporter.readObject(BinaryImporter.java:342)
at com.jme3.export.binary.BinaryImporter.load(BinaryImporter.java:242)
at com.jme3.export.binary.BinaryImporter.load(BinaryImporter.java:125)
at com.jme3.export.binary.BinaryImporter.load(BinaryImporter.java:109)
at com.jme3.export.binary.BinaryLoader.load(BinaryLoader.java:36)
at com.jme3.asset.DesktopAssetManager.loadLocatedAsset(DesktopAssetManager.java:260)
at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:374)
at com.jme3.asset.DesktopAssetManager.loadModel(DesktopAssetManager.java:417)
at com.jme3.gde.core.assets.SpatialAssetDataObject.loadAsset(SpatialAssetDataObject.java:94)
at com.jme3.gde.scenecomposer.OpenSceneComposer$1.run(OpenSceneComposer.java:37)
at java.base/java.lang.Thread.run(Thread.java:834)
Your symptoms match what happens on a 32 bit OS if you try to configure more than 1 gig of RAM on the Java command line. (silently falls back to default values)
I am running on win10 64 bit, and I have configured -JXms1024m -JXmx2048m in etc/.conf file. This problem occurs when opening some slightly larger models (such as models containing dozens of 4K resolution textures).
Do I need to configure higher memory?
The more recent JVMs assume -Xmx to be 1/4th of the System Memory, but those are the default Run Args the SDK is placing in said config file:
-J-Xmx512m -J-XX\:MaxDirectMemorySize\=2048m
Given what I said above, we can probably lift/remove that Xmx of 512, but like older jre’s were using 128 or 256m and also note how we increased the direct memory for exactly the texture cases.
Did you configure -J-Xms1024m or without the second hyphen?
It is not installed but it should ask you on the first launch. We need to see if we can add that plugin, however others on the hub specifically advocate against compile on save.