Excelsior's JET with LWJGL?

[nickdotjava]

Anybody know if we can use Excelsior's JET to compile programs using LWJGL to .exe's?

[oNyx]

Yes that works. Look at Cas's AlienFlux

[nickdotjava]

Since I've already started asking about JET here, I figured I'd just continue it here.  Since the personal version requires JDK to run, is the only advantage is your users cannot see your code as easily?  What I understand from their FAQ is that the users need not only JRE, but JDK.  Is this correct?

Games published by our own members! Check 'em out!

[erikd]

How I understood it is that you only need the entire JDK if you compile using the personal edition, and with the prof. edition your program *may* need some DLL's that are part of the JRE. Since there are some licensing restrictions regarding partial distributions of the JRE, you may have to include the entire JRE in that case.

I suppose the personal edition is only useful for having a test drive with JET as I believe you'll be the only one able to run your compiled programs because your compiled program will depend on not only the JDK but also the native compiled JDK (which JET pers.edition does at installation). One advantage is that your compiled program starts faster.

If I'm wrong somewhere, Cas will probably jump in to correct me

[princec]

That's basically right.

Jet Free edition:
user needs entire JDK installed, AND a bunch of Jet DLLs (which are nearly as big as a JRE again)

Jet std edition:
user needs a JRE installed, AND a bunch of Jet DLLs

Jet pro edition:
can use a think called JetPerfect which does away with the requirement for all the Jet DLLs. Does not need a JRE present if you don't use AWT (and hence Swing). Ideal for LWJGL.

Cas

[psiegel]

Wow, I really have to thank you guys for the timeliness of this post.  I was about to go out and buy the standard version without realizing it wouldn't completely separate me from needing the JRE.  Yikes.

Are you saying that any use of AWT/Swing requires the end user to have a JRE installed, despite the code being compiled with Jet?  That's terrible!  Has anyone experimented with ways around this, like using SWT or Agile2D?

[princec]

Well, yes, that's why I designed the LWJGL the way it is. I'm also sure that SWT allows the same.

Jet's worth the £500, for sure. Just make sure you get the Pro version.

Cas

[swpalmer]

Cas, you seem to really like JET.  I for one can say without a doubt that I would NEVER spend £500 on it  I actually can't think of a single piece of software that would be worth that much to me.

I personally don't like the idea of distributing Java programs as native code.  But that's for more political than practical reasons.

In terms of performance JET doesn't seem to offer much.. If I've followed things correctly you are using it primarily to reduce download size, right?   (which is only effective if you don't use AWT/Swing ... only acceptable for fullscreen games)
I guess today downloading the JRE is still a bit of a hurdle.. so I see the point there.  But if you are going to distrubute on CD would it still be worth it?  In that case would it make any significant difference to the end user?  

It just seems to do so little for £500.  To put it in perspective the entire JDK is free.  Micrsoft Visual C++.NET is only $109 USD or £67

[nickdotjava]

Damn that's expensive.  Especially because the project I'm working on has no budget, and is going to be given away freely.  Alright, time for someone to start a sourceforge project on this.  Too bad I don't have the time.  

I agree with Palmer.  There's a reason I only buy academic versions.  75% off is a very nice discount.  I love being a student.  

[princec]

It's definitely worth £500 to me - I think that a normal JRE-distribution would cost me approximately 95% of my sales. That's a good trade.

Now, treading on thin ice but unafraid to don my flameproof pants as usual*, I'd like to stick up for what Jet actually offers:

1) Incredibly quick startup time. Whoosh, it's loaded. It's at least twice as fast as the client VM and about 10x as fast as the server VM to load Alien Flux. This makes A.F look a lot more professional; again, I think this will probably translate into sales. Even if it only translates into 50 sales I've easily made my money back.

2) As I've moaned before, the client VM isn't fast enough - it requires a machine about 20-50% more powerful to achieve the same performance as the server VM. This translates to requiring a minimum spec that's 20-50% higher, which correspondingly translates again into a big loss in sales. I can run A.F. on a P200 (albeit with lo-res graphics, 16 bit color and 30Hz) using Jet. The client VM needs a much tidier spec.

3) Unfortunately the server VM, whilst being as fast as hell to run, is slow as hell starting up. It looks awful. The Jet exe, on the other hand, starts instantly at full speed, no glitches. Again, this will translate into lost sales.

4) The server VM isn't the default VM anyway

5) I have a suspicion that garbage collection is even faster in Jet than the server VM. YMMV. Escape analysis appears to have done away with the few inconsequential instantiations I do; and an advanced incremental concurrent collector with capped execution time has ensured that there are literally no GC pauses. Looks pro. The only pauses you get in A.F. are when it has to load something from disk.

6) Robustness. The whole game is a single .exe, easily installed and run by a total idiot. They can't break the JRE somehow either, as there isn't one.

All the other differences between running with Jet and a JRE aren't terribly relevant to me, like reduced memory consumption etc etc. It just does what it says it does and it does it extraordinarily well. You get what you pay for.

Cas

*burn, then drown, baby

Games published by our own members! Check 'em out!

[swpalmer]

So let me try to summarize.

JET makes it faster as well as smaller.

Point #6 (single EXE) doesn't really mean much in the end.. I've never heard of a typical user going into the program folder for a game and buggering it up.  If you used something like Install Anywhere it would put a private JRE in your game directory and create an exe stub to start your program with that JRE.  Install Anywhere is easy to use and would make idiot-proof installers for multiple platforms.

All your other points are speed related.  So I was incorrect in my assumption that your main reason for useing JET was to reduce download size.  In other words, if using JET did NOT reduce the download size it would still be worth it, because you expect 20-50% more sales by lowering the system spec alone.  If that is even half right, then I see your point, you would obviously make back the cost.

[bedelf]

In other words, if using JET did NOT reduce the download size it would still be worth it, because you expect 20-50% more sales by lowering the system spec alone.

Yep.

Er.. well I was gonna go into detail but I realized the only experience I have with exe vs jars are from a beta I'm in and can't talk about.

Oops.

[psiegel]

I think I have to back up Cas here.  I wouldn't recommend this approach for a freely downloadable game, but in a professional environment Jet does add some very necessary things to compete.  I think what you're really paying for is the luxury of developing in Java while still ending up with a game that performs as well as a game built with C++.

The download size is huge (no pun intended) issue.  My app will go from being almost 10 MB (including the 8 MB JRE) to less than 2MB!  That gives me plenty of extra room to throw in plenty of hi res graphics and sounds to really make the game sizzle.  

Also, I would say Jet earns you a little security.  For example, let's say my game includes a secret algorithm to generate the registration code that will unlock it from demo mode (not an unreasonable shareware approach).  It's a bit more difficult for hackers to get at that algorithm when they're looking at an .exe vs. a bunch of class files.  In fact, decompiling class files is so easy it's rediculous.  Granted, there are some freely available obfuscators out there, but I trust a natively compiled app just a little bit more.

I'm not saying it won't be hard to shell out the bucks for this app.  I had been hoping it would be significantly cheaper than this.  It would also be a lot easier to swallow if I had known this from the beginning.  Now I have to look at not only a significant increase in cost, but I have some extra development time as well as I try to completely strip AWT from my app.  Sigh.

Well, maybe the news at Java One will be really good?

-Paul