.java --> .exe

Man laver jo netop ikke Java til exe... Java er class og jarfiler... Hvorfor vil du lave den til exe`?

Der er også JET
http://www.excelsior-usa.com/jet.html

Ellers prop det i en JAR fil, så mister du heller ikke platformsuafhængigheden.

Olly:

1. hastighed
2. hastighed
3. hastighed

olly, sådan et svar havde jeg også forventet, men det er jo fuldstændig underordnet, hvorfor jeg skal lave den om.

Kan du ikke hente en Personal JBuilder fra borland og så compilere dem ( lave dem til exe filer )

/Martin

viht> Det er ret sjældent rå eksekverings-hastighed
af Java byte code er et problem. Men visse ting
man laver i Java kan godt være meget ressource-krævende.

martin> Jbuilder kan ikke generere EXE filer.

capote<<<

Nej det er ikke ligemeget, for der er ikke nogen grund til at bruge Java hvis du bare vil ødelægge en af grundstenen i det... Platformsuafhængigheden.

Hvis man vil lave noget så lav en jarfil.

Hvis vi skal holde os til hans spørgsmål, så kender jeg JET og det fungerer udmærket.

arne_v> hvilke ting i Java mener du der? Jeg har altid troet det var når JVM skulle loades.. og bare det faktum at man arbejder i et endnu højere lag.

viht> Swing applikationer kan være meget ressource-krævende,
forkert anvendelse ef entity EJB's kan være meget ressource
krævende. Java kode kan køre lynende hurtigt, men en del
Java libraries/koncepter kan være meget tunge.

Olly-->> Sjovt som både dig og disky råber om platforms-uafhængighed hvergang nogle vil lave en exe ud af Java!

Kunne det mon tænkes, at man ikke ønsker, at distribuere til andre platforme end Windows og at man måske heller ikke vil belemre venlige mennesker som gerne vil anvende programmet, til ikke at downloade JDK'en ??
Kunne komme i tanke om masser af anvendelsesmuligheder hvor det kunne være fedt med en exe!

Måske man både ville give sine kunder mulighed for at downloade en windows-kælling eller en linux-smartass version.... *GG*

og arne_v -->> har du nogle decideret speedtests på at Java er lynende hurtigt?? - jaja i forhold til hvad?? - Er det hurtigere end Delphi, VB, C, C++, C#, J# osv....??

janus_007>>

Ja ja... Hvis ideen med Java var exe så havde Sun nok lavet en compiler til det... Og ja Disky og jeg kan enes om mange ting når der snakkes Java. Hvad er problemet i det? Vi forsøger bare fortælle hvad man bør gøre... Lave en Jar...

janus_007> Ja - det er ret nemt at lave nogle små test i det, som man
traditionelt vil tro at et interpreted byte code sprog er meget
langsommere til end native executable.

Se f.eks. nedenstående lille eksempler i Java 0 C++.

Målte tider på min laptop:
  SUN JVM 1.3.1 = 65 sekunder
  SUN JVM 1.4.1 = 18 sekunder
  native executable compilet med GCC 3.1 = 18 sekunder

(og jeg har prøvet med et hav af optimize options uden at kunne
presse den ned under 18 sekunder)

Nu er der nok hurtigere C++ compilere end GCC, men der er altså
ikke den store overhead i interpreted byte code.

public class Test {
    private static final int N = 1000000000;
    public static void main(String[] args) throws Exception {
        long t1 = System.currentTimeMillis();
        int sum = 0;
        for(int i = 0; i < N; i++) {
            sum = ((sum + 1) * 2 + 1) / 2;
        }
        long t2 = System.currentTimeMillis();
        if(sum != N) {
            System.out.println("Error");
        } else {
            System.out.println(N + " operations in " + ((t2 - t1) / 1000) + " seconds");
        }
    }
}

#include <iostream>

#include <time.h>

using namespace std;

const int N = 1000000000;

int main()
{
  time_t t1 = time(NULL);
  int sum = 0;
  for(int i = 0; i < N; i++) {
      sum = ((sum + 1) * 2 + 1) / 2;
  }
  time_t t2 = time(NULL);
  if(sum != N) {
      cout << "Error" << endl;
  } else {
      cout << N << " operations in " << (t2 - t1) << " seconds" << endl;
  }
}

Hejsa... Jeg har lige testet samme kode, men i VB6. Rystende resultater *GG*

Nu ved jeg jo ikke hvilken maskine du har testet på, men:

VB:
Intel P3 single (850mhz) , 256MB. =     40.08sec
Intel P3 single (1000mhz xeon), 1GB. =     34.09sec
Intel P4 single (1500mHz)256mb =      53.00sec
Intel P3 Dual (1000mhz xeon), 1GB =     29.52sec

Kunne lige for sjov skyld en dag når jeg får tid lave det samme i C# ! - Eller måske andre vil bidrage :O)

Kun 750 MHz 512 MB !

Det var sqda imponerende :O)

Har du PRØVET at lave en eksekverbar jar-fil, og benytte den til dit program. Jeg har selv med held benyttet java2exe(jexepack), men har siden lavet et installations program der installerer JRE-modulet, og er faktisk blevet ret glad for det. Selvfølgelig skal JRE distribueres, men det er jo kun én gang den skal installeres på pc'en, så kan det benyttes til alle programmer skrevet i Java.

Når alt kommer til alt, så er jeg ikke sikker på at der laves så mange programmer, hvor hastighed er en altoverskyggende faktor, og Java er faktisk ikke så langsom endda.

Jeg var selv i begyndelsen af min "Java-karriere" stor tilhænger af exe-filer fordi det virkede nemmest, men hvis man downloader SUNs JRE, kan det jo selv installlere sig på den pc man ønsker, og herefter kan man nemt sende sin java-kode til afvikling på den pågældende pc, det fylder jo ikke ret meget sådan et javaprogram (class-filer).

Jeg kan ikke hjælpe dig med et exe-program, men hvis du ikke har prøvet jar-metoden bør du nok overveje den, for det virker rent faktisk, også hurtigt efter min mening.

Jeg prøvede lige hjemme (Athlon XP 2000 / 512 MB):
  JVM 1.3.1 - 30 sek.
  JVM 1.4.1 - 6 sek.
  GCC 3.1 - 8 sek.
  MS VS6 standard - 6 sek.
  MS VS6 /Ox /G5 - 4 sek.

Hastighed kan ikke bruges som generelt argument mod Java længere.

Jeg kan huske for et års tid siden, hvor jeg så en ret grundig test af Java (et par VM'er), GCC og MSVC. Java sparkede røv i nogle tests, også selv om MSVC var med optimering.
Min personlige erfaring er, at hvis der er tale om rimelig statiske datastrukturer, er Java lige så god eller bedre end et native compiled sprog. Er der imidlertid tale om mange allokeringer/deallokeringer af lager, så kan den store, stygge GC komme ind fra siden og barbere din performance ned til noget, du tror er løgn...
Til gengæld kan du lade dit java-program køre længe uden du løber tør for memory pga. leaks...  ;o)

Nu er din test jo også en smule ensidig, du sagde selv det er i grafikken Java hænger.
dittmer> der er ingen leaks hvis du håndterer hukommelsen rigtigt :)

Garbage Collectoren gør det nemmere at udvikle store programmer. I MSVC/GCC er det blot lidt sværere, men absolut ikke dårligere.

Testen er efter min mening rimelig til at aflive myten om at
Java generelt er meget langsom fordi det er fortolkt byte kode
(sammenlignet med native executable).

Så er der visse libraries/koncepter der er ret tunge (ikke mindst hvis
de bliver brugt forkert). Swing er en af dem som mange beklager sig
over. Jævnfør f.eks. diskussionen Swing versus SWT.