Jump to content
Excelsior Forums


Excelsior Staff
  • Content count

  • Joined

  • Last visited

Posts posted by snowman

  1. Where does Excelsior JET fit in your framework?

    Excelsior-Jet would allow organizations using JUIBrowser to deploy the runtime to a shared-folder - and therefor would allow to run it without any 3rd party software installation.

    An app-private JRE is not really well suited for this task, because of the large working set which has to be transmitted over network..

    So the code running on the client is the same regardless of the application, correct? If yes, it indeed makes sense to precompile it. However, a ULC app may run as either applet or JNLP app, but Excelsior JET does not support either. How would your end users launch their apps?

  2. Excelsior JET 4.8 was the last version with J2SE 1.4.2 support. We still have it available for purchase.

    If your app does not work on Sun JRE version 5.0 nor 6, but works on 1.4.2, we could provide you with a trial package of Excelsior JET 4.8. But you won't have the latest features introduced in Excelsior JET 5 and 6...

  3. Would you mind telling us a bit more about your project so that we could advise you better? It is a bit difficult to judge without knowing any details.

    Sure ;)

    Its a framework called (at least for now) JUIBrowser.

    Its some kind of remote-interface-interpreter, which means you can run swing-like code on the server, however the server just creates an UI description and sends it down to a small client which interprets the result.

    Very much like SAP interfaces, but much more flexible.

    So is it something like Canoo ULC (Ultra Light Client)?

    Where does Excelsior JET fit in your framework?

  4. The free non-commercial license would be more appropriate.

    I am not sure. My project is not one of those show-case projects, it has not even really started up with many users, which is stated as requirement for the free non-commercial license.

    I have not decided yet, but would the academic license also be allowed to use for this case?

    Would you mind telling us a bit more about your project so that we could advise you better? It is a bit difficult to judge without knowing any details.

  5. As far as I understand its perfectly legal to compile GPL software with JET, because its a "basis framework", some kind of operating system. Its also legal to compile GPL apps with VC++ and distribute them and also to run GNU software on Windows ;)

    You mix compilation and distribution. Simply put, GPL permits you to do whatever you want with the source code, the restrictions are on distribution. You may only redistribute GPL apps compiled with VC++ if you link to the VC++ runtime dynamically.

    The Excelsior JET Runtime contains our proprietary code and Sun code licensed under SCSL Commercial Use, which is not GPL-compatible.

  6. Hi there,

    I am a student at the technical university vienna in Austria. I am developing an open-source RIA browser, well, which could benefit a lot from Excelsior-JET.

    It would be great if you could answer me a few questions about the academic license:

    1.) My project is GPL and freeware, not commercial but not directly linked to my university activies for now.

    First of all, the Excelsior JET Runtime license is not GPL-compatible. LGPL, BSD, CPL, and many other open-source licenses are all fine, but not GPL.

    If you own the copyright, you may dual-license your project or change the license.

    I hope I can make my diploma using this stuff as its some really complicated piece of software for my terms and quite tricky , but, for now its not linked with university. May I use the academic license for this project?

    The free non-commercial license would be more appropriate.

    2.) Is it allowed to deploy my RIA browser on the internet? Whats about companies using my RIA browser, and adding/developing own plugins (using java-classes dynamically loaded with the "small" JIT compiler). Is this allowed?

    Yes, absolutely.

    Will the academic license display a popup like the evaluation version?


    Has the academic license a global optimizer, thats the only feature I really care about.

    Yes, it has all features of the Professional Edition, only the license is different.

    3.) If all those points are fine, how long does the license last?

    If I finish with university, are the distributed executables not legal anymore, or may I just not use my academic anymore license to compile new code to native?

    If you break all links with the academic environment, the executables will remain legal, but you must stop using the Academic Edition.

    PS: Jet is cool :-)

    Thanks. :)

  7. From our previous porting/migration efforts, I would suggest you to switch warnings off one by one, and only after reviewing the respective pieces of code. Warnings may indicate problems. Even if there is one real problem for 100 warnings, debugging it with warnings disabled is likely more expensive than reviewing all warnings.

  8. Excelsior JET 6.0 Maintenance Pack 1 (MP1) is available for download. It  is a highly recommended update that fixes multiple customer issues.

    MP1 is available to Excelsior JET 6.0 customers at no cost. If you are a registered customer of Excelsior JET 6.0 Standard, Professional or Enterprise Edition, but have not received a user/password combination for MP1 download, request it from our Support Dept.

    Download Now

  9. Excelsior Installer helps you create installation packages for your Windows applications. It is freely available.

    Excelsior Delivery is a commercial product that has all features of Excelsior Installer plus some advanced features.

    Please feel free to use this board to report your Excelsior Installer / Excelsior Delivery usage experience, ask for help and suggest improvements.

  10. We have released Excelsior JET 6.0, featuring the long-awaited support for Java SE 6.

    Other news are:

    - support for Windows Vista and RHEL 5,

    - support for version information and post-install actions, added due to popular demand,

    - Difference Tracker in JetPackII to help you create updates, and, as usual,

    - application performance improvements.

    Full information on new features and improvements

    Download Excelsior JET 6.0 Evaluation Package

  11. I am an Open Source developer, and I have a project in Java. Is it possible for me to use the evaluation version of Excelsior Jet for my project ? ( It's not commercial or anything, just free under GPL) ( this could be helpful for your product by advertising )

    No, it is not. The evaluation license does not allow redistribution. And in any case, the evaluation package produces executables that time out on a fixed date.

    We do grant free licenses to authors of non-commercial Java apps (not necessarily open source) in return for some promotion for our product. However, the Excelsior JET runtime license is not GPL-compatible. You would have to change the license for the natively compiled version, which is only possible if you own the copyright for all GPLed pieces code in your app.

    LGPL is ok, as well as many other open source licenses.

    Please feel free to email our Sales Dept. with more questions.

  12. There is another question.

    Do you have some plans about 64 bit version?

    Given the broadness of your question, I could say that we are working on it right now. However, that is going to be a custom Modula-2 compiler targeting a CPU architecture other than x64, and an operating system other than Windows or Linux...

    Then, the core components of Excelsior JET, namely the AOT compiler and the JVM (except the fast JIT compiler), are written in Oberon-2 and Modula-2 respectively. So if we ever decide to do a 64-bit version of Excelsior JET, we would have to either convert the runtime to C++ or retarget XDS Modula-2 to x64. In that sense, there is a chance that there will be Native XDS-x64. However, the compiler we are using for Excelsior JET development is again a Native XDS-x86 branch customized for our specific needs, so I do not think we'll ever release it to the public.

    In short, we are not going to finance a complete port of XDS to x64 or, for that matter, any other platform, ourselves.

  13. Excelsior JET 5.0 introduces Java Runtime Slim-Down, a new deployment model that may help you significantly reduce the download size of Java SE applications. With it, you may exclude certain components of the Java SE platform from the installation package, namely AWT/Java2D, CORBA, JDBC, JNDI, JSound, Management, RMI, Swing, and XML, provided they are not used by your Java application.

    This release also delivers a major performance increase over the previous versions. As measured with two standard benchmark suites (SciMark2 and SPEC JVM98), the composite scores have improved by a factor of 1.7 compared to Excelsior JET 4.x.

    Full information on new features and improvements

    Download the fully functional Excelsior JET 5.0 Evaluation Package

    Vote for Excelsior JET now!

    Voting for 2007 Java Developer's Journal Readers' Choice Awards ends on May 31st. Excelsior JET is nominated in the "Best Java Virtual Machine" category. This is your last chance to support our nomination. Please vote for us today!

  14. The UPX-Team also found the problem why it segfaults::

    This program seems to be trying to locate one its section (.jidata) by

    looking at its PE header in the memory. Unfortunately it can only see the

    UPX modified PE header, which results in the crash. There is nothing I can

    do about this, sorry.

    Maybe this can be worked-arround some time in future, as it effectivly destroys the ability to decompress in-location. I guess this is also the reson why aspack works (but needs exectly the size of the compressed executable more RAM).

    Is it possible to instruct UPX or any other packer to compress executable sections selectively? 

  15. Compressing an executable file has a big disadvantage: it will not be mapped to memory by the operating system and therefore your application will need more RAM. Moreover, if you run two copies of the application, or two applications that use the same DLLs, memory pages will not be shared among processes, thus increasing RAM usage further.

      .  .  .

    By the way the "Global optimizer" has the same disadvantage. If applications would be linked only dynamically all jet-dlls could be shared every time an jet-compiled application is launched. However you also give the developer the choice here to reduce download size and enhance performance.

    This is not quite the same disadvantage. You can optimize several Java apps sharing most of their classpaths together into one EXE, adding a main() method that would dispatch control to one of those apps' main() methods accoring to the command-line arguments.

    That said, I really don't understand why do you care so much about disk footprint. A typical desktop computer has 100 times more hard disk space than RAM. I still have gigabytes of free disk space on my workstation, but regular slowdowns due to Firefox eating half of its 512 MB of RAM drive me crazy. It is memory usage and in some cases download size that you have to care about, not disk footprint.

    Well personally I would like to be able to compress jet-executable because of real use-cases:

    * Deploy jet compiled demo's on an USB stick which should be able to run right out of the box. Every MB is quite expensive if you deploy hundreds of sticks.

    This is a very good point. I have no idea why USB sticks and flash memory cards escaped my attention when I was writing my previous post...

    * Add the option for companies which do not have a JRE installed to put a jet-compiled version on a shared folder so all windows-pcs could use it. And believe me it makes a difference wether you send 20mb over network or just 8mb.

    OK, yet another point taken.

    * Startup time is still bad. On my Athlon-1000/512mb/60gb a jet executable has a cold startup time of about 7s and this is mostly because of disk-IO. This is about the same as jre-5 needs to start up. The packers support in-location decompression (minimal memory overhead) and decompress with about 200mb/s.

    Have you used the Executable Image Optimizer? It may substantially reduce the startup time, especially combined with the Global Optimizer.

    So the reason why we eventually would use JET would be to remove the burden of installing software (the JRE) just to run a mid-sized java tool. And for this task 20mb/7s are quite a lot. I could almost include a application-private jre.

    The disk footprint of the complete Sun JRE 5.0 is 70MB and you cannot remove much from it without violating the Sun license.

    I don't see why it is such a big deal to just investigate the "problem" and look whats going on. It would maybe take 10-15min for an experienced JET enineer.

    We have no idea what all those packers expect to find inside the executable, and have no resources to investigate. Most likely, this segfault is not the only problem and finding all of them  will likely take much more than 10-15 minutes.

    What we could possibly do and what I think would actually work much better than reverse engineering all those packers on our side is us providing packer authors with a document describing the parts of a JET-compiled executable that must not be compressed, under a non-disclosure agreement. But again, this will take much more than 10-15 minutes and we have other commitments right now.

    For all packers the same problem popped up, namely a segfault at "0x00000008 at address 0x71d279" - so the only interesting thing would be to find out why the packed jet-executable wants to access this adress.

    After we figure this one out, there will likely be more "interesting things to find out". We have gone through this more than once, with our own products and with third-party software.

    I am sure the packer autors would be happy to help out.

    I have not heard back at all from authors of quite a few Java tools and applications whom I contacted in the hope that they might be interested in what we are doing here at Excelsior. You have to ask the packer authors whether they would be willing to help; without that, your statement is worth nothing.

    If users see a sence / would like to use executable packers because of whatever, why not let them?

    Sure. However, there are just a few users asking for this feature (maybe one user less, as LinuxHippy and JavaJulia post from the same IP address :) ). In particular, we have many paying customers asking for Java 6 support, that's a #1 request. I do not think we'll be able to work on anything else except Java 6 plus some features that we did not finish in time for Excelsior JET 5.0 release, schedule for next week.