Kategorie: Java

Völlig ohne Vorwarnung haben meine ganzen Java-Projekte diese Fehlermeldung erhalten:

Access restriction: The constructor  is not API (restriction on required library 'C:\Program Files\Java\jre1.8.0_181\lib\ext\jfxrt.jar')

Lösen ließ sich das ganz einfach. Das Projekt hatte sich als Java-Grundlage eine Runtime (JRE) und kein Development Kit (JDK) gewählt –> Das muss einfach wieder umsgestellt werden auf JDK.

Alternativ kann man die Berechtigung auch für das betroffene Projekt vergeben:

In ein Properties des Projekts

• Java Build Path –> Libraries
• Acess Rules –> Edit und Add
• Als Wert „javafx/**“ (in meinem Fall) hinzufügen.

Anschließend Apply und Rebuild –> Problem gelöst 🙂

Beim Vergleichen von Strings mit equal oder Enum Parsen mit „valueOf“ gibt es keinen match, obwohl der String augenscheinlich identisch ist – Dieses Problem wird in diesem Beitrag erläutert:

Beim Parsen von CSV Dateien stößt man ab und zu auf Probleme mit der Encodierung der zu parsenden Datei.

Im konkreten Fall gestaltete sich das Problem als herausfordernd, weil auf den ersten Blick keine Ursache für das Problem erkennbar war.

Die geparste Variable nennt sich „rowTypeString“ und hat im Debugger den Inhalt „RH“

Im Quelltext wird jedoch die Variable über ein Enum mit der  „valueOf()“-Funktion geparst und einem eindeutigen Typ zugewiesen. Diese lief jedoch immer auf eine IllegalArgumentException hinaus.
Die Analyse des String ergab dann doch noch interessante Details:

• Der String hat eine Länge von 3 Zeichen (auch wenn das dritte unsichtbar ist)
  
• Ein Character Array gab auch interessante Details zurück:
  

• Die Methode rowTypeString.getBytes() gibt  zahlreiche Bytes zurück, welche auf das dritte Zeichen hindeuten:
  [-17, -69, -65, 82, 72]
• Eigentlich dürfte das ByteArray nur [82,72] lauten für den String „RH“
  

Die Lösung konnte sich dann doch gut sehen lassen. Es werden alle „nicht druckbaren Zeichen“ entfernt mit dem nachfolgenden regulären Ausdruck:

stringValue.replaceAll("[^\\p{Graph}\n\r\t ]", "");

Ich danke an dieser Stelle dem Verfasser einer Antwort in StackOverFlow

64 Bit ist ein Trend, der nicht mehr aufzuhalten ist. Endlich ist die 3GB-Grenze auf den Clientbetriebssystemen Geschichte.
Mit Windows 7×64 habe ich auch meine Programmierumgebung auf 64 Bit umgestellt – damit gingen meine Probleme los.

Bisher habe ich mit Java und ODBC auf meine ADS-DBF-Dateien zugegriffen mit folgender Konfiguration:

Unter Windows 7 funktionierte die Datenbankanbindung jedoch nicht mehr. Erste Hürde: Installation eines 32-Bit ODBC-Treibers.
Es gibt unter Windows 7 64 Bit die ODBC-Verwaltung in 32 und in 64 Bit:

ODBC Datenquellenadministrator 32 Bit:
c:\windows\SysWOW64\odbcad32.exe

ODBC Datenquellenadministrator 64 Bit:
c:\windows\System32\odbcad32.exe

Die ODBC-Verbindung klappt jedoch nur in Kombination mit 32 Bit Java und 32 Bit ODBC. Auf reiner 64-Bit Ebene funktioniert die Verbindung nicht.
Es kommt folgende Fehlermeldung:

java.sql.SQLException: [Microsoft][ODBC Driver Manager] Der angegebene DSN weist eine nicht übereinstimmende Architektur von Treiber und Anwendung auf.
at sun.jdbc.odbc.JdbcOdbc.createSQLException(Unknown Source)
at sun.jdbc.odbc.JdbcOdbc.standardError(Unknown Source)
at sun.jdbc.odbc.JdbcOdbc.SQLDriverConnect(Unknown Source)
at sun.jdbc.odbc.JdbcOdbcConnection.initialize(Unknown Source)
at sun.jdbc.odbc.JdbcOdbcDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at rentasad.lib.db.ODBCConnection.connect(ODBCConnection.java:68)
at rentasad.lib.db.ODBCConnection.(ODBCConnection.java:29)
at rentasad.main.KreditkartenZuDTIGenerator.main(KreditkartenZuDTIGenerator.java:45)


Diese Fehlermeldung lässt sich jedoch ziemlich einfach beheben.

Es muss ein 32 Bit JDK installiert werden. Dieses wird zum Ausführen der Java-Applikation verwendet.