Jump to content
Excelsior Forums

kit

Excelsior Staff
  • Content count

    0
  • Joined

  • Last visited

Everything posted by kit

  1. Two usability issues with Jet Pack II

    1. To remove After-install runnable, click on the appropriate textfield and press "DEL" key. It is not obvious behavior indeed and there is a RFE for this in our issue tracker. 2. Yes, it is quite strange behavior of the installer. I have created an issue for this. Since it is not fatal misbehavior, the fix is likely to appear in the next JET version only. PS. NullPointerException you reported earlier has been fixed for two days. However, you have not contacted us since then.
  2. Digital Cert being stripped on install

    You are right. You may sign <JET_INSTALL_DIR>/bin/xuninst.exe directly for this purpose. Please let us know if it works
  3. I have reproduced the problem and now we are preparing the hotfix. Please contact our Support Department (java at excelsior-usa.com) to get the fix.
  4. Digital Cert being stripped on install

    In your case, you need to change the sequence of actions you perform as following: 1. build an executable (say "a.exe") 2. Call xpack a.jpn -make-image for_sign_a_dir 3. Sign a.exe in "for_sign_a_dir" directory (you may also sign uninstall.exe here) 4. Create the installer with this command: xpack a.jpn -from-image for_sign_a_dir For more information, please read JET User's Guide, Chapter "Deployment automation", Section "Installations protected by license managers" Please let us know what else we can do to help.
  5. This topic has been moved to How Do I?. [iurl]http://www.excelsior-usa.com/forum/index.php?topic=1564.0[/iurl]
  6. Perhaps, it will be fixed in the next JET version, but it is scheduled as optional task only. We may also implement this on a consultency basis. Please contact our support ( java at excelsior-usa.com ) if you are interested.
  7. Jet 6.4 beta, zip exception

    I have just compiled your application with the JET 6.4 beta 1, however it works flawlessly. Can you provide us the run scenario that reveals the problem?
  8. DestroyJavaVM is not implemented yet in Excelsior JET. So you may not switch the jet-compiled DLLs from one to another currently. We will address this issue in a future version of Excelsior JET. Why is it important for you to reinit JET runtime? Why the jars cannot live in one JVM?
  9. I would like to clarify the feature request. Note, that common installation is not available for users without administrator rights. So actually we can implement the feature in two ways: 1. If the user has no administrator rights, the program is always installed for himself (personal installation) and the Installation type panel is not shown. 2. If the user has no administrator rights, the installation will not be done and an appropriate message will be shown. For both ways, the installation is done for all users, if the user has administrator rights. What way do you prefer?
  10. There is no way to do this currently. I will add this feature request to our issue tracker.
  11. JET 6.0 Invocation/cMain sample error

    Hello, I have just compiled the cMain sample on Vista with JET 6.0 eval and it works fine. Do not you modify the sample before compiling? Can the problem be reproduced on another PC?
  12. highlight status in console log

    Honestly speaking, I do not understand why current output is not enough for your needs. Moreover these lines occur in the log at the very begining and do not take much of the compilation process.
  13. Hardlock Protection with Aladdin HASP

    Hi, I do not know how Aladdins HASP SRM works and why it cannot work properly with Excelsior JET. Have you tried to ask this question to Aladdins technical support?
  14. Recovery excel file was clean by Excelsior JET!

    Excelsior JET never asks to clean Drive, the most probably Windows OS asked it after the disk space was over during Excelsior JET using. Note, that the same might occur, if you would perform another disk space consuming task (download video, for instance). So the problem does not relate to Excelsior JET.
  15. Hi, There is no way to pack the jar into executable using JetPackII. Please contact our Support Dept. as zztop suggested to get an alternative solution.
  16. There is no such switch. Explicitly set properties can be viewed by means of System.getProperty(prop) call. We use standard forum engine, and honestly speaking I do not know, if it is configurable in this way. Now, we consider an issue to be solved, if there is no additional questions asked by initial poster.
  17. Explicitly added means: 1. !classpathentry, if either -protect or -optimize equations set to "all" for it 2. !module YourJar.jar, except both -protect and -optimize equations are not set to "all" globally . 3. !module YourClass.class 4. !batch *.class YourPackage 5. -main=YourClass Yes. Note however, that once you add a class to the compilation set, all its import is also automatically added. So in general, you add an import closure of the class with it. To get a complete freedom with defining of the compilation set, use -superimportonly+ secret option. With this option, the compiler will automatically add only superclasses and superinterfaces of explicitly added class.
  18. Usage (.usg) files are mainly intended to be used with Global Optimizer: they contain classes and members that were used during Trial Run with a special information on their usage and the later is used only by Global Optimizer. Without Global Optimizer enabled, only information about referenced classes are used from .usg files. So .usg files mainly complete your project in this mode, if not all classes from the classpath was explicitly added to the project (so .usg inclusion has impact on compilation in such case). However there should be at least one class that is explicitly added to the compilation set to let .usg files to take any effect. If you compile EXE, the main class is always such explicitly added class. For DLL, if you set -optimize=autodetect and -protect=nomatter, then the compiler does not know from which class it should start optimizing and hence issues "no classes to compile" error. You may explicitly add a class to the compilation set in such case using the !module YourClass.class directive.
  19. Using the SmartCard IO API

    We have fixed the problem. Anybody, who would like to receive the hotfix, may email to Support: java at excelsior-usa.com
  20. 128m No. Some of them listed at JET User's Guide, Chapter "Application Considirations", Section "Java system properties / JET runtime properties", however there are many secret properties and there is no way to see them. No, it is not expected. Note, however, that the process' memory usage is a sum of the heap, loaded code and data of imported DLLs, its own code and data, JITed code, JIT, JIT heap, etc. So it might happen, that even if the application itself uses not so much dynamic memory, the process may use much memory. We have seen such cases. And it might happen that there is no memory for JIT to load, since it requires quite a large amount of continuous address space available at the point. Due to address space fragmentation, the OS may fail to provide it even if there are relatively much memory available at this time. So, to understand if it is your case, please look at Task Manager to see how much memory your application uses just before crash with the error. If it's far from 4 GB and there is no other processes that use much memory then probably it is a flaw in our engine. In this case, I would prefer to continue this thread via support email: java at excelsior-usa.com However there is a (secret) workaround for the above problem. You need to enable -Djet.jit.do.not.unload.compiler to force JIT to stay in the memory once it is loaded. However it causes permanent memory overhead . It depends on your meaning of "minimum set". A reasonable trade-off is to compile all classes that are always loaded by your application at any run, plus those classes that are often loaded, plus those that you wish to protect and keep the rest in the bytecode form expecting JIT compiler to cope with them. With this flag, there is only theoretical possibility for the compiler to lack of the memory. A typical JIT session with this flag is 1-2 classes, and there should be a very big class to make JIT failing. So you may have the certainty with the flag enabled. Note also that a plugin by users may occupy so much heap memory itself that it cannot be handled by any other JVM. Thus, in general, you have not 100% certainty with the subject at all. Yes, it is. And the most probably will stay. AOT is the main feature that differentiates us from other JVM implementations. Yes, you can expect that. We are interested to improve and evolve any piece of our software including JIT and we have this task on our "todo" list. The ideal JVM for us is a real mix of AOT and JIT approaches: the application's core and platform classes should be compiled ahead-of-time, but the rest classes should be handled dynamically without significant performance penalty. I believe that both traditional JVMs such as Sun JVM and our JVM will meet at this point.
  21. Using the SmartCard IO API

    I have just found the following note at Sun site http://java.sun.com/javase/6/docs/technotes/guides/security/enhancements.html: "Sun's Java SE 6 implementation bundles the Smart Card I/O API defined by JSR 268 as well as a provider called SunPCSC which uses the platform's native PC/SC Smart Card stack, if available. Note that neither the API nor the SunPCSC provider are part of the Java SE 6 platform specification and may not be present on other compliant Java SE implementations. " However, as I said, we are working to support it.
  22. Our JIT compiler is scaled down version of the main AOT compiler and its memory usage and the speed is the subject to improve for almost every JET release. So now, it is strongly recommended to compile as many classes as possible ahead-of-time to avoid this JIT overhead. On the other hand, you certainly cannot avoid it for plugins.
  23. By design of our JIT, it has explicit heap limit and may use swap but can not be adaptive as heap limit of a whole application. JITing fails if explicit heaplimit is exceeded. On the other hand, increasing the heap for JIT causes for the main application to be able allocate less memory. So there is a trade-off between how much memory could be allocated by JIT and the application. "JIT ERROR: (RT) not enough memory for JIT compiler" is another error in compare with "JIT ERROR: (JIT) Internal crash while bytecode compiling: out of heap space". The first means that there is no physical memory to load JIT, while the second means that there is no memory to compile classes at run-time by loaded JIT. So increasing the heap for JIT to solve the second problem may cause in turn the first problem. In your situation, I would suggest you to enable the following runtime property: -Djet.jit.disable.resolution In this case, JIT will compile much less classes at single JIT session, so the default JIT heaplimit setting should fit for the most cases.
  24. Using the SmartCard IO API

    Thank you very much for the link. I have examined the issue and found that there is a problem with it in JET 6.0. It is astonishing for me that this concrete API is not necessary to be supported in order to be Java SE 6 compatible, so JCK 6 does not cover it. However we may support it and are working on it now. Can you send us a sample on its usage that we can easily test during this job?
×