Embedding vm: what is allowed?

General Discussions
#1

I read a post about it somewhere but could not find it, so I hope you don’t mind bringing me this up again. I’d like to avoid having customers deal with downloading and installing a JRE so I have either to compile my game to a native exe via JET or bundle it with an embedded vm. The former is costly and adds an additional step to the deployment task so embedding is an option.

My question is: what am I allowed to do? What can be stripped off?

And just out of curiosity: is someone besides Cas doing this?

#2

go into your JRE folder and view the README.txt file. That file has a section that starts out like this:

and it lists the files which you can exclude from your private jvm

#3

Probably one or two others doing it. Dunno. It’s not an ideal solution but I could use Jet if I wanted to. The way i see it is I’m advertising Sun’s JVM and Java whether it’s complete or not. Evangelism in mysterious ways.

Cas :slight_smile:

#4

[quote]go into your JRE folder and view the README.txt file. That file has a section that starts out like this:
and it lists the files which you can exclude from your private jvm
[/quote]
Stupid me, I could have find this out by myself :-[

Not much allowed to leave out…

#5

The more I lookk at that license agreement the less real reason I can see for it being that way. I once got some BS about “supporting millions of tiny broken versions of Java” but plainly this isn’t what’s happening here. I can see that if I wanted to ship a Puppygames Game VM based on the Sun code that’d be a nasty and immoral thing to do but as it stands… it’s just a great advert for Java technology in gaming to end-users and developers alike. I have met with no progress attempting to get a kosher license for it.

Hm, I’m owed a $45,000 prize by Sun. Maybe they could sort out a license for me instead?

Cas :slight_smile:

#6

[quote]The more I lookk at that license agreement the less real reason I can see for it being that way. I once got some BS about “supporting millions of tiny broken versions of Java” but plainly this isn’t what’s happening here.
[/quote]
There’s not even remotely a technical argument for it these days. Was reading something recently (& after wracking my brains I can’t for the life of me remember where) that discussed the reasoning behind re-use of libraries, etc, that basically stemmed from a time where disk space was expensive, but which no longer makes sense in a modern environment. If that was actually a reality you could (sort of) accept an argument that said: it’s a dumb idea to distribute a VM with your app/game when there should only be one on a machine. But disk space -isn’t- expensive, and your cut down VM is what… only 2MB… so, at the very least, there should be a licensing exception for these sort of uses.

J

#7

JasonB wrote:

Surely the issue is RAM not disk. Main memory is always going to be contended. Re-use between processes wouldn’t be possible if each app had its own private JVM and libs. I run enough different Java apps concurrently that this could make a big difference. (PS: I’m not sure how much modern JVMs actually do this though)

#8

The client version of the latest VM also does class sharing, but the fact is - we don’t care! We just want stuff to work.

Cas :slight_smile: