Jump to content
Excelsior Forums


Excelsior Staff
  • Content count

  • Joined

  • Last visited

Everything posted by kit

  1. Currently, there is no direct support for this in Excelsior Installer. So I may suggest only a workaround using general install customization mechanism implemented in Excelsior JET. But first, you need to change server.xml file specifying java system property instead of hardwired ports as highlighted at http://stackoverflow.com/questions/1045949/change-tomcat-port-on-the-fly Note, that besides JAVA_OPTS environment variable, you may specify your port properties in "catalina.properties" file (patch it at install time). Second, you may customize installation process via implementing Install Callback DLLs where you may draw additional dialog asking needed ports and saving the answers in, for instance, catalaina.properties file. However it would require C/C++ and WinAPI programming skills. The callback DLLs are described in JET User's Guide, Chapter "Deployment automation", Section "Step 6: Specifying Installation Settings / Extra facilities" (http://www.excelsior-usa.com/doc/jet700/jetw007.html#0187), and Section "Excelsior Installer / Callback DLLs" (http://www.excelsior-usa.com/doc/jet700/jetw007.html#0209). See also an example on how to do it at <JETInstallDir>/samples/InstallCustomization.
  2. Yes, of course. Excelsior JET takes Java bytecode of any origin, whether it is Scala, Groovy, JRuby or Jython.
  3. Excelsior JET has its own implementation of memory management and garbage collection, so almost all settings for HotSpot that you listed is not applicable to Excelsior JET at all. Related options for Excelsior JET is highlighted at this Knowledge Base article: "HOWTO: Fine tune application memory footprint" -- http://www.excelsior-usa.com/kb/000025.html.
  4. kit

    Compile & pack only selected jars

    It is possible if your 3 jars do not contain classes/interfaces derived from classes residing in the rest of 30 jars. Excelsior JET cannot compile (and thus protect) classes whose superclasses are not available at compile time. When this occurs, the compiler leaves the classes in bytecode form and packs them into EXE as is. There is a trick for such cases: 1. Prepare fake jars with names of those 30 jars and supply them to the compiler. Do not forget to select "none" in the "Pack into EXE" column for those 30 jars (page "Classpath" of JET Control Panel.) 2. Then click "Check consistency", to check if you will have uncompiled classes in your 3 jars due to absent superclasses (they will be marked with a black icon). 3. After compilation, replace fake jars with the real ones. Altenatively, you may skip creation of 30 fake jars and specify only 3 jars to the compiler. In such case, replace the classpath of your application after compilation via manually setting the "-Djava.class.path" VM property. Non-compiled jars will be handled by the JIT compiler that comes with the JET Runtime.
  5. kit

    packing .dll

    No, it is not possible. External DLLs must be visible to Windows to let it load them. Some Java libraries (such as SWT), use the following trick to overcome this: -- they put DLL into a jar -- on a startup they extract the DLL to the temp directory and load it from there -- on a shutdown they remove the DLL from the temp If you would implement this trick with your application, your DLL will be packed with your jar into executable by Excelsior JET automatically as any other resource. However you have to reconcile that your DLL will be exposed to temp at application run.
  6. kit

    File associations

    Yes, and it is global place. So setting file associations for personal installation would affect all users, that contradicts with the meaning of "personal". Moreover, if an user has no administrative rights, Windows will not allow installation of file associations.
  7. kit

    File associations

    Yes, file associations cannot be installed "personally". It is Windows limitation not ours.
  8. This feature was implemented in JET 7.0. You may download Jet 7.0 Beta's
  9. kit

    Too big native SWT RCP file

    First of all, let us dispel common (as I see) misconception. There are two different types of applications: SWT applications and Eclipse RCP applications. SWT applications are typically plain Java SE desktop applications (that does not use any runtime except standard) that uses SWT as a library for GUI representation of the program. So SWT applications simply put SWT library (swt.jar) to the classpath of the application. Eclipse RCP applications use Equinox Runtime (OSGi) in addition to standard Java SE runtime and this differentiates them from simple SWT applications. Typically Eclipse RCP applications also use SWT for GUI representation but it is not necessarily (for example, you may create a command line Eclipse RCP application that does not have GUI at all). The minimal download size for SWT applications is really about 4-5MB as you saw on our site http://www.excelsior-usa.com/java-download-size.html (yes, it is simple SWT application there). The minimal download size for Eclipse RCP applications that use SWT is larger and is about 12-15MB (e.g. check RSSOwl sample at http://www.excelsior-usa.com/protect-eclipse-rcp-applications.html ) due to huge Equinox Runtime in conjunction with other standard bundles (in addition to SWT, JFace and UI Workbench come with a typical Eclipse RCP application.) To achieve maximum reduction you need to employ Java Runtime Slim-Down technology that is applicable to Eclipse RCP applications as well. See the JET User's Guide, Chapter "Java Runtime Slim-Down" for details on how to enable it -- http://www.excelsior-usa.com/doc/jet650/jetw009.html#0233. Now, we are preparing a live demo for it. I see another common misunderstanding in your post. As I get, you look at the size of an executable that is created just after compiling (having -native suffix). However, when we talk about download size we mean the size of the resulting installer file (that may be simple zip) that can be downloaded and installed by end-user. And this installer package contains not only the executable but also the JET Runtime. All sample installer packages that are placed on our web-site are wrapped by Excelsior Installer that uses advanced techniques for compressing JET-compiled executables and the JET Runtime. So the download size may differ from the size of the executable and it is not correct to look at the size of the executable, if you actually need to keep the download size as small as possible.
  10. kit

    Hibernate 3.2.6 and Excelsior Jet 6.5

    We have fixed the problem -- thanx to dmigowski's example. Anyone who suffers from the same problem may contact support team (java at execelsior-usa.com) to get the hotfix.
  11. I'm afraid you have chosen the wrong place to ask your question. Ask it at Blackberry related forums.
  12. kit

    App server

    We would like to support some compliant Java EE app server. The first candidate is JBoss not Glassfish though, since it is more popular. However we wait for JBoss to move to OSGi as they announced to not do double work of supporting their classloaders and moreover OSGi is already supported in Excelsior JET for Eclipse RCP. Particular dates of such support are not yet defined, we would like to gather feedback on Tomcat support first. If it goes well and we get enough requests for Java EE, it has chances to appear soon.
  13. kit

    Hibernate 3.2.6 and Excelsior Jet 6.5

    BTW, does it work with Sun JRE 6 (on the client only)?
  14. kit

    Hibernate 3.2.6 and Excelsior Jet 6.5

    We need an example to reproduce this misbehavior. Can you provide us it? You may contact "java at excelsior-usa.com" with the subject.
  15. The next version of Excelsior JET will allow you to do this. The first beta including this feature will be available in a week or two.
  16. NulPointerException was because you hacked JNA incorrectly. JNA essentially relies that getDeclaredFields returns fields in the source order and hacking this dependency is not correct: if you set REQUIRES_FIELD_ORDER to false, then fields in native structure may be mapped to not correct fields of JNA's Structure in Java. Thus after calling some native function via JNA that fills native structure, its Java counterpart would be filled incorrectly and some field of it that must be filled may be null (or has not correct value) thus provoking NullPointerException. So since JNA 3.0.5, authors add workaround for the problem: if you call setFieldOrder for all of your Structures then your program written in JNA would work on any JVM. So they shift responsibility to be Java spec compliant from themselves to their users that is not honest IMHO. So you may now write programs in JNA in Java spec compliant way, but even their own samples are not Java spec compliant yet. I would check the balloon sample on our Fedora 9 installation. Would you point us what sample of "official way" have you tried on it to check it also?
  17. Why do you think so? Did you try it with JET?
  18. That is not correct indeed. JNA documentation as well as the message clearly states that "you must use setFieldOrder". What does it mean? For your "convenience" JNA assumes that "native" or "C" structures have the same filed order as declared in a successor of JNA's class "Structure" (that describes "native" structure). If a JVM returns getDeclareFileds in the source order than you "do not need" to use setFieldOrder method for your successor of Structure, else you must call it in the constructor of the class passing to it field names in the source order thus actually declaring explicitly native field order. Once you call setFieldOrder method, you may rearrange those field in the Java source as you like and everything will work on any JVM. I think that JNA's authors name the method in a confusing way and do not document it well. The correct name would be setNativeFieldOrder or setNativeStructureLayout or simply defineLayout as it names in our own similar JNI proxy implementation xFunction (http://www.excelsior-usa.com/xfunction.html). Moreover, IMHO, it must be declared abstract in Structure (and is called automatically) to force JNA's users to implement it, else it implicitly incites them to write Java programs in non-compliant to Java specification way. Really, if Sun (aka Oracle) decides to change the order of fields in getDeclaredField method tomorrow (that is allowed to them by specification -- http://www.excelsior-usa.com/blog/excelsior-jet/a-tale-of-four-jvms-and-one-app-server) then all (yes all) applications that use JNA and do not call setFieldOrder method in their structures will stop working immediately! So the "convenience" I mentioned above is simply clumsy assistance. Sorry for my lyric, let us return to the subject. What do you need to make the sample working? The sample uses OS specific classes such as com/sun/jna/examples/win32/GDI32. If you look inside if them, you will see a lot of classes extending Structure class, and yes, they do not use setFieldOrder. Continue? Yes, you have to call this method in constructors for all of them! For instance, let us take GDI32.RECT class. You have to add default constructor to it like this public RECT(){ setFieldOrder(new String[]{"left", "top", "right", "bottom"}); } and so on ... As JNA is open source, you may contribute the changes back to community since it would make JNA more compliant to Java specification.
  19. kit

    Math calculations

    I have reproduced the misbehavior. Thank you for the sample. We will examine it and if it is proved to be a bug we will try to fix it. If you have an active Support Contract please contact Excelsior Java Team to get the hotfix for the problem.
  20. As far as I understand from the screenshots you have posted here, you have tried the example on Linux. So what Linux distro you have? Please answer also what version of JNA you use as well as Sun JRE version and Excelsior JET version. I have just tried JNA 3.1.0 with balloon example on Windows and RedHat Linux distros and the sample behaves equally on Excelsior JET 6.5 and on Sun JRE 1.6.0_12 (Java 6 Update 12).
  21. kit

    Math calculations

    It is better to send messages to the Excelsior Java Team if you need reply as soon as possible, because the forum has lower priority for monitoring. I have just compiled your test program with javac, executed it on Sun JVM and got the following: How should I proceed?
  22. kit

    What is the format of the xbind.script?

    As you may see from the documentation: "The xbind utility is used to perform post-installation processing of JET-compiled executables. You would normally use it in multiple root installations created with third-party installers." ... and then "JetPackII prepares an xbind script file when creating the installation image. You do not need to edit that file. " So the xbind script is not intended to be edited and thus its format was not documented. However to get an example of it, just turn to "Installation into multiple directories" backend and create the installation package (it is not obligatory to have multiple roots for this installation type -- the only one is ok). You will get an xbind.script file in the unicode format in the target directory. It is fairly easy to discover the format from it. Tips: find the COMPONENT <YourExecutable> and the JETVMPROP directive below is what you need to patch.
  23. We did nothing with xpack for the subject. So please contact Excelsior Support -- "java at excelsior-usa.com" and describe the problem in more details. Some way to reproduce the misbehavior on our side is required.
  24. I believe that the final version of Eclipse RCP support in Excelsior JET will include full featured JetPackII graphical tool that will allow you to wrap resulting application into Excelsior Installer. Nevertheless they should not contain original classes and jar files but only resources. To pack them as a whole, just choose "original jar/zip" item of "Pack into exe" combobox in the Classpath Grid of Classpath Page of the JET Control Panel (you see, texts are in beta stage now ). However be very careful with this! If you have native code libraries that accesses non-jar resources directly the resulting application may not work because non-java native code has no knowledge where the packed resources are. That's why default mode for directory plugins does not pack them into exe as a whole. The typical misbehavior you may see -- if you have directory plugin that contains welcome screen resources, then after packing the resources into exe, the welcome screen will not appear correctly, because Eclipse shows welcome screen via MS Internet Explorer that will not find the resources in the executable. On the contrary, if you make such plugin as a jar, everything will work after packing because Eclipse Runtime retrieves required resources into "configuration" directory for IE before showing in this case and since Eclipse Runtime is Java code we know how to feed it packed-into-exe resources. We are planning to release Excelsior JET 6.5 in 1Q 2009. Regarding the license for the beta, I do not think so, but you'd better to contact our Support or Sales department with this at "java at excelsior-usa.com" and "sales at excelsior-usa.com" respectively.
  25. Yes, you may use xpack utility now to make such "removing" automatically: xpack -source AppDir -target TargetDir then TargetDir will not contain your jars and moreover it could be copied to another PC and work there. To improve protection of .xml files that are packed into exe you may enable "Encrypt strings and resources" setting on the Page Target of JET Control Panel. After that you should not see any readable strings that are critical for you to hide in the executable