Targetted Java Version

[shartte]

Hello everyone,

what is the current roadmap/policy for targetting Java 8? I think it has great potential for making APIs generally nicer (default methods) and simplifying a *lot* of the UI code by using Lambdas for bindings.
Another nice feature would be to use the embedded JavaScript engine - which is now very fast - for things like simplified server-side-only plugins written in JavaScript. Removal of PermGen is also nice, since it simplifies how memory settings are defined.

In general, I would advice to ship a private JRE copy with official client releases (-> launcher), like some other applications do. This helps with support in general, and would allow us to move to Java8. A regular user would not be required to *know* which Java version they need.

Even if we do not move to Java 8, shipping a private JRE still seems worthwhile for the same reasons.

I build and run the current codebase on Java 8 and did not see any problems so far.

If there is general interest and approval for Java 8, I'd look into how we could easily ship a private JRE with releases. It would be especially interesting to look at the new Java 8 compact profiles that strip out alot of seldomly used code that ships with the JRE.

Regards

 

[Florian]

Hi, I think both switching to Java 8 and bundling a JRE are a good idea.

 

[Mike Kienenberger]

How will this impact OS X support?

If I recall, OS X tends to be behind the java curve, with no end-user-controllable way to keep up.

 

[shartte]

I have no Mac that I can try this with, but there is a JRE 8 for Mac OS X here:
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html

It's possible that Safari only uses the Apple Java so Applets run into these problems on Mac OS X. Since a private JRE would not need to be registered with the system in any way, we should not run into any of these problems.

Regards

 

[Cervator]

I think it should be on the road map, but honestly have no idea on priority. Macs will likely bite us one way or another. How caught up are all the major Linux distros?

I know Java 8 has been used (by accident or on purpose) several times before and at times have hit issues, so I wonder if it is an OS specific thing if you hit no issues.

We may also want to try to aim for the same level as other major similar projects, most obvious one of course being Minecraft, being lots of users are likely to have both. If they have to set Java 7 as default for MC to work and Java 8 for Terasology, and either choice will break the other ... that'll lead to some grumbling

 

[shartte]

Ah but Cervator, we would privately ship a JRE with the exact version we need within the Launcher zip.

I have made this change on Windows yesterday (locally) and it worked. The biggest downside is that the download size of the launcher will increase by roughly 45MB. The BIG upside to this on Windows is that we no longer need to tell people that they need to download or update Java. At that point it's irrelevant what they use to run Minecraft. Our JRE will never be "installed" to the system, it just resides in a "jre" subfolder within the Launcher installation.

The big upside is that we can require a minimum version of Java without having users go and install it.

This bundling of JREs should also work for MacOS X and Linux. We are not dependant on the respective distribution, really.

The second downside comes in from this angle: The launcher package will no longer be architecture independent, since it ships a JRE by default. Power Users can always override the JRE we ship if they want, but a "normal" user will not have to care!

------------------------------- Overview of what the launcher directory structure would look like:

TerasologyLauncher.exe -> launch4j exe that will launch lib\TerasologyLauncher.jar USING jre\bin\javaw.exe
jre\bin\javaw.exe
jre\bin\[other binary stuff]
jre\lib\[jre libs]

The official Oracle JRE documentation lists the files that can be removed in redistributed JREs (control panel, browser plugins, other .exe files such as keytool, etc.)

On systems other than Windows, the shell scripts in bin\ would use the bundled JRE to launch the TerasologyLauncher.jar file. There are tutorials on how to do this for Mac OS X and Linux.

 

[Skaldarnar]

I wonder if it is possible to separate the "bundled" JRE from the main launcher somehow. The increased file size bothers me as I think it's unpractical to download 50+ MB just for a small launcher update (e.g., some GUI tweaks or a bug fix).

Likewise, we would need to see how it all fits into the launcher setup with webstart. Pinging @mkalb and @msteiger to lead their attention here.

 

[msteiger]

Bundling JRE is tempting, because the launcher would work in any case, yes. What bothers me is that it's quite big and only rarely necessary. So we would probably provide it as an extra download so that users that already have it, don't need it download it over and over again. It could be a "First-Time-Download-With-Java" package, but I'm unsure if it justifies the effort. Or maybe we could create a minimized JRE (using ProGuard?).

