Jump to content
Excelsior Forums


Excelsior Staff
  • Content count

  • Joined

  • Last visited

Posts posted by snowman

  1. I'll second the interest in an OS X version. With that, this would be an excellent write once, compile everywhere tool.

    XDS-C has always been such a tool. I recall a customer who targeted five platforms with it, including Mac OS 9 and SunOS.

    If your development machine is a Mac, configure a small Linux VM and run XDS-C in it.

  2. We have issued Excelsior JET 7.6 Maintenance Pack 1 today, optionally bundled with the Java SE 6u29 support add-on. Download now if you are experiencing any issues or need to bring the Java SE 6 version up to date.

    If you are a paying customer of Excelsior JET 7.6, but the download instructions for the above updates are neither in your inbox nor in the junk mail box, request them from our Support Dept. at support@excelsior-usa.com.

  3. This canonical program

    public class hello
     static public void main (String args[])
       System.out.println("Hello, world!");

    compiled with Excelsior JET into a 64-bit Windows executable has been successfully run. After that, it has finished in time with the expected result. ;)

    Note: Even though many runtime routines and native methods are still replaced with stubs, a lot of compiled Java code has been executed. This is an important milestone that shows we are moving in the right direction.

    Stay tuned!

  4. Do you suggest we deploy the game without music and sound effects? The bugs are rare - letting thousands people download a version without music/sound would be worse IMHO.

    Cannot you send a version without sound specifically to people who reported the problem?

    Also try running my app on the conventional JRE with the -Xcheck:jni option and see if that generates any warnings on your system and on those people's systems.

  5. But our game depends on those libraries. It doesn't work without them. And I don't have a way to reproduce the problem on my machine. So how do you suggest to solve the problem?

    What exactly are those libraries? Cannot you subset your game's source so that it does not use one of them? Or perhaps you can switch off a feature (e.g. audio)?

    Fact is, that the Oracle JVM doesn't crash.

    We had a few customer issues like this in the past, and most of them were JNI misuses that did not trigger any crashes on the Sun JRE simply by coincidence. And all those apps crashed when run on JRockit and/or IBM JDK.

    Our CTO had written an article closely related to this topic last year:

    Switching JVMs May Help Reveal Issues in Multi-Threaded Apps

    I am not ruling out a bug in our product, but we need some way to reproduce it reliably.

  6. The updated Excelsior JET Roadmap is back online.

    In brief: the last 32-bit-only version is on track for October release, the first 64-bit preview is set to see the light of day before the end of 2011, and Java 7 is put aside in favor of an earlier 64-bit release, in turn expected to occur in about a year from now.

    We understand this may not align with your plans for Java 7 and therefore would greatly appreciate your feedback!

  7. I have similar crashlogs from all over the world (different operating systems & hardware). That's why I suspect it's not a hardware issue. Since we use some native libraries it might well be that one of them corrups memory somehow. But I have no idea how I could verify this hypothesis.

    Yes, most likely it's a misbehaving native library. I would try to disable them one-by-one, or use older/newer versions.

  8. We have reached the next internal milestone in the development of 64-bit Excelsior JET:

    • 64-bit JET Runtime DLLs are now part of regular automatic build
    • Compiled executables correctly load the JET Runtime components
    • Initialization of the 64-bit Runtime has passed and reached the point of first execution of Java code

    The next goal is running “Hello, world!”, which, in turn, requires execution of multiple Java SE platform classes on startup.

  9. Excelsior JET has produced the first 64-bit executable that starts and terminates correctly. It was compiled by a baseline (non-optimizing) AOT compiler that currently supports only “simple” bytecodes such as arithmetic operations and direct calls.

    All this may sound trivial, but actually indicates successful completion of a few large engineering tasks:

    • The baseline compiler has been completely re-implemented in Java (BTW, its 32-bit version has passed all JCK 6 tests)
    • 64-bit code emitter has been successfully integrated into the new baseline compiler
    • Lots of work have been done in the linker to support various JET Runtime structures for 64-bit platforms (which will not be limited to Windows and Linux, we hope ;) )

    Now we are working actively on the 64-bit runtime. Stay tuned.

  10. As you may have noticed, our forums were closed down for maintenance for over two weeks. The reason is that we've switched to a new hosting provider, and decided that it would be a good time to migrate to a new forum engine with more adequate counter-spam measures. We apologize for the migration taking a bit more time than expected.

    We have chosen IP.Board, which comes with converters from a couple dozen engines, including our good old SMF 1.1. So far it looks as if all the members and topics and posts were preserved. The password reset feature is in place too.

    If you notice any problems with the new forums, please do not hesitate to let us know. Just reply to this topic, or email our support.

  11. What we really say is that our product has passed the official Java Compatibility Kit test suite on those flavors of Linux. That does not preclude it from working on other flavors.

    Please note however that it only makes sense for us to run the JCK on systems officially supported by Sun, as our product includes the reference implementation of the Java SE API, licensed for commercial use.

  12. The just released Excelsior JET 7.0 beta 3 adds Tomcat support to the JET Control Panel and introduces the capabilities to hide the Tomcat server's [tt]conf/[/tt] directory and its contents, extend its boot classpath, change the main class and the Windows service main class, and specify additional VM options. You still have to resort to the command-line [tt]xpack[/tt] tool for packaging your Tomcat Web applications.

    Beta 3 also supports more recent Java versions: Java SE 6.0 Update 16 (1.6.0_16) and J2SE 5.0 Update 21 (1.5.0_21).

    Download Excelsior JET 7.0 beta 3 for Windows

    Download Excelsior JET 7.0 beta 3 for Linux

  13. Disclaimer: I am not a lawyer.

    To the best of my knowledge, the Apache License and EPL are both compatible with Excelsior JET license, because, unlike GPL, they do not force you to use them for your product.

    For the avoidance of doubt, your binary will include the Excelsior JET Runtime, so you may not release it as a whole under any open-source license.  Even if your source code is available under Apache or EPL, you have to use a separate binary license that does not permit reverse engineering and otherwise complies with the Excelsior JET license.

    Again, if in doubt, talk to a lawyer.