Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About crazyjavahacking

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, what files should be modify when I execute xlink command? I need to verify whether the call is actually necessary and I was hoping that by investigation what should be changes and whether it actually changed might answer the question. Thanks, Martin
  2. Hi, I am verifying couple of our older JET project scripts and there is the usage of the following 2 switched that seem no longer to be supported in JET project *.prj format: -javacommandline:=java -classpath /apollo/terminal/release.jar -Djava.library.path=/apollo/terminal -Djava.net.preferIPv4Stack=true eu.apksoft.apollo.terminal.TerminalBootstrap -jetcplastpage:=PageCompile -apptype=Plain Please verify. Thanks, Martin
  3. Hi, I wrote a simple Gradle plugin to wrap the JET execution and it turned out one of the integration tests started to fail with JET 15.0. I am attaching the prj file, zipped jetpdb folder content and full build log from which the full command line commands are shown. The java source file is just hell world without any additional dependencies: package apollosoft.build.support.gradle.jet; public class Main { public static void main(String... args) { System.out.println("Hello packed JET !"); } } The important part of the JET compilation log: Starting process 'command '/home/martin/jet-extract-folder/bin/jc''. Working directory: /home/martin/devel/apollo/buildteam/gradle_plugins/build/spockSpecifications/jet/03-jetPacking/build/jet Command: /home/martin/jet-extract-folder/bin/jc =p =a /home/martin/devel/apollo/buildteam/gradle_plugins/build/spockSpecifications/jet/03-jetPacking/build/jet/infoboard.prj Successfully started process 'command '/home/martin/jet-extract-folder/bin/jc'' Excelsior JET v15.0 Professional Edition (c) Excelsior 1997,2018 Active Java SE Version 1.8.0_144 (profile 8144) Make project "/home/martin/devel/apollo/buildteam/gradle_plugins/build/spockSpecifications/jet/03-jetPacking/build/jet/infoboard.prj" Reading /home/martin/devel/apollo/buildteam/gradle_plugins/build/spockSpecifications/jet/03-jetPacking/build/libs/03-jetPacking.jar ... 1 classes Total compilable classes within classpath entries: 1 ------------------------ Parsing Stage --------------------------------------- 1/1: /home/martin/devel/apollo/buildteam/gradle_plugins/build/spockSpecifications/jet/03-jetPacking/build/libs/03-jetPacking.jar:/apollosoft/build/support/gradle/jet/Main.class ------------------------------------------------------------------- files: 1 errors: 0 warnings: 0 notices: 0 ------------------------ Codegen Stage --------------------------------------- 0% done, 1/1 to go: /home/martin/devel/apollo/buildteam/gradle_plugins/build/spockSpecifications/jet/03-jetPacking/build/libs/03-jetPacking.jar:/apollosoft/build/support/gradle/jet/Main.class Oak optimizations Triading <init> Optimizing Generating Triading main Optimizing Generating errors(0), warnings(0), notes(0); bytes(5213), time 0.00 Preparing resources for packing ... Processing /home/martin/devel/apollo/buildteam/gradle_plugins/build/spockSpecifications/jet/03-jetPacking/build/libs/03-jetPacking.jar ... Resources were successfully prepared for packing. ------------------------------------------------------------------- files: 1 errors: 0 warnings: 0 notices: 0 XDS Link Version 2.25.40 Copyright (c) Excelsior 1995-2017. No errors, no warnings Link time 0:00.22 The important part of the JET packaging log: Starting process 'command '/home/martin/jet-extract-folder/bin/xpack''. Working directory: /home/martin/devel/apollo/buildteam/gradle_plugins/build/spockSpecifications/jet/03-jetPacking/build/jet Command: /home/martin/jet-extract-folder/bin/xpack -backend self-contained-directory -source /home/martin/devel/apollo/buildteam/gradle_plugins/build/spockSpecifications/jet/03-jetPacking/build/jet/binary -target /home/martin/devel/apollo/buildteam/gradle_plugins/build/spockSpecifications/jet/03-jetPacking/build/jet/packed Successfully started process 'command '/home/martin/jet-extract-folder/bin/xpack'' JetPackII batch mode The file /home/martin/devel/apollo/buildteam/gradle_plugins/build/spockSpecifications/jet/03-jetPacking/build/jet/binary/jetMainClassTest is compiled for the profile "1.8.0_144" but does not compatible with it. Recompile your application to fix the problem. Fatal error: No JET-compiled components in this project The build error is confusing. Please advice what is going on. Thanks, Martin infoboard.prj infoboard_jetpdb.zip jet-integration-test-build.log
  4. 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
  5. 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
  6. 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
  7. Awesome! Just let me know if I can help with anything. I was using JET 14 on 32bit platform. Thanks, Martin
  8. Code sample committed into https://github.com/Crazyjavahacking/excelsior-jet-so-libs-segmentation-fault
  9. 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
  10. crazyjavahacking

    Safety of PDB files persistence

    Thank you very much for explanations!
  11. crazyjavahacking

    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.
  12. crazyjavahacking

    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
  13. crazyjavahacking

    Run-time linking of shared libraries

    Thank you, your answer is explaining everything well.
  14. crazyjavahacking

    Cleanup of files in JET directory

    Thank you, this is helpful.
  15. crazyjavahacking

    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