http://stackoverflow.com/questions/2618176/is-it-possible-to-shrink-rt-jar-with-proguard

I think it would be a lot easier and user-friendly to support the users in installing Java properly. Oracle provides all the downloads and and online checks for Java for players that are not computer-savvy:

https://www.java.com/verify/

 

[shartte]

I don't think you're currently legally allowed to reduce the size of rt.jar without loosing the right to redistribute. At least that's what I am reading in the Oracle license, but I might be wrong.

> What bothers me is that it's quite big and only rarely necessary.
It's about 45MB compressed, which I personally don't find to be problematic. The requirement to make it part of the launcher is that the incremental updating works so those 45MB are never redownloaded unless we ship an actual update of the JRE.

> I think it would be a lot easier and user-friendly to support the users in installing Java properly.
I just see this from a normal gaming standpoint that the user should not need to care that our game is written in Java. It should be self-contained for them (download this, run it. hassle free).
It reduces the number of steps necessary to run Terasology for players. Even if we didn't want to upgrade to Java 8, it'd still be good for us to include the JRE i think
On top of that: If a "poweruser" wants to override the JRE we ship, they can always do that easily.

 

[manu3d]

How about Terasology's installer downloading and installing the JRE (minimized or not) if one cannot be found or if the detected one is the wrong version?

 

[shartte]

That would be possible, but right now, there is no installer

It's just a zip file if i remember correctly.

If there was an installer, it'd have to work on Mac OS X and Linux, which makes it even more complicated.

 

[manu3d]

The same installer would have to work on all platforms? Why?

In any case I would suggest that users at large have come to expect an installer. So, at some point it will probably need making. In this context, for the time being it might be possible to put the appropriate JRE in the zip file, as a non-optimized way of doing things. When Terasology gets to the optimization and polish stage, the installer might be made to download the appropriate JRE on the fly, if necessary.

 

[mkalb]

The EXE file is created with launch4J.
Features are:

• Works with a bundled JRE or searches for newest Sun or IBM JRE / JDK in given version range and type (64-bit or 32-bit).
• Opens Java download page if an appropriate Java version cannot be found or a support website in case of an error.

 

[shartte]

> Opens Java download page if an appropriate Java version cannot be found or a support website in case of an error.

That sounds kinda horrible, heh. Why would we even consider doing that? To save 45 MB download size?

 

[shartte]

I made a repository with repackaged JREs for all platforms we support:
https://github.com/shartte/TerasologyJava

The shell script automatically downloads the JRE for all platforms, removes everything marked as optional in the JRE readme and creates a .tar.bz2 with just the JRE. This could be used as input for the packaging/release process for the launcher on Jenkins.

 

[Skaldarnar]

@shartte I see your points with packaging the JRE. Saving 45MB of download size is actually a good point - not everyone has high speed connections.

The main Java release/patch cycle is about 2 months if I oversee it correctly (not counting critical updates). Although 2 months is okay for updating the bundled JRE, doing it every week for small patches can be quite annoying.

I think the main points already mentioned are:

• incremental updates have to work
• platform specific JREs should be bundled
• game and launcher should use the same JRE

We should probably just start working on this on a new branch bundledJRE or use the existing java8 one. We can also set up a build in Jenkins for testing.

I somehow have the impression this discussions circles around a bit ...

 

[msteiger]

I still think that bundling the JRE with the launcher in general wouldn't have the expected effect (more happy users). Why not provide two versions?

• one that is small and fast to download: as @mkalb pointed out, launch4j (and Java Web Start) already support installing Java nicely (and only if required!).
• one that is large, but complete: for users that want a super-simple installation.

What do you think?

 

[shartte]

I would rather have platform-dependant options and a "generic" one that doesn't install anything on it's own, intended mostly for power users.
If you look at other Java software, that's how it's often done. Platform specific packages + a generic one.
*edit*: From the standpoint of the auto self update, this would be one more "product type". The only difference being that product type not including the jre folder.

 

[Cervator]

Aren't those two pairs of options pretty much the same? One smaller generic option that can offer to install Java if needed + larger OS specific ones with bundled JRE?

 

[shartte]

Yes they are! At least almost. I would omit the auto-installing of a JRE for that option though.