Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About crazyjavahacking

  • Rank
  1. Interesting, it looks like this will replace the functionality I wanted to achieve. It looks like JET will maintain some kind of pre-compiled code cache? Will that be valid for one machine, or could that be shared across various machines, e.g. multiple build agents? I will be definitely interested in helping the testing the smart caching is that is possible. I saw you provide BETA release of JET to chosen customers. Thanks, Martin
  2. Our fatjar contains about 14000 class files and JETting takes about 30-45 minutes. That is quite a lot of time. By separating all external libraries into shared libraries and compiling them only once + caching binaries and PDB files we can significantly reduce the build time. Number of our company's class files is about 2500. That is the primary reason for my investigation. Thanks, Martin
  3. We do use JET, but not the multi-component model yet. Currently we use JET to compile one huge fatjar into a final executable without any shared libraries. I am investigating the multi-component model, preparing a prototype and trying to figure out all the problematic cases our build might go into. Thanks, Martin
  4. Awesome! Just let me know if I can help with anything. I was using JET 14 on 32bit platform. Thanks, Martin
  5. Code sample committed into https://github.com/Crazyjavahacking/excelsior-jet-so-libs-segmentation-fault
  6. Hi, I was playing with multi-component functionality and I found out one place where adding additional error description will be very helpful: when I am creating SO library from a JAR file (e.g. impl.jar) that is using bytecode from another JAR file (e.g. api.jar) that is also compiled into SO library, and when the impl.prj file does not contain !uses api.prj, the application will crash at loadtime with segmentation fault, this is different from the situation when a JAR file compiled into executable will miss the !uses api.prj and which will fail with nice NoClassDefFoundError with stacktrace Would it be possible to add some better error handling, or diagnostics in described situation? Otherwise in huge multi-module project it will be difficult to figure out what is done wrong. I can provide sample Gradle + shell projects where the described situation can be reproduced. Thanks, Martin
  7. Safety of PDB files persistence

    Thank you very much for explanations!
  8. Class unloading

    According to the JLS, finalize() method is not guaranteed to be executed. I guess JET runtime will simply hold strong reference to the classloader and that prevents CL to be unloaded.
  9. Safety of PDB files persistence

    Hi, I was performing some testing for multi-component JET applications and I have couple of questions. System requirements: The documentation is mentioning the following minimal system requirements for Linux OS: glibc >= 2.12 linux kernel >= 2.6.32 What does this practically mean? Is JET compiler internally using glibc in the given version? Will all of the produced executables/shared libs be runnable under any Linux OS system that contains at least the given glibc? What compiler/linked is used for the produced executable/shared libs? Project Data Base files Are *.pdb files system independent on the same OS family (e.g. Ubuntu Linux)? Is it possible to safely cache PDB files on the same machine for later usage? In our case it will be very beneficial to pre-compile all external JARs into SO files and only re-compile the application JAR file. For that we will need PDB files (which we can store in artifact repository). Would that work? Multiple files in the "project_jetpdb" directory are created, but it seems like not all of them are necessary (executable will be compiled and linked without them). Can you please verify the following assumptions are correct? bod.pdb (necessary), xyz.efs (not necessary), xyz.rsp (not necessary), xyz.env (becessary), lambdaclasses.pdb (not necessary and looks like dynamically generated at each run), obj.zip (not necessary), rdf.pdb (not necessary and looks like dynamically generated at each run), sym.pdb (necessary) Thanks, Martin
  10. Run-time linking of shared libraries

    Thank you, your answer is explaining everything well.
  11. Cleanup of files in JET directory

    Thank you, this is helpful.
  12. Cleanup of files in JET directory

    Hi, I am trying to analyze which files in JET directory are no longer necessary. The question is whether for proper JET execution do we need: older JRE profiles, setup/backup folder, setup/prebuilt folder, setup/updates folder. Can you please verify? Thanks, Martin
  13. Run-time linking of shared libraries

    Hi, I was testing multi-component applications in JET 14 and the documentation is saying: It looks like that I don't have to use mentioned switch if I put all the compiled *.so shared libraries in the same directory as the binary. Is that correct? Please verify. Thanks, Martin
  14. Hi, I was looking at the JET 14 documentations and it seems like `compilerheap` option is no longer supported. Why is it so? Is there any replacement? Thanks, Martin
  15. Documentation of RSP file format

    Hi, is there any documentation describing the RSP file format? Thanks, Martin