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. )
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.
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.
The thought did occur to me. I thought we decided 4 was to be Vulkan support (kidding really).
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.
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)
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.
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.
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.
@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:
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.
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
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…?
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.
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.
@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?
@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.
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.
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.
)
