I was noticing that there is some significant documentation for Nifty on the Wiki, but Nifty appears to be effectively dead and JME should start purging references to it.
4 Likes
Nifty works just fine. I don’t think there is reason to purge it. It is still part of jME. One could argue that same goes to LWJGL 2, jBullet, etc. All existing options should be presented in the wiki. As well as current recommendations what to choose.
1 Like
While it is true that nifty “works”; if people have issue with it and ask for help they will find people immediately tell them to stop using it and migrate to something else. I would agree that if should at least be deemphasised. No more prominent than lemur or other gui options
And given recent Unity “issues” it wouldnt suprise me if we get a bunch of new users, so now is probably a good time to streamline things
1 Like
This is problem with many things… People have strong opinions. The wiki also tells to build a game using scene graph as game objects and all that. Same hell breaks loose if one asks help with that 
So maybe we need to take a look at the bigger picture and modify the wiki so that it most accurately presents the views of the majority (of core…ish…? people). To avoid this frustrating phase where you finally managed to get your first project somewhat up and running… come to the forums to ask help and you’ll get help yes, but the help says to start over with different library / approach. This is very discouraging.
If we all think that LWJGL 3, Minie, Lemur and ECS (and Gradle!!) are the building blocks of any game and everything else is just wrong. Then we definitely need to communicate that to the people, in the wiki, before they start this exciting journey…
To add a bit to this. In my understanding, many, like Unity, also encourages the wrong architecture/way to build your game. They teach the easy way first. One gets the impression that this is really productive and all that. But in the end, not that manageable or clever way. I do get this hook, it is clever.
Same in jME, using scene graph as game objects and XML to build your GUI. Fast and impressive. Also encouraged path by the SDK scene editor. ECS can be a mouthful and stop one’s journey before it even started. I mean… a bit balancing act. I guess we need to really think what we want to portray, what is it like to develop games with jME…
10 Likes
It is too foolish for Unity3D to charge by installation counts. I suggest it charges by frame rendering counts instead. 
1 Like
I completely agree with your point of view. Beginners should quickly experience the simple part of JME first, so they are motivated to move on to the next step, instead of importing jar libraries from scratch, generating geometry in code, creating GUI in code etc. from the very beginning. It’s easy for beginners to get lost in a simple helloworld and eventually give up using JME.
I have no opinion about Nifty in particular, but some considerations for “purging” documentation:
JME already suffers from a lot of 404 search results and the like.
People have to maintain existing code etc.
At most a note should be added with a link to new recommended content.
Nothing should be removed or moved imho.
Ideally all URLs should stay valid and all content accessible.
The comment by rnk about 404 issues makes a lot of sense.
At their very least, a prominent warning should be added to the Nifty pages to discourage new developers from going down that path. The imminent EOL for Java 11 should have us looking at any code that hasn’t been meaningfully updated in the last few years.
Beware of blindly following this mantra. Some libraries are not updated only because all of the meaningful bugs have been fixed and they are otherwise feature complete.
It’s a conversation that makes me chuckle sometimes:
“Library foo hasn’t been updated in 8 years!!!”
“Well, is there anything wrong with it?”
“No”
“Is it working fine?”
“Yes”
“Then what updates would you suggest?”
It means we have to purposely leave some number of bugs in so that the library can be fixed periodically for no reason other than to make sure it “was updated recently”.
3 Likes
Maybe there is something I don’t understand about this. What exactly is the correlation between the two? What I’m supposed to fear?
In general, and maybe in this scenario where my project is already using Java 21 but its dependencies not so much. So what happens?
1 Like
Fair warning: My day job is as a NASA contractor, and so I have a different outlook on software from people in the gaming industry. Also, we have software that has been running literally for decades so, again, different outlook.
Things change. Code that works perfectly under a given version of Java does not necessarily work perfectly under a newer version of Java. That doesn’t mean that a given piece of code will suddenly break, but on the other hand, it isn’t impossible.
So, taking pspeed’s example, if all the bugs have been eliminated from a library, that’s great - Mazeltov! But that doesn’t mean that the library shouldn’t be tested with each new LTS Java release, even if the only update needed is to update the Read Me to indicate “Yep, we tested it with Java 17 and it still works perfectly.”
3 Likes
Its still not just about Java, there are a lot of JVM doing things differently, thats why here people like bundle default JVM with game itself, so it work same.
Not mention WEB version that use Java code translated into Javascript code.
1 Like
In my experience this is almost never true.
3 Likes
I would agree with the issues Nifty has and it was one of the main reasons the project was abandoned. However, It is still a usefull tool since you can design the UI with xml.
I think we should remove Nifty once we have a full replacement even in design of the UI without code.
There are always new deprecations in the JDK, take Object#finialize() as a naive example, those deprecations will not be in our sight if we are still relying on JDK-8, I think that what @AceMcCloud is talking about, the internal JDK changes that change the way people implements the code.
finalize() has been effectively deprecated since at least 1.2… which just goes to show how long something can exist in the JDK even when deprecated.
It’s a real testament to Java that in 25 years, I can count on one hand the number of ways a JDK upgrade broke my existing code.
Yes, it happens. Often enough to really worry about? Not really.
3 Likes
Anyway, jme3-nifty is already built using JDK-17, so far no serious project warnings have been generated, so it’s okay, the very good thing about the Java compiler is that it’s verbose to deprecations and code changes.
2 Likes
Perhaps fully killing nifty is not the answer (for the reasons listed here) but perhaps less controversially how about demoting it. So it’s listed alongside the other options. Not in a privileged place that implies it’s the best option
2 Likes