doc to pdf Konvertieren...

[izoards]

Hallo Java Community,

Welche Library verwendet Ihr, um *.docx in *.pdf Dateien zu konvertieren?
Ich habe es mit Apache POI versucht, dort wird leider eine Grafik meines *.docx nicht sauber konvertiert. (Nehme an, der Grund ist, dass diese Konvertierung über openOffice geschieht?)

Danach stiess ich auf folgende Lösung:
Convert docx files to PDF files format loss-free with Java | rieckpil

Diese funktioniert einwandfrei, jedoch wird hier dieses exe-Programm benötigt.

Gibt es keine Java Lösung, (Office darf/ist installiert), welche docx zu pdf konvertiert (Verlustfrei) ohne ein externes programm aufzurufen?

Aspose ist ja kostenpflichtig, stimmt das?
Installation | Documentation (aspose.com)

Was gibt es hier für empfehlungen?

Besten Dank für die Hilfe...

 

[Robert Zenz]

Wenn Microsoft Office installiert ist, ist vermutlich die einfachste Moeglichkeit Microsoft Office im Batch aufzurufen um die Datei zu konvertieren.

Microsoft Office Dokumente handhaben ist so eine Sache, am einfachsten ist es immer noch dies direkt mit Microsoft Office zu machen (und selbst da kann es Probleme geben).

 

[MoxxiManagarm]

Baeldung nennt namentlich https://www.qoppa.com/wordconvert/ (sieht mir auf dem ersten Blick aber auch kostenpflichtig aus)

 

[izoards]

Wenn Microsoft Office installiert ist, ist vermutlich die einfachste Moeglichkeit Microsoft Office im Batch aufzurufen um die Datei zu konvertieren.

-> Also eine externe .bat aufzurufen? Also analog der Lösung mit dem exe programm?

...dies direkt mit Microsoft Office zu machen

Wie meinst Du, es direkt mit Microsoft Office zu machen?

 

[Robert Zenz]

Also eine externe .bat aufzurufen? Also analog der Lösung mit dem exe programm?

Ja, beziehungsweise direkt Microsoft Word mit den notwendingen Parametern um die Datei im Batch (also ohne Oberflaeche) zu konvertieren. Ich bin sehr sicher dass das geht, weil ich sowas schon als Service gesehen habe (also Datei wird an eine Windows VM geschickt, dort konvertiert, PDF wird zurueck geliefert), aber ich weisz nicht was man genau dafuer machen muss.

 

[izoards]

Baeldung nennt namentlich https://www.qoppa.com/wordconvert/ (sieht mir auf dem ersten Blick aber auch kostenpflichtig aus)

Es gibt auch noch: documents4j - A document format converter for Java

hat da schon jemand Erfahrung?

 

[izoards]

Ja, beziehungsweise direkt Microsoft Word mit den notwendingen Parametern um die Datei im Batch (also ohne Oberflaeche) zu konvertieren. Ich bin sehr sicher dass das geht, weil ich sowas schon als Service gesehen habe (also Datei wird an eine Windows VM geschickt, dort konvertiert, PDF wird zurueck geliefert), aber ich weisz nicht was man genau dafuer machen muss.

Also mit PowerShell habe ich sowas schonmal gemacht.. Jedoch möchte ich es nun über Java machen...

 

[kneitzel]

Also mit PowerShell habe ich sowas schonmal gemacht.. Jedoch möchte ich es nun über Java machen...

Wenn Du es mit PowerShell schon gemacht hast, dann wäre evtl. eine Einbindung von PowerShell denkbar:

GitHub - Tuupertunut/PowerShellLibJava: A simple library for using PowerShell from Java.

A simple library for using PowerShell from Java. Contribute to Tuupertunut/PowerShellLibJava development by creating an account on GitHub.

github.com

Wenn Du in PowerShell auf die COM Wrapper zugegriffen hast, dann hattest Du da ja schon einen vernünftigen Ansatz.

Die Frage ist sonst, ob man sich per JNA nicht entsprechende Wrapper bauen will. https://medium.com/@phasslr/access-microsoft-excel-from-java-the-low-budget-way-6b57eece4204 beschreibt das wohl ein wenig.

