for the release version of the SDK we plan to bundle the needed JDK with the SDK. This would solve some problems and make some things easier but also introduce some slight “issues”.
Advantages:
Messed up or completely missing JDK installs don’t mess with the installer or SDK
No separate install of Java/JDK needed
The selected JDK will be evaluated for jME to avoid issues with Java updates / versioning
User can still easily use another JDK by commenting a line in the config file
Disadvantages:
About 30-40MB larger download size
Separate downloads for 32/64 bit windows and linux
Need JDK packages manually packaged in a certain way
Packaging the JDK for the separate operating systems is the most work in all of this but it has do be done only once. This article describes the process and in the first part he describes how to package a JRE/JDK: http://netbeans.dzone.com/including-jre-in-nbi If anyone could try and create such packages of the latest 1.7 JDKs for Linux and Windows 32/64bit that’d be awesome.
In future updates we also plan to integrate the JavaFX packaging for applications (or something similar) which allows packaging a JRE along with the application. This is recommended for most serious games running on java as it reduces the issues people have with their java install immensely and security updates are irrelevant for a JRE used to run one application (that you wrote yourself ;)). This is already possible by altering the Launch4J parameters under windows but its a novelty for MacOSX and required for both the windows and mac app stores.
I see no disavantage on this. From now on, it’s a simple program that has no dependency any other isntalled program, which is really good. And the JDK that will be embeded will work properly, like if the SDK/jME can work in JDK 7, then JDK 7 will be used (or 8 in future), if not, then a working JDK will be selected.
This will stop problems regarding linux users with OpenJDK.
And as @kwando said, if with this we could embed a JRE into the applications, would be awsome!
@shirkit said:
And as @kwando said, if with this we could embed a JRE into the applications, would be awsome!
Not exactly with this step, that would be another step and probably it'll be a separate update/download I guess as the sheer size of the JREs for all platforms are prohibitive.. But then it'll be a simple checkbox in best jME SDK tradition ;)
@normen said:
Disadvantages:
- About 30-40MB larger download size
Is this really an issue nowadays? I mean, you download it once, and maybe some updates. but that's it.
- Separate downloads for 32/64 bit windows and linux
Yeah, but that is something most people can live with.
- Need JDK packages manually packaged in a certain way
Thats a real good point. But i suppose this could be set up somehow so that it can be done autmatically? Dunno, never tried something like that.
In future updates we also plan to integrate the JavaFX packaging for applications (or something similar) which allows packaging a JRE along with the application. This is recommended for most serious games running on java as it reduces the issues people have with their java install immensely and security updates are irrelevant for a JRE used to run one application (that you wrote yourself ;)). This is already possible by altering the Launch4J parameters under windows but its a novelty for MacOSX and required for both the windows and mac app stores.
So any thoughts on this? :)
Cheers,
Normen
That would be a w e s o m e. Especially if it is a one-click option in the SDK.
I think that integrating a JRE with the SDK would only make the SDK download obsolete very quick. I recently downloaded Netbeans 7.1.2 with JDK 7u4 in a single download. And now that Netbeans 7.2 is the better option, that download is now useless to me so it has been deleted from my PC.
I have enjoyed the way it has been to install JMonkey SDK on top of the JDK of my choice. And that choice for me right now is Java 7. However, there are probably people who prefer Java 6.
I have reinstalled the JMonkey SDK various times over the last few years with no problems, and it is easy to update to the latest version (stable or nightly). I wouldn’t want to be installing a JDK every time I do that installation. And I wouldn’t want to be fiddling with command line parameters either. It’s bad enough to remember how to get Netbeans to show up in English when it detects I’m in Brazil.
To have clients run my apps, if they don’t run straight off, it’s no problem to point them to a JRE download on ORACLE’s website. Java FX 2 comes with the Java 7 JDK now anyway, I think. So I can’t see why that would be needed.
The way it has been has worked pretty well for me, so I wouldn’t want to see that changed … unless of course, I’ve miss understood something.
@alfinete said:
I have reinstalled the JMonkey SDK various times over the last few years with no problems, and it is easy to update to the latest version (stable or nightly). I wouldn't want to be installing a JDK every time I do that installation. And I wouldn't want to be fiddling with command line parameters either. It's bad enough to remember how to get Netbeans to show up in English when it detects I'm in Brazil.
To have clients run my apps, if they don't run straight off, it's no problem to point them to a JRE download on ORACLE's website. Java FX 2 comes with the Java 7 JDK now anyway, I think. So I can't see why that would be needed.
You don't install a JDK in the system for this, its in a folder in the application, it would just be a matter of extracting 30MB more while the installer runs really. Is that what you mean or do you mean the actual download size?
And I don't know what you mean by command line parameters? Also I don't know what JavaFX has to do with this in general? It has almost zero benefit for jME applications.. I was only talking about the application launchers and that oracle now also supports bundling the JRE with the JavaFX ant build files.
AFAIK there are/where licencing issues when distributing the JavaFX with your application. Last time i checked this, (4-5 Months ago) it was not sure if you as developer are allowed to distribute the library itself or only an installer…
I would probably still use my externally downloaded and configured JDK but that shouldn’t be a problem so that’s like a -0. For the download size in % it isn’t that much from downloading jME SDK (the rest), Blender, Gimp or what have you that is needed to do stuff so that is also a -0. On the positive side there will be a baseline installation to test against for reference which is +1. Also, hopefully, be less questions about borked installs in the forum which is like +12 so the net would be +14 which is awesome
Edit: there’s a silent +1 for awesome in the net result
The concept certainly sounds good and I don’t see a problem with an extra 40MB on the SDK download. How large is the JRE download though? I guess having the option to include it in distributions would be good but if it was a large increase to download size I’m not sure whether I’d want it in my client distributable or not…
@zzuegg said:
AFAIK there are/where licencing issues when distributing the JavaFX with your application. Last time i checked this, (4-5 Months ago) it was not sure if you as developer are allowed to distribute the library itself or only an installer..
Again, its not about publishing any of the JavaFX libraries, jME doesn't need them. Its just about the small java stub and bundling the JRE/JDK which is legal and possible for quite a while now.
It seems I may have misunderstood the original post, so I’d like to see if I can get closer to the objective this time.
To use an NBI to package a JRE with distributed jME3 programs would be very good in my opinion. It would save a lot of confusion for the client and the extra DL size shouldn’t be a problem.
I have a few questions though:
Will the installer package created by jMP be able to place a launch icon on the desktop (and in the installed programs menu) to launch the app?
Does it provide an uninstaller to uninstall the jME3 app?
… and 3. Are you planning to include a JDK install with the jMonkeyPlatform installer? Since that was what I understood from the first post and is why I wrote what I did previously. It was only when I read the link therein that I realized that this may not be the case.
I think that a bundle is a good idea… in this broadband age 30mb here or there is really not a problem, nor are platform-specific downloads, and that just makes it so much easier to ensure everyone is finding bugs and issues on the same baseline.
For me, and I don’t think I am alone, I still have serious issues with JME crashing and memory related problems, so being able to isolate these and compare with other user’s experiences would be a big plus.
Licensing might be tricky, I’d hate to see JME infected by the GPL, although aggregate work should be perfectly fine.
@alfinete: the post is about bundling the JDK with the SDK which means you do not need a separate install of the JDK and no JDK will be installed on your system. Still you can use a separately installed JDK if you want. The “JRE bundling for games” is a different thing for the future. Maybe I shouldn’t have mixed those two in one thread, sorry
@monkeychops: the part of jme you have to bundle with your app will never be gpl, also the JRE bundling shouldn’t really distract you in any way license-wise.
Losing security updates would not be good. There are malicious images out there that will confuse the JDK into running arbitrary machine code when decoding them for display.
Quickly pushing JDK updates to installed jME SDKs would eliminate that problem.
I’m pretty sure that Oracle offers URLs for checking current Java version and downloading an update; after all, jusched must get that data from somewhere. I don’t know any specifics, unfortunately.
@toolforger said:
Losing security updates would not be good. There are malicious images out there that will confuse the JDK into running arbitrary machine code when decoding them for display.
Security updates are irrelevant. The JDK isn't installed in the system so no other application can use it.
A JVM that loads images typically doesn’t run with Administrator privileges, system JVM or not, so that’s not the scenario.
A zombie herder is after your CPU cycles and network bandwidth, and wants to persist beyond log-off; user privilege is enough for both.
Grabbing Administrator rights is just just a means to an end for them, to increase the infection’s half-life. Definitely not top priority.
In case anybody is wondering how an image can even run code: References to such exploits are in the third and fourth paragraph in the Details section of http://www.ubuntu.com/usn/usn-859-1/ .
