Jump to content
Excelsior Forums

shashaank

Members
  • Content count

    0
  • Joined

  • Last visited

Posts posted by shashaank


  1. Excelsior JET actually had such technology since the second public beta and up to and until version 3.7. It was called JetPerfect, and it enabled you to cram an SWT app onto a 1.44MB floppy disk. But there were two big problems with it:

    • It was extremely fragile - any use of reflection or JNI at run-time could break things completely. One client compiled their SWT app on a system where the mouse had no wheel, and it blew up on its client's systems when SWT tried to load the respective class dynamically.
    • It was illegal - the Java SE license did not permit subsetting the API. (It still does not, with the exception of Compact Profiles introduced in Java 8, but, of course, today you can just take OpenJDK and throw away whatever you want.)

    That's why we dropped JetPerfect from version 4.0, which was the first certified Java Compatible. But even if there were no legal issues, the wheel-less mouse incident alone would have been enough to trigger the decision.

    Thank you :D

    You saved me from putting efforts in this.

    A few days after posting on excelsior I was also feeling that this idea is not so good, and java9 modularization would be far more better (which I suppose would trickle down to excelsior in some way)

    Thank again.


  2. Do you think this is possible with excelsior jet?

    Can we further strip down the size of the executable produced by excelsior using

    a smaller bootstrap runtime?

    Hi,

    I am extremely excited to share something unimaginable.

    Java 8 FX app in less than 5MB !!!!!

    This allows me to use functional programming and other goodies as well !!!!

    Don't believe me, just see it for yourself :

    https://github.com/shashaanktulsyan/spyfs/blob/master/sample%205MB%20java%20application.7z'>https://github.com/shashaanktulsyan/spyfs/blob/master/sample%205MB%20java%20application.7z

    Note : this is a 64bit application, so don't be surprised if this doesn't run on 32bit oses. Also it is based on java8 so it might show error on older versions of windows.

    I am sure you are also wondering what wizardry I have used here.

    Let me tell what I did. I used following this to my advantage :

    1. Java classes are loaded in lazy fashion. So even if there is dependency to a class because of an import statement, the class itself will not be loaded until it is required !
    2. Xbootclasspath can be used to change runtime classes. So instead of using heavy rt.jar and other heavy jar files we can use a highly stripped down runtime which has exactly those classes which we require.
    3. So now the last part remains, is how to find which classes are actually used. For this purpose I don't use anything related to javavm. Instead I use virtual filesystems!!! This way I am also able to remove native libraries (dlls) and resources (configuration files etc) which are not required.
    4. Finally these options can be set very easily in configuration file of a native java application created using javafx packager. Only 2 lines need to be added to do the trick.

    Here I am not going to share the details.

    But I am here to share the excitement. This is really insanely small !

    A Javafx application in 5MB!! That is crazy small.

    What do you guys think?

    Hopefully even Excelsior could benefit from this cool technology things which I just developed.

    BTW if you are interested in knowing the exact steps, check out https://github.com/shashaanktulsyan/spyfs .

    Thanks

    Shashank :D :D :D


  3. Hi,

    I am extremely excited to share something unimaginable.

    Java 8 FX app in less than 5MB !!!!!

    This allows me to use functional programming and other goodies as well !!!!

    Don't believe me, just see it for yourself :

    https://github.com/shashaanktulsyan/spyfs/blob/master/sample%205MB%20java%20application.7z'>https://github.com/shashaanktulsyan/spyfs/blob/master/sample%205MB%20java%20application.7z

    Note : this is a 64bit application, so don't be surprised if this doesn't run on 32bit oses. Also it is based on java8 so it might show error on older versions of windows.

    I am sure you are also wondering what wizardry I have used here.

    Let me tell what I did. I used following this to my advantage :

    1. Java classes are loaded in lazy fashion. So even if there is dependency to a class because of an import statement, the class itself will not be loaded until it is required !
    2. Xbootclasspath can be used to change runtime classes. So instead of using heavy rt.jar and other heavy jar files we can use a highly stripped down runtime which has exactly those classes which we require.
    3. So now the last part remains, is how to find which classes are actually used. For this purpose I don't use anything related to javavm. Instead I use virtual filesystems!!! This way I am also able to remove native libraries (dlls) and resources (configuration files etc) which are not required.
    4. Finally these options can be set very easily in configuration file of a native java application created using javafx packager. Only 2 lines need to be added to do the trick.

    Here I am not going to share the details.

    But I am here to share the excitement. This is really insanely small !

    A Javafx application in 5MB!! That is crazy small.

    What do you guys think?

    Hopefully even Excelsior could benefit from this cool technology things which I just developed.

    BTW if you are interested in knowing the exact steps, check out https://github.com/shashaanktulsyan/spyfs .

    Thanks

    Shashank :D :D :D


  4. Hi,

    One of our users had reported this bug/error wherein when sometimes NU is started, the application doesn't start, but instead crashes and outputs this:

    ddggm0.png

    The detailed error information is provided by the same user, over here:

    
    
    
       JET RUNTIME HAS DETECTED UNRECOVERABLE ERROR: system exception at 0x70ed11c1
       Please, contact the vendor of the application.
    
       Exception 0xC0000005 (EXCEPTION_ACCESS_VIOLATION) at 0x70ed11c1 (C:\Windows\system32\dhcpcsvc6.DLL+0x11c1)
       Failed to execute memory at 0x70ed11c1
    
       PID 11028, TID 12284
    
       Registers:
    
         EAX = 0xFFFFFFE4  EBX = 0xFFFFFFFE
         ECX = 0xF711EA93  EDX = 0x0
         ESI = 0x70ED1898  EDI = 0x169DF72C
         EBP = 0x169DEC8C  ESP = 0x169DEC64
         EIP = 0x70ed11c1 (C:\Windows\system32\dhcpcsvc6.DLL+0x11c1)
    
       Stack:
    
         0x169dec64:  0x76b278d8 0x00000000 0x00000000 0x00000000
         0x169dec74:  0x169ded98 0x169dede8 0x70ed18a8 0x00000001
         0x169dec84:  0xfffffffe 0x011c3886 0x169decac 0x70ed4a3a
         0x169dec94:  0x70ed6054 0x70ed11c1 0x169ded98 0x169df71c
         0x169deca4:  0x169dede8 0x169ded6c 0x169decd0 0x7728b499
         0x169decb4:  0x169ded98 0x169df71c 0x169dede8 0x169ded6c
         0x169decc4:  0x169df530 0x7728b4ad 0x169df71c 0x169ded80
         0x169decd4:  0x7728b46b 0x169ded98 0x169df71c 0x169dede8
         0x169dece4:  0x169ded6c 0x70ed4a1a 0x00000000 0x169ded98
         0x169decf4:  0x169df71c 0x7728b40e 0x169ded98 0x169df71c
         0x169ded04:  0x169dede8 0x169ded6c 0x70ed4a1a 0x70ed13c8
         0x169ded14:  0x169ded98 0x00000000 0x75636573 0x79746972
         0x169ded24:  0x6f72702e 0x65646976 0x65532e72 0x00000000
         0x169ded34:  0x00000000 0x00000000 0x00000000 0x00000000
         0x169ded44:  0x00000000 0x00000000 0x00000000 0x00000000
         0x169ded54:  0x00000000 0x00000000 0x00000000 0x00000000
    
       Version Information:
    
         Java version: 1.7.0_55
         Excelsior JET 10.00 Evaluation edition
         JET Profile: Java SE version: 1.7.0_55; JET update level: 0; CPU architecture: x86
         Runtime: Desktop
         CPU features: cmov mmx sse sse2 sse3 ssse3 sse4.1 sse4.2 popcnt cx8 cx16
         Application was deployed
    
       Options and system properties:
    
         -Djet.jit.disable.resolution=
         -Djet.gc.heaplimit=0
         -Djet.stack.trace=
    
       Entry point type: exe/splash
    
       Command line: "O:\Soft\Neembuu\NeembuuUploader.exe"
    
       OS:
    
       Windows Server 2008 R2 Service Pack 1 build 7601 [WOW64]
    
       Process Modules:
    
       0x00400000 - 0x024db000     O:\Soft\Neembuu\NeembuuUploader.exe
       0x77230000 - 0x773b0000     C:\Windows\SysWOW64\ntdll.dll
       0x765a0000 - 0x766b0000     C:\Windows\syswow64\kernel32.dll
       0x76b90000 - 0x76bd7000     C:\Windows\syswow64\KERNELBASE.dll
       0x6f6e0000 - 0x6f6f8000     C:\Windows\system32\tsappcmp.dll
       0x76ae0000 - 0x76b8c000     C:\Windows\syswow64\msvcrt.dll
       0x753d0000 - 0x754d0000     C:\Windows\syswow64\USER32.dll
       0x76d70000 - 0x76e00000     C:\Windows\syswow64\GDI32.dll
       0x77200000 - 0x7720a000     C:\Windows\syswow64\LPK.dll
       0x754f0000 - 0x7558d000     C:\Windows\syswow64\USP10.dll
       0x76cd0000 - 0x76d70000     C:\Windows\syswow64\ADVAPI32.dll
       0x75880000 - 0x75899000     C:\Windows\SysWOW64\sechost.dll
       0x751a0000 - 0x75290000     C:\Windows\syswow64\RPCRT4.dll
       0x74c40000 - 0x74ca0000     C:\Windows\syswow64\SspiCli.dll
       0x74c30000 - 0x74c3c000     C:\Windows\syswow64\CRYPTBASE.dll
       0x74f10000 - 0x7506c000     C:\Windows\syswow64\ole32.dll
       0x76be0000 - 0x76c40000     C:\Windows\system32\IMM32.DLL
       0x755c0000 - 0x7568c000     C:\Windows\syswow64\MSCTF.dll
       0x758e0000 - 0x7652a000     C:\Windows\syswow64\SHELL32.DLL
       0x756a0000 - 0x756f7000     C:\Windows\syswow64\SHLWAPI.dll
       0x74780000 - 0x747b2000     C:\Windows\system32\WINMM.DLL
       0x75700000 - 0x75705000     C:\Windows\syswow64\PSAPI.DLL
       0x6f3d0000 - 0x6f40c000     C:\Windows\system32\pdh.dll
       0x70ef0000 - 0x70f11000     C:\Windows\system32\ntmarta.dll
       0x76a90000 - 0x76ad5000     C:\Windows\syswow64\WLDAP32.dll
       0x6f4c0000 - 0x6f4c9000     C:\Windows\System32\perfos.dll
       0x6def0000 - 0x6dfae000     O:\Soft\Neembuu\rt\bin\msvcr100.dll
       0x6e1c0000 - 0x6e1c6000     O:\Soft\Neembuu\rt\bin\jetvm\jvm.dll
       0x6e050000 - 0x6e064000     O:\Soft\Neembuu\rt\bin\java.dll
       0x6e030000 - 0x6e044000     O:\Soft\Neembuu\rt\bin\zip.dll
       0x6dff0000 - 0x6e025000     O:\Soft\Neembuu\rt\bin\splashscreen.dll
       0x6d8a0000 - 0x6d9e3000     O:\Soft\Neembuu\rt\bin\awt.dll
       0x75070000 - 0x750ff000     C:\Windows\syswow64\OLEAUT32.dll
       0x6dfd0000 - 0x6dfe4000     O:\Soft\Neembuu\rt\bin\net.dll
       0x758a0000 - 0x758d5000     C:\Windows\syswow64\WS2_32.dll
       0x75690000 - 0x75696000     C:\Windows\syswow64\NSI.dll
       0x73220000 - 0x7325c000     C:\Windows\system32\mswsock.dll
       0x708a0000 - 0x708a6000     C:\Windows\System32\wship6.dll
       0x6e1d0000 - 0x6e1df000     O:\Soft\Neembuu\rt\bin\nio.dll
       0x70940000 - 0x70ade000     C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\COMCTL32.dll
       0x71110000 - 0x71123000     C:\Windows\system32\DWMAPI.DLL
       0x724c0000 - 0x724d6000     C:\Windows\system32\CRYPTSP.dll
       0x6deb0000 - 0x6dee9000     O:\Soft\Neembuu\rt\bin\fontmanager.dll
       0x72480000 - 0x724bb000     C:\Windows\system32\rsaenh.dll
       0x753b0000 - 0x753c7000     C:\Windows\syswow64\USERENV.dll
       0x74ed0000 - 0x74edb000     C:\Windows\syswow64\profapi.dll
       0x72ee0000 - 0x72efc000     C:\Windows\system32\IPHLPAPI.DLL
       0x72ea0000 - 0x72ea7000     C:\Windows\system32\WINNSI.DLL
       0x70ed0000 - 0x70edd000     C:\Windows\system32\dhcpcsvc6.DLL
       0x70eb0000 - 0x70ec2000     C:\Windows\system32\dhcpcsvc.DLL
       0x6de80000 - 0x6deb0000     O:\Soft\Neembuu\rt\bin\t2k.dll
       0x712c0000 - 0x71340000     C:\Windows\system32\UxTheme.dll
       0x76c40000 - 0x76cc3000     C:\Windows\syswow64\CLBCatQ.DLL
       0x6f500000 - 0x6f630000     C:\Windows\system32\WindowsCodecs.dll
       0x6f450000 - 0x6f49c000     C:\Windows\system32\apphelp.dll
       0x6f410000 - 0x6f441000     C:\Windows\system32\EhStorShell.dll
       0x74cb0000 - 0x74e4d000     C:\Windows\syswow64\SETUPAPI.dll
       0x75590000 - 0x755b7000     C:\Windows\syswow64\CFGMGR32.dll
       0x74ee0000 - 0x74ef2000     C:\Windows\syswow64\DEVOBJ.dll
       0x70690000 - 0x70785000     C:\Windows\system32\PROPSYS.dll
       0x6f330000 - 0x6f3a0000     C:\Windows\system32\ntshrui.dll
       0x715b0000 - 0x715c9000     C:\Windows\system32\srvcli.dll
       0x6f4f0000 - 0x6f4fb000     C:\Windows\system32\cscapi.dll
       0x70630000 - 0x7063a000     C:\Windows\system32\slc.dll
       0x714e0000 - 0x71564000     C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\comctl32.dll
       0x6da00000 - 0x6db98000     C:\Windows\system32\NetworkExplorer.dll
       0x6e250000 - 0x6e27e000     C:\Windows\System32\shdocvw.dll
       0x6e220000 - 0x6e232000     C:\Windows\system32\MPR.dll
       0x6e1b0000 - 0x6e1b8000     C:\Windows\System32\drprov.dll
       0x70870000 - 0x70899000     C:\Windows\System32\WINSTA.dll
       0x6dfb0000 - 0x6dfc4000     C:\Windows\System32\ntlanman.dll
       0x6de40000 - 0x6de57000     C:\Windows\System32\davclnt.dll
       0x6de70000 - 0x6de78000     C:\Windows\System32\DAVHLPR.dll
       0x715a0000 - 0x715af000     C:\Windows\system32\wkscli.dll
       0x715d0000 - 0x715d9000     C:\Windows\system32\netutils.dll
       0x6b760000 - 0x6b998000     C:\Windows\system32\wpdshext.dll
       0x71130000 - 0x712c0000     C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.17514_none_72d18a4386696c80\gdiplus.dll
       0x6d6c0000 - 0x6d749000     C:\Windows\system32\PortableDeviceApi.dll
       0x75850000 - 0x7587d000     C:\Windows\syswow64\WINTRUST.dll
       0x75290000 - 0x753ad000     C:\Windows\syswow64\CRYPT32.dll
       0x75710000 - 0x7571c000     C:\Windows\syswow64\MSASN1.dll
       0x192d0000 - 0x192d8000     C:\Program Files (x86)\Internet Download Manager\idmmkb.dll
       0x6dbf0000 - 0x6dc2f000     C:\Windows\system32\audiodev.dll
       0x6b4f0000 - 0x6b757000     C:\Windows\system32\WMVCore.DLL
       0x6dbb0000 - 0x6dbed000     C:\Windows\system32\WMASF.DLL
       0x6dca0000 - 0x6dcc2000     C:\Windows\system32\EhStorAPI.dll
       0x6f2a0000 - 0x6f2a9000     C:\Windows\system32\LINKINFO.dll
       0x724e0000 - 0x724e8000     C:\Windows\system32\Secur32.dll
    
       JET-compiled Components:
    
       O:\Soft\Neembuu\NeembuuUploader.exe exe, version info: jet-1000-release (eval, en)
    
       Java Stack Trace:
    
         java.net.NetworkInterface.getAll(Native Method)
         java.net.NetworkInterface.<unknown>(Unknown Source)
         sun.security.provider.SeedGenerator.<unknown>(Unknown Source)
         sun.security.provider.SeedGenerator.access$000(Unknown Source)
         sun.security.provider.SeedGenerator$1.run(Unknown Source)
         sun.security.provider.SeedGenerator$1.<unknown>(Unknown Source)
         com.excelsior.jet.runtime.excepts.s.<unknown>(Unknown Source)
         com.excelsior.jet.runtime.k12.<unknown>(Unknown Source)
         com.excelsior.jet.runtime.k12.<unknown>(Unknown Source)
         java.security.AccessController.<unknown>(Unknown Source)
         sun.security.provider.SeedGenerator.getSystemEntropy(Unknown Source)
         sun.security.provider.SecureRandom$SeederHolder.<clinit>(Unknown Source)
         com.excelsior.jet.runtime.classload.ClassInitialization.__aj__initClass__Lcom_excelsior_jet_runtime_typedesc_ClassOrInterfTypeDesc_2(Unknown Source)
         sun.security.provider.SecureRandom$SeederHolder.access$100(Unknown Source)
         sun.security.provider.SecureRandom.engineNextBytes(Unknown Source)
         java.security.SecureRandom.<unknown>(Unknown Source)
         java.security.SecureRandom.next(Unknown Source)
         java.util.Random.nextInt(Unknown Source)
         sun.security.ssl.SSLContextImpl.engineInit(Unknown Source)
         javax.net.ssl.SSLContext.<unknown>(Unknown Source)
         neembuuuploader.httpclient.NUHttpClient.getHttpClient(Unknown Source)
         neembuuuploader.versioning.CheckUser.<unknown>(Unknown Source)
         neembuuuploader.versioning.UserImpl$1.run(Unknown Source)
         com.excelsior.jet.runtime.thread.JavaThread.__aj__runThreadBody__(Unknown Source)
    
    
    

    What should we do about this error?

    Any advice?

    Thanks :D


  5. Hi,

    Please contact our Support (java at excelsior-usa.com) and send us your .jpn file to let us examine the problem.

    The problem was solved and I don't have that jpn file anymore.

    The reason for the error, as far as I remember, was Comodo Antivirus.

    It didn't like the way excelsior was liking and binding files.

    And also it didn't popup any message because of which it took me sometime to figure out

    that comodo was the culprit.

    Sorry for the trouble, please ignore this false error report.


  6. When you say "much smaller market", are you comparing by the potential number of users or by potential revenues and profits?

    If the latter, do you have solid market data to support your opinion?

    My comment on market size is based on number of users.

    My perception is based on what I have been hearing and reading lately.

    I have never in my life come across a blog/article talking about

    porting a desktop app to mobile.

    Please try google searching these 2 topics and compare the interest in the two domains.

    (1) port desktop app to mobile

    (2) port android app to iphone

    The maximum interest has been on

    (1) Rapid prototyping to validate the idea first before jumping into a full fledged product

    (2) Porting the prototype or a finished app, to different devices before a fully native version is made

    The mobile app domain is majorly dominated by startups, who have a very different lifecycle.

    They try to follow lean principles as much as possible.

    The revenue per license seems to be a lot lesser.

    Refer : https://build.phonegap.com/plans

    Excelisor could offer a cloud based solution in which if the user cannot afford

    a premium license of excelisor, he can create a ticket and upload his code,

    and excelisor would compile it and allow him to download the compiled binaries.

    The user could do all the testing using trial version of excelsior running

    on his machine. The price for compiling might be something very small.

    It could be per job basis or a monthly subscription.

    This model could work for both desktop and mobile apps.

    Phone gap is doing something similar.

    Again, revenue per user would be small, but the audience would be bigger.

    I cannot say exactly how profitable this might turn out to be.

    For someone doing it from scratch like robovm is getting good donations.

    People want it to survive.

    If someone can do it from zero in about an year, I think excelisor

    with it's advanced compiler technology (which I think is a century ahead of competitors)

    can do it even better and with lesser effort.

    Another model is Xamarin's price model

    https://store.xamarin.com/

    It starts from free and goes to $2000.

    Excelsior's premium license is also $3000.

    It seems to be comparable.

    Apps made using phonegap are so slow that sometimes they are rejected by apple's app store. Imagine giving these users fully optimized native apps, then that $2000 or whatever they are paying would be more justified.

    The basic pricing model which excelsior has could be mixed

    with a cloud based compiling solution something like what phonegap offers. This mixture would open new sources of revenue, increase awareness about excelsior.

    The best way would be to do a press release or some announcement on this,

    see the response that people have. What I am saying is my opinion, I am just suggesting ways using which excelsior can make it's way in the mobile market.


  7. And UI redesign is required in the case of RoboVM as well. An Android app won't look native on iOS.

    Thank you :) For taking my suggestions positively.

    I must apologize for stretching this discussion a bit more, but

    there one point I must emphasize as it really important.

    The problem isn't porting desktop apps to iphone.

    The problem is porting Android apps to iphone.

    Mobile app market is a new market.

    It is not based on a legacy of code from desktop era.

    It is based on new code written in new platform.

    The problem is not porting desktop legacy code to iphone,

    that is a much smaller market

    compared to the market of porting android apps to iphone.

    Indeed even after porting the android app, the UI has to be re-done.

    iOS ui can be done in java using a shim layer which robo vm provider.

    It works it gives 50% the kind of speed JVM would.

    Put Excelsior and I can see >100% performance on iphone (compared to android's dalvik vm.)

    For now (I am not talking about future) it is android vs iphone.

    In future, the demand might be more complex as the number of devices and plaforms as increasing.

    In that kind of scenario the javascript based non-native app might take some lead.

    Like Mozilla's Firefox OS, I think it supports javascript based apps only, and doesn't

    rely too much on native code as such.

    So let us not go into that direction.

    Being able to run the same code (non-UI part of code) on android, iphone & let us say windows.

    That is something hot, but will not remain so for long.

    In terms of portability javascript is proving to be highly more portable than java.


  8. Members of Excelsior senior management not only read this forum, but also post replies.

    Excelsior is an Oracle Java licensee, hence our solution would have to be Java SE compliant, whereas the RoboVM author had chosen to use the Android standard library, so as to aid portability between iOS and Android.

    Does having a Oracle Java license prohibit from making a parallel product which just support Android's Java?

    People design apps specifically for mobile.

    People develop for android, and being able to port that code to iOS would mean coding only once.

    Being able to port desktop app to iOS is something I doubt if I would ever be interested in doing.

    Mainly because the way desktop apps are designed and the way mobile apps are designed is very different.

    Even if the entire desktop app is ported, the UI would require a redesign.

    Could you please explain what exactly is (or was) Excelisor planning for iOS mobile platform ?

    If nothing, you guys should consider taking a stake in robovm and do somekind of collaboration.

    If that market catches up you help them scale by providing excelsior's advanced technology, whereas they would be providing Excelisor with a new market.

    Android to native iOS must be taken seriously, this is my sincere advice.

    Thanks


  9. Hi,

    I am getting the following error :

    excelsior_jet_problem.png

    It is saying

    Invalid Project file <path of the project file> 6372:0

    I created a brand new project, with duplicate settings.

    It is still giving the same problem.

    If I try packaging as a directory it works.

    Packaging it as a executable setup is not working.

    Any suggestion? What should I try to fix this problem?

    I also updated to Jet9.0 MP2 to see if this problem solves.

    (I have installed Jet9.0 MP2 and Jet9.0 on on top of other several times, could that be the reason for this error?)

    Thanks


  10. We are aware of this opportunity, thank you.

    Makes little sense: due to dynamic typing of JavaScript, performance can be improved only via dynamic optimization.

    Please do consider some kind of collaboration (or acquisition) with robovm.

    Robovm would greatly benefit with the kind of optimizations Jet has.

    It will be good Excelsior and java community.

    Excelsior would get access to the user base of robovm which they have already created.

    I hope I did not intrude too much.

    I am just hoping for the best.

    I hope you can forward this suggestion to Excelsior senior management.

    Thanks


  11. It's a known issue (for jar files compiled in the "pack into exe" mode) and it will be fixed in the next release (Dec 2014).

    For now, you can either:

    - get code source from a class residing in a jar not packed into exe, if any; or

    - define your own VM options and use its for loading the library (if you define its value as $(Root)in JetPackII, it will hold the path to installation directory)

    Thank you. For now I made heavy changes in the way the library is detected and solved the problem without breaking compatibility with Oracle JVM.

    What I did was I implemented multiple fallbacks in the code. The code first looked for the dll in the expected location. If it failed, it did something else, and so on. I also placed a copy of the dll in the root directory where excelsior always looks for libraries. This way I somehow got it working.


  12. Hi

    I read here a long time back

    http://rusbase.com/news/author/benhopkins/excelsior-siberian-software-success-story/

    That Excelsior is trying to do for java what Xamarin did for .net

    I am sure you guys must be knowing about Robovm

    http://www.robovm.org/

    It is doing fairly well.

    They compile java to native ios code. (the word vm is a misnomer)

    The performance of robovm compared to that of oracle's is that robovm is twice as slow.

    Combine robovm and excelsior and I see something good out there.

    Objective C developers are high in demand, low in supply.

    Good objective C developers are still a bit tough to find.

    Having your code in 2-3 different languages is another pain point.

    Probably excelisor could acquire robovm.

    Another avenue is this direction is javascript to native.

    A lot of development is happening here.

    Java8 is comming with Nashron, to run javascript with full jvm optimization.

    Webapp developers are faced with problem that front end code is in javascript and backend is in java/.net/php etc.

    Node.js solved this problem allowing rapid prototyping and all code in 1 single language.

    Javascript developers are easy to find. People compare node.js with scala and lift.

    Scala developers are tough to find, and finding skillful ones even tougher.

    There is phonegap which is compiling javascript to native mobile phone apps.

    Not only that, but also compile javascript to apps for chromium os and firefox os.

    Java ---to--> iOs

    JavaScript ---to---> Native

    I think these two things are hot right now.

    What do you guys think?


  13. Hi,

    -----------Edit---------------

    It seems that this issue is not caused by upgrading to Excelsior MP2.

    Basically, it seems the absolute path of the executable is not known to the runtime. It just knows the directory from which it was called.

    I have 2 ways out

    (1) Extract dll to temp folder each and everytime, and load it from there

    (2) Somehow package the dll to into the exe. But I don't know how to do it with excelsior.

    Kindly advice, how I may load my dlls, when my program is

    invoked from a location which is NOT the directory where the exe exists.

    -----------------------------

    My program dynamically loads a dll located relative to the resultant executable created using excelsior.

    The

    Application working directory : F:\neembuu\release1_development_environment

    Location of the dll which is loaded during runtime : f:\neembuu\release1_development_environment\lib\jpfm_x86_rev113.dll

    I resolve the path by first locating the jar file, and then find the dll relative to it.

    The code used to find the jar looks like this:

           String fullLibraryPath = DefaultManager.class
                   .getProtectionDomain().getCodeSource().
                   getLocation().toString();
           LOGGER.log(Level.INFO, "DefaultManager codesource path {0}", fullLibraryPath);
    

    When I run the program from the application working directory, the location of the source I get :

    INFO: DefaultManager codesource path file:/F:/neembuu/release1_development_environment/lib/jpfm.jar

    When I run the program from working directory, say f:\ , using the command

    F:\>\neembuu\release1_development_environment\neembuu-now.exe

    I get the following output

    INFO: DefaultManager codesource path file:/F:/lib/jpfm.jar

    In case the program is run from any directory other than the application working directory

    the location of code is incorrectly specified. This makes loading the dll impossible.

    I think my best bet would be to package the dll into the application itself.

    And simply call the System.load("jpfm_x86_rev113");

    But that would make the code very specific to windows, x86, and excelsior jet and very ugly.

    The last time I compiled all this was working fine.

    Probably I should reinstall the old version of jet and try again.

    When the same thing is run using xjava -jar command the behavior is consistent with my expecations.

    Compatibility is breaking when I compile it to an exe.

    Any suggestion?

    If is this behavior normal? Or I am doing it all wrong?

    Thanks :)

    PS: I am not sure if this is an issue because of upgrading to Jet9.0 MP2,

    but it wasn't the case earlier. I might be wrong, so please correct me in that case.


  14. Hi,

    Default Charset

    System.out.println(Charset.defaultCharset());

    For Oracle JVM is UTF-8

    And for Excelsior Jet 9.0 is windows-1252.

    The javadocs about Charset.defaultCharset() say

    Returns the default charset of this Java virtual machine.
    
    The default charset is determined during virtual-machine startup and
    typically depends upon the locale and charset of the underlying
    operating system.

    I wouldn't expect different defaultCharset being returned

    on the same machine, when running the same program, just on a different VM.

    Please resolve default Charset issue if this difference is non-intentional.

    In any case, this post might be helpful for someone facing similar issue in future.

    Thanks


  15. Hi,

    Firstly, I would like to thank Excelsior.

    We got a free license recently for our free and open source project.

    We are thinking of migrating our UI to javafx.

    Javafx seems to run fine on excelsior jet.

    The only problem is that the compile time is reallyyyyy loooooooong.

    What excelsior jet seems to do is, it uses pre-compiled binaries/objects of java runtime.

    So everytime a user compiles his application he doesn't have to compile the java runtime

    with excelsior jet, he only needs to compile his portion of the code.

    But for javafx, the javafx runtime has to be compiled each and every time.

    That takes a long long time.

    Is there a way, by which, I could compile javafx once and use it everytime by sort of linking

    my project to it ?

    This would reduce the compile time a lot, because my program is not really big, most of the time

    goes into compiling javafx.

    Thanks :)

×