Aber nur für das Konvertieren in ein PDF halte ich dies für zu kompliziert.
Statt dessen würde da einen einfachen Aufruf tätigen. Dabei ist es egal, ob es ein direkter Winword aufruf ist oder noch in einem PowerShell Script verpackt oder mit irgend einem separaten kleinen Tool wie docto (https://github.com/tobya/DocTo). Aber das wäre halt nur meine Präferenz.

 

[Neumi5694]

Ich kann da nur kneitzel zustimmen. Falls es schon einen fertigen Konverter gibt, verwende den per Script oder JNA oder was auch immer.

Auf eine reine Java-Lösung würde ich in diesem Fall verzichten (es sei denn, jemand hat das schon programmiert und du darfst das verwenden).

Es fängt ja schon bei der Frage an, ob du die Doc überhaupt komplett (und richtig) einlesen kannst.
Man erinnere sich an die ersten Gehversuche von OpenOffice/LibreOffice, als Doc-Dateien in OO anders aussahen als in Word. Damit war der Ruf der eigentlich tollen Software lange Zeig geschädigt.
Die Daten einer Excel-Tabelle oder den Text einer Word-Datei einzulesen, ist eine Sache. Das Ganze optisch richtig darzustellen (auf Bildschirm oder in Druckdokument) ist ein ganz anderes Kaliber.

 

[izoards]

Super, besten Dank für eure Meinungen und Erfahrungen... Dann werde ich es mit dem externen Skript machen.

Als nächsten Schritt (Optional) müsste ich das PDF noch per Mail versenden (Automatisch ein neues Mail öffnen und das PDF anhängen)
Dies war per PowerShell auch recht simple...
Ist sowas in Java denkbar, oder sollte ich hier auch per externem skript diesen Schritt durchführen?

 

[Neumi5694]

Nein, Netzwerkkommunikation aus Java ist kein Problem, es ist fast schon ideal dafür.

Hier findest du ein paar Ideen:

Sending Emails with Java | Baeldung

Learn how to use the native Java mail library to send emails with and without attachments.

www.baeldung.com

Java - Sending Email

Java - Sending Email - To send an e-mail using your Java Application is simple enough but to start with you should have JavaMail API and Java Activation Framework (JAF) installed on your machine.

www.tutorialspoint.com

Es gibt garantiert auch schon einige fertige Mail-Libraries, die du verwenden kannst, aber Email ist eigentlich recht simpel.

 

[izoards]

Ok top

Aber diese Lösungsansätze sind ohne "Eingriff des Nutzers", ist das richtig?
Ich müsste eben im ersten Schritt einfach eine neue Mail aus Outlook erstellen mit Betreff und kurzem Text und dann noch das PDF anhängen...
Der Anwender soll dann die Empfängeradresse eingeben und das Mail versenden...

 

[izoards]

habe soeben was gefunden, was gut aussieht für meine Bedürfnisse
java - How to create an E-Mail in Outlook and make it visible for the User - Stack Overflow

 

[Neumi5694]

Naja, diese Ansätze verwenden halt in den Beispielen hardcodierte Texte. Die JavaMail API ist nur zum Versenden selbst da, eine (G)UI musst du schon selbst erstellen.

 

[izoards]

habe soeben was gefunden, was gut aussieht für meine Bedürfnisse
java - How to create an E-Mail in Outlook and make it visible for the User - Stack Overflow

Sagt jemand folgende Fehlermeldung etwas:

org.eclipse.swt.SWTException: Failed to create Ole Client. result = -2147221164

Ich kriege diese Meldung auf meinem Rechner, wo ich Outlook 365 (32-Bit) installiert habe.

Am Rechner mit Outlook 2016 (64-Bit) habe ich keine Probleme...

Könnte es ein, dass die JVM mit 32-Bit laufen muss? Oder hat jemand einen Ansatz, wo das Problem liegen könnte?


Hier hat jemand ein ähnliches Problem, jedoch weiss ich nicht was die Lösung ist:
java - Fail to open outlook 2013 application using OleClientSite API in eclipe - Stack Overflow


Danke für die Hilfe...

 

[kneitzel]

Ja, Deine Vermutung ist schon richtig. Das 32Bit und 64Bit sind sozusagen zwei getrennte Systeme. Du brauchst also für Zugriffe per OLE die gleiche Architektur - also entweder läuft alles unter 32Bit oder eben unter 64Bit.

Und das besagt in dem Link auch die Fehlermeldung - "Class not registered". In dem (Sub)System ist die angeforderte Klasse nicht registriert, d.h. Outlook ist nicht (in dem richtigen (Sub)System) installiert.

 

[izoards]

Ja, Deine Vermutung ist schon richtig. Das 32Bit und 64Bit sind sozusagen zwei getrennte Systeme. Du brauchst also für Zugriffe per OLE die gleiche Architektur - also entweder läuft alles unter 32Bit oder eben unter 64Bit.

Und das besagt in dem Link auch die Fehlermeldung - "Class not registered". In dem (Sub)System ist die angeforderte Klasse nicht registriert, d.h. Outlook ist nicht (in dem richtigen (Sub)System) installiert.

Besten Dank, kann ich in IntelliJ einstellen, ob ich es in 32-Bit oder in 64-Bit "haben" möchte.
Oder muss ich das in der JVM in den Umgebungsvariablen machen?

 

[Neumi5694]

Du musst eine andere JVM verwenden (x86/i586 und nicht, x64).

 

[izoards]

wo kann ich das ändern?

 

[kneitzel]

Wie rufst Du das denn auf?

In der Regel reicht es, wenn Du eine entsprechende JVM installierst und dann gezielt diese JVM nimmst. Bei Start mit doppelklick auf dem jar File kann das kritischer sein - da zur Not einen Link erstellen, der eben ein entsprechendes javaw -jar .... aufruft.

Bei IntelliJ sollte es ausreichen, beim Projekt die entsprechende JVM zu hinterlegen, also zur Not das entsprechende jdk irgendwo ablegen und dann in IntelliJ hinzufügen (Dropdown Add... bei Auswahl des JDKs)

Edit: Noch der Hinweis wo es im IntelliJ zu finden ist: Die Einstellung des JDKs findet sich bei den Modul Einstellungen.

 

[Neumi5694]

Du musst eine 32 Bit SDK runterladen und dann mit der darin enthaltenen JVM dein Programm starten. In den Projekteigenschaften solltest du wählen können, welche der installierten SDKs du haben willst.

 

[Neumi5694]

Sinnvoller ist aber, auf deinem 64 Bit System auch die 64 Bit Version von Outlook zu installieren.

 

[izoards]

Super, danke vielmals für die Hilfe...

 

[kneitzel]

Sinnvoller ist aber, auf deinem 64 Bit System auch die 64 Bit Version von Outlook zu installieren.

Da aber ggf. aufpassen. Da kann ein ganzer Rattenschwanz mitkommen. Die Frage ist erst einmal, wieso da die 32Bit Version installiert ist. Nicht dass Du da vom Regen in die Traufe kommst, weil Du das änderst und dann andere Dinge plötzlich nicht mehr gehen (Weil die in 32Bit zur Verfügung stehen) ....

Aber ja: Man sollte versuchen auf 64Bit nur 64Bit Software zu nutzen ... Das vereinfacht das Leben deutlich ...

 

[izoards]

Da aber ggf. aufpassen. Da kann ein ganzer Rattenschwanz mitkommen. Die Frage ist erst einmal, wieso da die 32Bit Version installiert ist. Nicht dass Du da vom Regen in die Traufe kommst, weil Du das änderst und dann andere Dinge plötzlich nicht mehr gehen (Weil die in 32Bit zur Verfügung stehen) ....

Aber ja: Man sollte versuchen auf 64Bit nur 64Bit Software zu nutzen ... Das vereinfacht das Leben deutlich ...

Aber es ist möglich, mit IntelliJ je nach dem, eben über die Auswahl Modul Einstellungen und dann Dependencies von 32-Bit auf 64-Bit zu wechseln?
Interessant finde ich, wenn ich über Systemsteuerung das Java konfig öffne, ist dieses 32-Bit....

Ich würde eben gerne eine Version für 32-Bit Outlook machen und eine für 64-Bit Outlook...

 

[kneitzel]

Aber es ist möglich, mit IntelliJ je nach dem, eben über die Auswahl Modul Einstellungen und dann Dependencies von 32-Bit auf 64-Bit zu wechseln?

Da verstehe ich gerade nicht, was genau du meinst. Du kannst für jedes Modul auswählen, welches JDK verwendet werden soll. Das gilt dann aber nur für das Ausführen aus IntelliJ. Also in der Regel baust Du da also nichts für 32Bit oder 64 Bit, denn Java selbst kennt diese Unterscheidung nicht. Java Code wird in Bytecode übersetzt, er diese Unterscheidung nicht hat, daher ist es egal, ob du es mit 32Bit oder 64Bit erstellst.

Interessant finde ich, wenn ich über Systemsteuerung das Java konfig öffne, ist dieses 32-Bit....

Da geht mir erst einmal durch den Kopf: Was für eine alte Java Version setzt Du denn ein? Das mit der Systemsteuerung ist ja eigentlich schon lange nicht mehr. Aber generell besagt das erst einmal, dass du eine 32-bit Java Version installiert hast, die noch ein Element in der Systemsteuerung mit gebracht hat....

Ich würde eben gerne eine Version für 32-Bit Outlook machen und eine für 64-Bit Outlook...

Was genau erstellst Du denn? Falls Du eine jar Datei erstellen solltest, die nur reine Java Elemente enthält (also keine DLLs und so), dann ist das Produzierte erst einmal unabhängig von der Architektur. Das läuft dann prinzipiell auf jedem System. Du lieferst ja keine Java Runtime mit.

Wenn Du fertige Lösungen haben willst, dann könntest Du auch eine Runtime mitgeben. Dann könntest Du natürlich Lösungen anbieten für verschiedene Plattformen. Das ist ja auch das, was dann mit JLink eingeführt wurde und was dann mit JPackage erweitert wurde.
In dem Zusammenhang kann man sich dann auch die ganzen Lösungen anschauen, die damals verwendet wurden, um z.B. auch eine exe zu erzeugen und so. Launch4j z.B. - Wobei ich das eher für deprecated halte und eben eher zu aktuellen Java Versionen raten würde und Nutzung der entsprechenden Tools.

 

[izoards]

Da geht mir erst einmal durch den Kopf: Was für eine alte Java Version setzt Du denn ein? Das mit der Systemsteuerung ist ja eigentlich schon lange nicht mehr. Aber generell besagt das erst einmal, dass du eine 32-bit Java Version installiert hast, die noch ein Element in der Systemsteuerung mit gebracht hat....

Ich habe Java 8 Update 231

Was genau erstellst Du denn? Falls Du eine jar Datei erstellen solltest, die nur reine Java Elemente enthält (also keine DLLs und so), dann ist das Produzierte erst einmal unabhängig von der Architektur. Das läuft dann prinzipiell auf jedem System. Du lieferst ja keine Java Runtime mit.

Ich erstelle eine Jar Datei.

Heisst das, ich muss jdk 8 32-Bit und 64-Bit installieren und dann im Java Config unter Java Runtime Environement - Einstellungen, die Wahl treffen?

 

[kneitzel]

Ich erstelle eine Jar Datei.

Heisst das, ich muss jdk 8 32-Bit und 64-Bit installieren und dann im Java Config unter Java Runtime Environement - Einstellungen, die Wahl treffen?

Also ich würde mich da erst einmal nicht auf so Spielchen einlassen. Das Starten der Applikation per Doppelclick ist problembehaftet. Es mag sein, dass Du so vorgehen kannst, aber dann läuft evtl. etwas anderes nicht mehr ...

Daher wäre mein Ansatz immer der, dass ich statt einer jar Datei eine Lösung anbieten würde, die alles bündelt. Also ein kleines Paket, das auch eine JRE mitliefert. (Oracle Lizenzbedingungen zu Redistribution kenne ich nicht, daher würde ich ein OpenJDK nehmen das unter GPL steht und daher unkritisch ist.)

Dadurch erreichst Du eine Loslösung von der konkreten Konfiguration des Clients. Deine Software funktioniert dann unabhängig von der Konfiguration des jeweiligen Clients (keine oder falsche Java Version).

Die Lösung könnte also einfach sein, dass Du ein ZIP File erstellst, in dem ein JRE von einem OpenJDK ist:
- so ein ZIP File bei AdoptOpenJDK enthält die notwendigen Dateien in bin und lib (Meist innerhalb eines Verzeichnisses, das die Version und so angibt, also bei einem aktuellen AdoptOpenJDK ist es in jdk8u282-b08-jre)
- Also baust du diese bin undlib Verzeichnisse ein. Das jar kommt mit in das root und ebenso eine start.cmd, so dass Du die Struktur hast:
bin/
lib/
start.cmd
wasAuchImmer.jar

In start.cmd kann einfach sein:

@echo off
%~dp0bin\javaw.exe -jar%~dp0wasAuchImmer.jar

Das ist eine Minimal-Version, die ich mal zusammen geschrieben habe (hoffentlich ohne Tippfehler, da hier im Forum so geschrieben). Hat den Nachteil, dass leider immer ein leeres cmd Fenster erscheint.
Besser ist es natürlich, wenn man z.B. ein MSI anbietet und dann hat man entsprechende lnk Dateien, die das javaw und so entsprechend aufrufen. (Z.B. mittels WiX gebaut ...)
Oder man nutzt ein Tool, dass dies zusammen packt - dann hat der Anwender nur noch eine exe, die er starten kann. Launch4J habe ich schon genannt, aber es gibt da auch noch andere Tools.

Das CMD Fenster bekommt man ggf. auch noch mit anderen Tricks weg - ich habe mir mal ein "HideWindow" Tool in .Net geschrieben, das andere Dinge startet und dabei ein CMD Fenster unterdrückt / versteckt. Aber das halte ich für obsolet und war damals nur etwas für mich und nicht wirklich als Tool gedacht.

 

[izoards]

Oh, danke für diese Infos..

Ich schaue mir mal Launch4J an. Gibt es da irgendwo eine gute Anleitung, für ein "Hello World" Projekt..

Das CMD Fenster möchte ich eben nicht zusätzlich offen haben...

 

[kneitzel]

Schau Dir einfach mal http://launch4j.sourceforge.net/docs.html an - das Tool ist eigentlich recht übersichtlich finde ich.

 

[izoards]

und mit launch4j erstelle ich eine .exe, welche die jre direkt mit drin hat?
Also muss dann keine JRE auf dem Rechner installiert sein?

 

[kneitzel]

und mit launch4j erstelle ich eine .exe, welche die jre direkt mit drin hat?
Also muss dann keine JRE auf dem Rechner installiert sein?

Also ich kenne es so, dass die JRE nicht im exe selbst mit drin ist, sondern in einem Unterverzeichnis.

Du kannst also sagen, dass es z.B. die JRE aus "jre" nehmen soll und dann liegt eine JRE im Verzeichnis jre bei der exe.

 

[izoards]

Also ich kenne es so, dass die JRE nicht im exe selbst mit drin ist, sondern in einem Unterverzeichnis.

Du kannst also sagen, dass es z.B. die JRE aus "jre" nehmen soll und dann liegt eine JRE im Verzeichnis jre bei der exe.

Ach so
Muss ich bei gelegenheit mal alles austesten...

Nächstes Ziel ist es mal, dass ich unter IntelliJ wenigstens beide varianten anwählen kann, so dass ich am Rechner mit 32-Bit Outlook und am Rechner mit 64-Bit Outlook weiter entwickeln kann...

 

[mihe7]

Hm... PDF-Konvertierung mit externem Windows-Tool/JNA/COM-Wrapper, Outlook per OLE-Automatisierung, ein Launcher als Windows Executable... @izoards hat sich hier m. E. denkbar ungeeignete Anwendungsfälle für Java herausgesucht Nicht, dass es nicht funktionieren würde, aber warum soll/will man Java einsetzen, wenn am Ende eine reine Windows-Lösung rauskommen soll?

 

[izoards]

Hmm oook, versuchs trotzdem...

Hab jetzt mal dort wo outlook 32-bit installiert ist die 32-bit JRE "aktiviert"

Jedoch krieg ich jetzt den Fehler:

"C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\bin\java.exe" "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.2.1\lib\idea_rt.jar=58093:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.2.1\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\charsets.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\ext\access-bridge-32.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\ext\access-bridge.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\ext\cldrdata.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\ext\dnsns.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\ext\jaccess.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\ext\localedata.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\ext\nashorn.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\ext\sunec.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\ext\sunjce_provider.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\ext\sunmscapi.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\ext\sunpkcs11.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\ext\zipfs.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\jce.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\jfr.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\jsse.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\management-agent.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\resources.jar;C:\Program Files (x86)\AdoptOpenJDK\jdk-8.0.282.8-hotspot\jre\lib\rt.jar;C:\intellij\doctopdf\target\classes;C:\Users\zusel\.m2\repository\fr\opensagres\xdocreport\org.apache.poi.xwpf.converter.pdf\1.0.0\org.apache.poi.xwpf.converter.pdf-1.0.0.jar;C:\Users\zusel\.m2\repository\fr\opensagres\xdocreport\org.apache.poi.xwpf.converter.core\1.0.0\org.apache.poi.xwpf.converter.core-1.0.0.jar;C:\Users\zusel\.m2\repository\org\apache\poi\poi-ooxml\3.8\poi-ooxml-3.8.jar;C:\Users\zusel\.m2\repository\dom4j\dom4j\1.6.1\dom4j-1.6.1.jar;C:\Users\zusel\.m2\repository\xml-apis\xml-apis\1.0.b2\xml-apis-1.0.b2.jar;C:\Users\zusel\.m2\repository\org\apache\poi\ooxml-schemas\1.1\ooxml-schemas-1.1.jar;C:\Users\zusel\.m2\repository\org\apache\xmlbeans\xmlbeans\2.3.0\xmlbeans-2.3.0.jar;C:\Users\zusel\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0.1.jar;C:\Users\zusel\.m2\repository\fr\opensagres\xdocreport\fr.opensagres.xdocreport.itext.extension\1.0.0\fr.opensagres.xdocreport.itext.extension-1.0.0.jar;C:\Users\zusel\.m2\repository\com\lowagie\itext\2.1.7\itext-2.1.7.jar;C:\Users\zusel\.m2\repository\bouncycastle\bcmail-jdk14\138\bcmail-jdk14-138.jar;C:\Users\zusel\.m2\repository\bouncycastle\bcprov-jdk14\138\bcprov-jdk14-138.jar;C:\Users\zusel\.m2\repository\org\apache\poi\poi\4.1.2\poi-4.1.2.jar;C:\Users\zusel\.m2\repository\commons-codec\commons-codec\1.13\commons-codec-1.13.jar;C:\Users\zusel\.m2\repository\org\apache\commons\commons-collections4\4.4\commons-collections4-4.4.jar;C:\Users\zusel\.m2\repository\org\apache\commons\commons-math3\3.6.1\commons-math3-3.6.1.jar;C:\Users\zusel\.m2\repository\com\zaxxer\SparseBitSet\1.2\SparseBitSet-1.2.jar;C:\Users\zusel\.m2\repository\org\eclipse\platform\org.eclipse.swt.win32.win32.x86_64\3.116.0\org.eclipse.swt.win32.win32.x86_64-3.116.0.jar;C:\Users\zusel\.m2\repository\org\eclipse\platform\org.eclipse.swt\3.116.0\org.eclipse.swt-3.116.0.jar" FlowSys.DocToPDF
Started
Result of Office processing: 0
114032
Exception in thread "main" java.lang.UnsatisfiedLinkError: Cannot load 64-bit SWT libraries on 32-bit JVM
    at org.eclipse.swt.internal.Library.loadLibrary(Library.java:277)
    at org.eclipse.swt.internal.Library.loadLibrary(Library.java:257)
    at org.eclipse.swt.internal.C.<clinit>(C.java:19)
    at org.eclipse.swt.widgets.Display.<clinit>(Display.java:146)
    at FlowSys.createMail.sendEMail(createMail.java:22)
    at FlowSys.DocToPDF.main(DocToPDF.java:64)

 

[mihe7]

Cannot load 64-bit SWT libraries on 32-bit JVM

Jetzt brauchst Du auch die 32-Bit-Version von SWT (sofern es sowas gibt...)

 

[izoards]

hm, ich glaub ich setz einfach office 64-Bit voraus... kriegs irgendwie nicht hin....

 

[izoards]

Hier:

<dependency>
            <groupId>org.eclipse.platform</groupId>
            <artifactId>org.eclipse.swt.win32.win32.x86_64</artifactId>
            <version>3.116.0</version>
        </dependency>

steht zwar, dass es für 86_64 ist...(?)

 

[kneitzel]

x86_64 ist eine Schreibweise für x64 - das ist ein reiner 64Bit Build.
Siehe dazu auch https://de.wikipedia.org/wiki/X64

 

[kneitzel]

Für x86 Windows scheint das die letzte Version zu sein (von 2018):

Maven Repository: org.eclipse.platform » org.eclipse.swt.win32.win32.x86 » 3.108.0

mvnrepository.com

 

[izoards]

Ach soooo, daaanke...
oooh, eben, früher lief doch alles auf 32-Bit...

Jedoch kann ich diese 32-Bit version irgendwie nicht einbinden.... es kommt, dass sie nicht gefunden werden kann...

 

[kneitzel]

Sicher, dass Du Dich nicht verschrieben hast? Zur Not den ganzen Dependency Block 1:1 von der Seite kopieren...

 

[izoards]

Ufff, jetzt hab ich auf Office 64-Bit gewechselt und kanns gar nicht mehr testen... 🙈

 

[izoards]

@kneitzel

Für x86 Windows scheint das die letzte Version zu sein (von 2018):

Maven Repository: org.eclipse.platform » org.eclipse.swt.win32.win32.x86 » 3.108.0​

mvnrepository.com

Habe nochmals ein Anlauf genommen mit dem 32-Bit Office und es hat geklappt.
Musste jedoch folgendes Maven Repository nehmen:

https://mvnrepository.com/artifact/...se.swt.win32.win32.x86/3.105.0.v20160603-0902