Oracle gave it the big FU, now what?

Prior to coming to JMonkey I had always used and sworn by eclipse, but I decided to start with the bundled SDK so I would have all the additional SDK features, and within a week I forgot I was even using a different IDE :rofl: they all feel the same to me now, but it only made sense to use the SDK as a new user so I could explore all of its cool features

Nowadays I find myself using both JMB and the SDK equally . If I’m working on a lot of files at once in the SDK, then I’ll do the scene editing in JMB so I can stay organized. I like to do certain scene editing tasks in JMB and other in the SDK, and I couldn’t imagine using only one or the other. Plus having a second editor available is an invaluable tool for troubleshooting when you encounter an error in either the SDK or JMB.

3 Likes

I’ve been scrupulously avoiding this topic up to now, but I’d like to second what @nehon said:

If I understand correctly, the “JMonkey SDK” is no longer supported by the core team and is now largely or entirely supported by @Darkchaos. As we all know, JMB is @javasabr’s personal project. My point in bringing this up is that both of these are excellent tools supported by different people who have been generous enough to contribute their hard work back to the community for others to use. As such, the whole “what’s the best IDE-editor-build tool-flyswatter-fill-in-the-blank” debate is moot - if their respective authors want to take a certain approach, that’s up to them to do. They’re doing the work, so they get to choose which direction their projects will take. If one of us sees a piece missing we can contribute patches or build new tools to address the need. If @javasabr wants to build tight integration between JMB and IntelliJ, fine, if @Darkchaos wants to continue to develop the SDK on top of Netbeans, that’s fine too. There’s no point to or need for a big discussion over what’s the “best” tool platform - it really is all a matter of taste, and I think the jME community is fortunate that there are multiple options that take very different directions.

We’re fortunate enough to have options - use what works well for you and don’t worry about the others.

Very true.

12 Likes

The code is here if you want to make some improvements I’ll gladly take PRs GitHub - Nehon/bootmonkey: Project scaffolding for JME3

I have absolutely no hostility towards his project. It’s the opposite even.
Idk if this and the little text below was addressed to me, but since I’m quoted I have to answer.

I invested A LOT of time in the SDK back in the days it was supported by the core team, and to be honest I was very shocked when the team decided to drop its support. Though the reason were sound: We don’t have much time to maintain it in the current state of the team, it hinders the engines release cycle because every change has to be reflected in the SDK, the build was troublesome at this time too, and since people always complain about “why netbeans and not ‘whateverthefuckmyfavoriteIDE’?”, it’d be best to just separate the editor from any IDE and let people use their IDE.
But before we did drop the SDK… we asked the community if someone would step in to support it, in case it could be saved.
No one did.
It’s after 1 or 2 month that Darkchaos arrived and decided to take over the maintenance. So there has been a very bad timing, but life’s a bitch.
Then Javasabr decided to do his own IDE and released it to the community.
To me, both Darkchaos and Javasbr have a lot of merit and we should support them.

I’m not an old geezer in his attic thinking “noobs should learn the hard way as I did”. I’d be thrilled to have an official editor for JME, full of fantastic features, but official mean maintained by the core team, and I don’t have time for this. I tried though, I have an editor based on SPIX that was mentioned above, and I work on it from time to time. But to be honest, I think I will never release it, because it would mean maintaining it and answer to troubleshooting, and I don’t have time… I’d rather focus on the engine.
So… we want an IDE with wonderful features? We have 2 of them. Each of them using a different approach, why are we complaining?
I guess people don’t like to be given a choice…

9 Likes

no no, I just recommend to use IntelliJ IDEA as java IDE, but you can use jMB with any IDE/Text Editor :slight_smile:

2 Likes

I like unity 3d editor as 3d editor, I want to have the same tool for my favorite engine :slight_smile:

3 Likes

My mistake - I misremembered something you or someone else said earlier in the topic.

Well, for larger teams you’re probably right. But from my own experience, when you’re working on a small scale project (e.g. 1-3 people), I’ve found small in-engine tools quite efficient. Let’s say you’re working on a shooter game where a level consists of a terrain and some objects on it, it’s pretty simple to code some kind of “dev tools interface” and a free-flight mode (something like “no clip” mode in Quake), where a level designer can seemlesly switch between gameplay and editing and modifiy the terrain and objects directly. No import pipelines, direct gameplay experience feedback, 100% WYSIWYG. And for assets JME already supports a lot through blend-files and the various image formats.

But that doesn’t mean I wouldn’t support anybody working on more general tools like scene editors! In fact I like coding tools myself too :smiley:

Yeah If I remember correctly even John Carmack was quite impressed by his coding skills back in the shareware days. The awesome tools for Commander Keen, Doom, etc. that he wrote really helped to accel the games development. Here is an interesting read about Romero and his tools.

4 Likes

I really like the SDK! So much good shit in there. Thank you for all your hard work on it <3

11 Likes

No.

Its not addressed to anyone in particular,

just making a point about how people may be overestimating NetBenans longevity with what’s happening, underestimating the impact this may have on its integration development with JME and why people may refuse to move onto doing things a little different for longer than they should.

I like the SDKs NetBeans integration. It was a major factor in my decision of choosing JME as my engine of choice. NetBeans is the only editor I have ever used for java. I hope it never goes away. It may become more user friendly for integration with JME now Apache has it, if it doesn’t, that will be its demise. If you cant draw in more contributors to the SDK, over time it will fade away.

1 Like

ok ok

Well actually the SDK has never been as ailve as it is today at least, since the days when Normen was maintaining it

2 Likes

Thanks for sharing - that’s a GREAT read! Putting that one in my permanent bookmarks.

1 Like

People get angry about any thing that did not suite their way and feelings…

Or I can say: “Try unity, it’s better than jME in every aspect you can possible think of and get your job done instead of waiting for others to write you some pieces of software for free…”

I use Unity every day and hack in jME every night for 6 years. Same with Netbean and Eclipse, Sublime Text and Visual Studio together and I don’t think I should blame any one or have bad experience in any of those. Because they are just tools…

About Unity/JME or Netbean/IJ IDEA both sides (team, community, contributor) have learn from each other some thing…

Unity guys are trying to open source some parts of them to get the “force” of opensource to drive some innovation and also rely in developer of asset packages to solve problems they don’t want to get their hands dirty on.
IDEA try to get more people improve and make plugins so “more is more for every one”.

Last line: I don’t think Netbean will be die any time soon because of backed by Apache … but now is a new era. It was good and still really good as 2018. It’s not as buggy or crash as many times as any IDE i have used in my career. The Netbean community is also very strong! The problem is the business model that push talent people away from the “good side”… I don’t and never want that to happen to this community in any way in the future, … but the life is cruel some how

1 Like

Hey Atomixnmc,

Glad to hear from you.

I will be zipping up and moving all your docs in the wiki soon. They will be stored in the GitHub - jMonkeyEngine/doc-examples: The JME project where to find all the documentation code examples repository under atomix as a courtesy.

They were responsible for over a hundred build errors in the wiki logs, mostly out of order headings like going from == to ==== for example. So I fixed em for you.

If you want to create your own wiki or contributions repo for them I can add a link to it.

1 Like

Yes, sorry about my tutorials errors because I’m not around when the migration happen. I started my own company 2 years ago and there go my free time. I still do open source but not too much time left for jME and the community. I still visit the forum sometime and will revive my articles and code whenever it fit.

Thanks,

2 Likes

NP, They will be there for you.

Sounds like a good idea. I would do that myself if a) I had enought time -and- b) my voice wouldn’t sound so terrible. My videos would use pop-up text or subtitles instead to transport the information, but that’s not cool enough for the kids out there. And also … I prefer (searchable) text like in a wiki or eBook, but I know that many people prefer videos today.

Thought I would add something new to this subject that Oracle didn’t take into account and something that I have found to be very frustrating.

With the 6 month life expectancy for each new java version Oracle has now destroyed the book market for java.

There was a normal flow of about two years between book releases for java that has now stopped. You cant release a book, recover the expenses and make a profit if the subject matter is no longer viable every 6 months.

They went from java 8 to pre-release of 12 in two years. No publisher will touch that.

2 Likes

This is also at a time when many people who would normally buy books can find the information they need online pretty easily. These days I’m already on the fence about buying language-related books because of that. (I bought Groovy books and then only read one specific chapter.)

I also wonder what this does to the certification industry.

1 Like

Professionally what people seem to be doing is ignore the non-LTS versions (it’s what I do for real work), so Java 11 is the “real” latest. Unless you really need something in the newer versions, there isn’t much reason to care about the 6 month versions. It’s all publishers should care about too.

I’d like to know what made them decide on 6 months specifically. I mean who exactly was filling their inbox demanding that? Because I’m pretty sure it wasn’t their customers.

Hey it’s cool to be a constantly changing mess now, let’s forget that our enterprise customer requirements are pretty much the opposite so we can pretend that we’re Google. Look how fast our version number goes up! That’ll get the kids to switch back to Java!

1 Like

My 2 cents: absolutely nothing in term of business practice. Certifications will continue to be sought and bought.

The real value of certification is plummeting, but it is an irrelevant detail.

1 Like