JME Post-Java-8 Modular Design

JME shouldn’t need to deal with this near term. I started this topic to avoid derailing the Next Release thread.

@tlf30 What’s the issue you see with simultaneous JDK 8 support + modules? New API required?

(Side note, can we really assume there’s going to be public API alternatives for every reflective warning/error? I seriously doubt that’s a safe assumption. :frowning:)

Have any decisions been made on how far JME should even take modular design? I can see each sub-project becoming a module, the entire engine could be one big module, or anything in between.

I can imagine some benefit JME might get from the ability to lock down use of certain internal-use-only packages… if done carefully. But JME also doesn’t have to adopt a full blown modular design with dozens of modules. There’s a number of pros/cons to going full-modular.

2 Likes

From everything I’ve read, whenever this has been brought up, it’s something that will likely be apart of jme4+. Everyone currently running jme3 isn’t jumping to try and upgrade, java 8 does pretty much everything jme3 requires. That said it would be neat to start talking 4.0. I’m trying to get more involved since I finally have a firm enough grasp on programming that I feel I can start contributing.

If/when we do start talking java 9+ and modules, I personally would like to see modules broken into similar chunks as the sub-projects are now. Theres enough granularity there to cut down on engine size without having to many dependencies to add.

2 Likes

The thought did occur to me. I thought we decided 4 was to be Vulkan support (kidding really). :stuck_out_tongue:

There could be significant refactoring involved if things were to be made fully modular, if it’s to be fully taken advantage of. But this is assuming consensus is that it’s even worth doing. If it is, sub-project = module seems like a logical starting place.

1 Like

One Question is the gain: saving 2MiB Diskspace for a 80GiB Game would be useless. With the subprojects we already have some granularity though modules would also involve rechecking all the assumptions (e.g. jme3-plugins)

2 Likes

Benefit should be a bit more than that for our purposes here, but probably not much. Off the top of my head…

  • Protection/encapsulation of “for internal use only” packages (this is controversial IMO, but I’m unaware of how big a problem this has been for JME historically)
  • Faster startup
  • Faster builds

Maybe more… those things alone aren’t so exciting though.

I don’t have a strong opinion on whether it’s even worth going further than ensuring that breaking changes are addressed (this is what I lean towards). But I am curious on tlf’s viewpoint here since he seems to be on the bleeding edge of this topic. :slight_smile:

None that I’m aware of.

Not sure how this can be true.

To me it comes down to level of effort. Lower level of effort = more likely to get done. Mix with current commitments from the community and it’s probably a choice between being really simple and done and “anything more complicated” and not done.

So probably each separate jar as a module? I don’t know.

A little annoyed with myself as I’m not sure where I recall where I’ve seen anything about build optimization specifically, so I probably conflated that one with JVM startup optimization (which I’ve definitely read). That’s what I get for going on memory and not double checking. :roll_eyes:

But yes it’s sounding like the goal would be to just keep things running past 13+.

Sorry guys, I’m currently up at work in the artic circle. When I get back I will join in this conversation here. I have a plan already for how to do this in JME4.

3 Likes

@louhy I am back home. Finally getting settled back in for a little bit.

So the next big support level for the JDK will probably have to be JDK11 as it is the next long term release after jdk8.
There will be a LOT of problems attempting to fully support JDK11 at the same time as JDK8. We have already seen this just getting jme3 to work with jdk11.

I think the best approach is do full support for JDK 11 in JME 4. At the same time it would be best to cut JDK 8 support. For people that absolutely require JDK 8 support they will still have jme3, but it probably wont get updated anymore.

With the migration to JME 4 it will be a good opportunity to address many of the large hangups.
There are two major hangups that need to be addressed:

  1. Internal VS External library support.
  • Should we continue to package things like Nifty as part of JME, or let the community support things like that as an external package.
  • jBullet has had a long life, but is now having major problems. Physics has mostly moved to native bullet and community packages. We should remove it from JME 4.
  • We will need to cut support for LWJGL2, moving forward it would be ideal to only maintain one LWJGL library, and version 3 is the only one that supports Vulkan.
  1. Rendering Engine
  • JME is designed to be integrated with openGL, we need to create an abstraction layer to allow for other rendering engines to be used. An example of this is having the ability to add support for Vulkan.

Those are the big topics we need to address for JME 4. Once these are addressed, we can start working on the plan for executing them. I already have gone though and re-branded JME3 to JME4 in a private project just to see how hard it would be with all the packages. I think moving forward, we should just use com.jme as the package structure instead of com.jme4 as to make large upgrades easier. But re-branding will be the easiest of all the things we have to do here.

It would be great if we could get some people to take on different roles in the process of doing JME 4. I know nothing about how Vulkan works, so we will need someone(s) to tackle that. As for moving things to JDK11 modules, I can work on that. I am not sure how to create the abstraction layer for the rendering engine, after looking at the core jme3 code, many opengl things are hard coded, this will make the abstraction difficult to do.

Wow, that was a lot! OK, now I am ready to get roasted here :smile:

EDIT: @pspeed JME4 would also be a good opportunity to rebuild the spider monkey serializer. I know you have worked on it a lot and are not super happy. Not sure if you would be interested in rebuilding it…?

3 Likes

Extending off of this, this is my preliminary road map for JME4, what do you guys think?

  1. Prepwork
  • Create a 4.0 branch on GitHub
  • Create a JME4 issue tag on GitHub
  • Re-brand to JME4
  • Remove all deprecated libraries/classes/functions from jme3
  • Remove jme3-jbullet
  • Remove jme3-lwjgl
  • Remove old animation system
  1. JDK 11
  • Move to Gradle 5
  • Implement java 9+ modules
  1. Vulkan Support
  • Add abstraction layer between the rendering engine and the rest of jme
  • Abstraction layer tests
  • Get OpenGL working in the new rendering layer
  • Get Vulkan working in the new rendering layer
  • Add basic Vulkan shaders
  • Vulkan tests
  1. Platform Support (need to get working in JME4)
  • Windows
  • Linux
  • OS X
  • Android
  • iOS
  1. Other JME4 Projects
  • Rewrite serializer (?)

Things to take into consideration when planning this roadmap:

  • This JME4 will cut support for JDK 8
  • There is a laundry list of items that we may or may not want to consider here: https://github.com/jMonkeyEngine/jmonkeyengine/issues/198
  • If there are any changes not being implemented due to breaking compatibility with previous builds, this is the time to make those changes.

About the SDK
At this time it is NOT within the scope of JME4 to prepare a SDK based on Netbeans 10+.
If someone wants to do this, we would welcome it with open arms, but it will take a massive amount of work, and we already have a lot to do just getting JME4 ready.

5 Likes

agree something should be made forward for JME4. JME is great engine, main issue is vulkan support. I think it would even increase community activity :slight_smile:

jme3-jbullet - well, some people still use it, but hey, its JME4, so we should stick to future :slight_smile:

im not familiar with Vulkan much, so cant tell here.

Why bother with an abstraction layer over OpenGL/Vulkan? Support Vulkan or don’t… but watering it down through an “OpenGL Compatible” interface seems pointless to me.

If you want Vulkan support then someone needs to take the time to design an engine that is built on Vulkan ideas… not OpenGL ones. We’d need another Kirill (momoko_fan) to push that forward. It’s a lot of work.

Anything else is pointless to me.

@pspeed are you thinking of just cutting OpenGL all together then? My understanding is that many platforms such as mobile devices still do not support Vulkan yet, is that correct?

I just don’t understand the point of supporting Vulkan if it’s just a hobbled thing under an OpenGL compatibility layer. That’s already what OpenGL is now.

Someone needs to think about what a Vulkan-centric design would look like and then decide if an ES compatibility layer would make sense or how that could be cribbed in.

…but trying to support regular OpenGL and Vulkan simultaneously doesn’t make sense to me. What’s the benefit of having Vulkan shoe-horned underneath there?

2 Likes

@tlf30 Looks like some good ideas up there to me. I’m a little hung up on:

  • Remove jme3-jbullet
  • Vulkan Support

I suppose I don’t feel strongly either way about dropping JBullet, other than it’d be a shame to lose it without good reason (are there any, other than it’s not actively maintained outside of JME?). When I get a chance to look into it further, maybe I’ll develop a stronger opinion. With Minie coming along change is a certainty anyway, so I wonder if there’s a good middle ground solution, with some careful architectural planning. @sgold probably has some thoughts on the matter.

As for Vulkan, what pspeed is saying makes sense to me. Supporting both GL and Vulkan would be nice if it can be done without hindering a Vulkan implementation, but I doubt it can be done. These things have a way of hiding complexity from you until it’s too late. If someone were to implement Vulkan support, it’s be a real shame if it were negatively impacted just for OGL compatibility. It’s a hard enough and high risk enough project without OGL…

Elephant in the room is how to get that done in the first place, so it may be a moot point.

So, relating to the OT,

  • Implement java 9+ modules

I’m curious to hear if you have any specific ideas in mind for this one. It sounds like most of us here don’t see much value in making JME a fully modular project. (Ex. making each subproject a module, or something.) I remain open minded about it, but I do worry about the extra hassles it may bring along.

I can not comment on Vulkan support as I have no experience with Vulkan. But probably will worth to take a look at this engine or ask from the author about his experience with Vulkan. Maybe he can give us some insight about Vulkan support.

Quick, somebody go and recruit him for JME4. :stuck_out_tongue:
Probably the best roadmap a JME Vulkanizer could get… but still a ton of work.

Interestingly, it says it does support both OGL and Vulkan - so maybe supporting both isn’t so bad after all.

Has anyone worked with bg-fx before? It looks like LWJGL has bindings to bg-fx which has multiple render backends (IE metal / opengl / direct x etc). Vulkan looks like it is still wip but technically wouldn’t matter as much.

https://bkaradzic.github.io/bgfx/overview.html

I’m glad that people with good technical vision are thinking about the future of jMonkeyEngine. I don’t know enough about Vulkan (or OpenGL, for that matter) to comment on it.

My goal for Minie is to make it the obvious best choice for JME physics. So if there’s a JME4, I’d be interested in adapting Minie to make it the official physics library of JME4. In a JME4 context, I’d regard jme3-bullet and jme3-jbullet as legacy baggage.

3 Likes

Question for the guys pushing for vulkan as if it was a main concern:
What do you plan to do with vulkan that you can’t already do with opengl?

3 Likes