Anderes (schlechteres) Font-Rendering in OpenJDK 8

[inflamer]

Hallo,

womöglich ist dem einen oder anderen, der noch mit Java 8 arbeitet, aufgefallen, dass die gängigen alternativen Java 8-Binaries wie etwa das von AdoptOpenJDK ein anderes, und zwar leider merkbar schlechteres Font-Rendering mitbringen als das originale Java 8 von Oracle. (Habe auch das von Zulu oder wie das heißt ausprobiert - dort ist das gleche Problem.)

An sich kann man auch damit leben, wenn in der eigenen Anwendung die Darstellung von Schrift nicht gerade besondere Relevanz hat, was bei mir allerdings sehr wohl der Fall ist.

Ich habe nach dem Problem auch schon gegoogelt - das Ganze scheint auch anderen Usern aufgefallen zu sein. Leider wird als Lösung stets das Setzen irgendwelcher Windows-Umgebungsvariablen vorgeschlagen, was unpraktisch ist, wenn dies vom Enduser verlangt werden muss.

Meine Frage daher: Gibt es hierfür eine andere Lösung? (Manipulation irgendwelcher Config-Dateien in der JRE o.ä.)
Danke!

PS: Neuere OpenJDK-Versionen (von mir getestet wurden jedenfalls 11 und 17) scheinen wieder das ursprüngliche Font-Rendering zu nutzen, dort gibt es das Problem nicht. Das aber nur der Vollständigkeit halber.

 

[yfons123]

Neuere OpenJDK-Versionen (von mir getestet wurden jedenfalls 11 und 17) scheinen wieder das ursprüngliche Font-Rendering zu nutzen, dort gibt es das Problem nicht.

warum nicht einfach das ?

 

[inflamer]

warum nicht einfach das ?

Der Grund ist (der hier hoffentlich nicht zu weit führt), dass in Java 8 die einstmals entfernte Unterstützung von ODBC mit einem kleinen Trick wieder hergestellt werden kann, indem man ein paar kleine Dateien aus Java 7 übernimmt:

Removal of JDBC ODBC bridge in java 8

Starting with Java 8, the JDBC-ODBC Bridge will no longer be included with the JDK. Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); // classNotFoundException is thrown Is there any other solution

stackoverflow.com

In Java 11 bekomme ich dies leider bisher nicht hin. Das wäre allerdings sogar die bessere Lösung...

 

[yfons123]

2

You should not use the JDBC-ODBC bridge in a production environment. It is much slower than other JDBC drivers and only necessary when a JDBC driver is not available.

SQL Server has a JDBC driver available from Microsoft. If you use it then you will get the required result.

With the ODBC bridge you have no choice but to install the ODBC driver.

This article describes the connection string you will need to use to connect to the SQL Server.

2

Do NOT use the JDBC-ODBC bridge driver. That was meant purely for testing, not for production. You can still make your application database agnostic using drivers that are optimized for the database you want to connect to. Just externalize the username, password database driver name and connect string, and don't use any DB-specific SQL and you should be fine.

For connecting to SQL Server, use the jTDS driver http://jtds.sourceforge.net/ The connect string format looks like this:

jdbc:jtds:sqlserver://localhost/my_database

There are a few other parameters you can include, separated by semicolons, but I think this is all that's required. Obviously when you connect, you'll need to supply a username and password

Connecting to SQLServer using JDBC-ODBC Bridge

I'm writing an applicationt hat was prototyped on MySQL and is now connecting to an Oracle database. All I had to do to connect to the oracle database (having built up the table structure) was cha...

stackoverflow.com

 

[inflamer]

Genau diese Diskussion über Sinn und Unsinn von ODBC wollte ich an dieser Stelle eigentlich vermeiden. Daher nur in Kürze, und alle weiteren Anworten dann bitte unmittelbar zum eigentlichen Thema, wenn es geht. Unter anderem der JDBC-Treiber für MS SQL stößt mit Knall an seine Grenzen, wenn die Ports vom Server dynamisch vergeben werden. Der entsprechende ODBC-Treiber kann hingegen bestens damit umgehen.

 

[mrBrown]

Was meinst du in dem Fall mit dynamisch vergebenen Ports und zu welchen Problemen führen die?

(da das so ein „jdbc wirft Fehler weshalb du odbc nutzt weshalb du java 8 nutzt weshalb du Font-Probleme hast“-Ding ist, macht es durchaus auch Sinn, mal das erste Problem in der Kette anzugucken. Probleme hast du sonst immer wieder)

 

[inflamer]

Ok, manche SQL-Server nutzen wohl aus Sicherheitsgründen nicht den Standard-Port 1433, sondern vergeben eine Random-Portnummer, eben eine dynamische.

Nun las ich vorher im JDBC-Tutorial von Microsoft folgendes:

Building the connection URL - JDBC Driver for SQL Server

Article about formatting the connection string used by the Microsoft JDBC Driver for SQL Server. Samples of connection strings are included in the examples section.

docs.microsoft.com

Zitat: "portNumber (Optional) is the port to connect to on serverName. The default is 1433. If you're using the default, you don't have to specify the port, nor its preceding ':', in the URL."

Für mich klang das so, dass wenn man an den JDBC-Treiber keine Portnummer übergibt, schlicht die 1433 benutzt wird, also nix mit dynamisch.

Wie das aber halt so ist, googelt man (oder: ich) gerne nochmal das Thema wenn man mal was im Forum geschrieben hat, einfach um zu prüfen, dass man keinen Müll geschrieben hat...

Jetzt habe ich hier nochmal was anderes gefunden, was im MS-Tutorial (oben) gar nicht erwäht wird:

Instance Name Better than Port Number

This section describes how SQL Server support JDBC client applications to use instance name instead of port number to connect to a specific instance.

www.herongyang.com

Zitat: "If you specify an instance name in the connection request, the JDBC Driver is smart to make a UDP call first to the SQL Server Browser with the instance name. The SQL Server Browser will return the port number of the given instance. Then the JDBC Driver will a TCP connection on that port number."

Das soll also doch gehen mit dynamischer Portnummer, und zwar indem man statt einer Portnummer den Namen der jeweiligen Instanz an den JDBC-Treiber übergibt. Das muss ich dann eben nochmal ausprobieren. Insofern schon mal ein Fortschritt.

ODBC hätte ich aber trotzdem gerne in meiner Anwendung dabei, wenn auch bloß als Zusatzoption zu JDBC...

Sorry für den langen Text.

 

[KonradN]

Du wirfst extrem viel durcheinander. Also diverse SQL Server nutzen unterschiedliche Ports. Der MS SQL Server hat einen Default Port von 1433. Aber Postgresql hat z.B. 5432 als Default Port ....

Jedes Produkt hat das, was der Entwickler gerade nehmen wollte.

Und als Entwickler interessiert Dich sowas nicht! Du greifst auf eine MS SQL Datenbank zu, d.h. ein Admin muss
A) das installieren und konfigurieren
B) dir einen Connectin String geben
Dabei kann der Admin frei machen, was er will! Da kann er einen Port seiner Wahl nutzen. Oder einen Instanznamen seiner Wahl. Das ist seine Verantwortung!

Du bekommst die URL und nutzt diese. Nicht mehr und nicht weniger.

Und da ODBC als Fallback zu haben: was für Autos kaufst du dir denn? Es ist doch verdammt schwer, Autos zu bekommen, die du noch mit einer Kurbel vorne anwerfen kannst. (Das wäre vermutlich der passende Auto-Vergleich).

Alleine schon der Support von ODBC ist schlicht Hölle mit Treibern, der Konfiguration und und und .... Das ist nicht ohne Grund rausgeflogen.

Von daher: nimm Admins nicht deren Job ab. Egal was du machst: ein Admin kann es so einrichten, dass es nicht mehr geht was du dir ausgedenkt hast. Daher bleib beim Standard! Lass den Admin frei walten und er soll dir dann einen Connection String geben!

 

[inflamer]

@Konrad. Das Prob ist halt, dass manchmal eben nicht der Admin die Ports vergibt, sondern der Server selbst (in dem Fall MS SQL) es tut, und zwar indem er willkürlich irgendeine beliebige Nummer wählt. Diese Nummer ist dazu auch noch bei jedem Neustart des Servers eine andere, der Admin ist da fein raus sozusagen.

Zu ODBC: Die User wollen auf Gedeih und Verderb ODBC, ich muss mich leider dran halten. Na gut, ich möchte es doch sehr gerne, wenn es denn geht.

Ehrlich gesagt versteh ich den schlechten Ruf davon nicht, ein Meer von Anwendungen nutzt ODBC. Und wenn man damit nicht gerade supa-dupa akkrobatische Kunststücke machen will, sondern deine Anwendung es schlicht dazu nutzt, um einfach mal Daten zu importieren, dann ist doch nichts dran auszusetzen, oder?

 

[yfons123]

indem er willkürlich irgendeine beliebige Nummer wählt.

hört sich sehr nach schiffe versenken an

 

[inflamer]

hört sich sehr nach schiffe versenken an

Oder nach einem Smartphone, wenn man sich damit einem W-LAN-Router nähert

 

[KonradN]

Das Meer an Applikationen, das ODBC nutzt, kann ich nicht sehen. Maximal alte Legacy Applikationen nutzen das ggf. noch (was ich so sehe)

Da es obsolet ist, wurde es bei Java heraus genommen.

Und 'einfach Mal Daten importieren' ist aus meiner Sicht nicht: Installiere erst einmal den ODBC Treiber.... das ist ja schon eine Komplexität mehr als notwendig.

Und die Nutzung alter Technologie auf nicht unterstützten Wegen ist auch etwas, das mir Bauchschmerzen bereiten würde.

Aber ist ok, dann mach ruhig weiter mit ODBC.

 

[Neumi5694]

Ich muss mich noch mit Access-DBs rumschlagen, das geht ganz gut über UCanAccess.
Problematisch wird's wenn in diesen Dateien Tabellen auf ODBC-Tabellen verlinkt sind. Ging in Java8 noch mit einer JDBC-ADO Bridge, die jetzt aber nicht mehr verwendet werden kann.
UCanAccess kann das leider nicht. Aktuell hab ich noch keine Lösung dafür gefunden.

 

[Oneixee5]

Ich mache sehr wenig mit MSSQL. Ich benötige aber gar keine Portnummer für die Verbindung, es wird einfach serverName/instanceName verwendet. Daher erscheint mir das Problem ziemlich unverständlich. Microsoft selbst hat ODBC aufgegeben und soll keine funktionierende Alternative anbieten - das glaube ich einfach nicht.

 

[Robert Zenz]

Ich habe nach dem Problem auch schon gegoogelt - das Ganze scheint auch anderen Usern aufgefallen zu sein. Leider wird als Lösung stets das Setzen irgendwelcher Windows-Umgebungsvariablen vorgeschlagen, was unpraktisch ist, wenn dies vom Enduser verlangt werden muss.

Meine Frage daher: Gibt es hierfür eine andere Lösung? (Manipulation irgendwelcher Config-Dateien in der JRE o.ä.)

Du kannst auch die Umgebungsvariablen selbst setzen in der main Methode. System.setProperty setzt diese aber nur innerhalb der Java VM, sollte aber eigentlich ausreichen. Ansonsten kannst du ganz einfach mit JNA die native Bibliothek ansprechen um die Umgebungsvariablen des Prozesses zu ergaenzen. Auf Linux sind das mit JNA zumindest nur 10 Zeilen oder so insgesamt.[/icode]

 

[Neumi5694]

Ich mache sehr wenig mit MSSQL. Ich benötige aber gar keine Portnummer für die Verbindung, es wird einfach serverName/instanceName verwendet. Daher erscheint mir das Problem ziemlich unverständlich. Microsoft selbst hat ODBC aufgegeben und soll keine funktionierende Alternative anbieten - das glaube ich einfach nicht.

Ich kann's mir schon vorstellen. Lokale Systeme sind überholt, kaum jemand verwaltet noch noch mehrer Datenbanksysteme auf einem Windows-Rechner. Es ergibt eigentlich auch nur dann Sinn, wenn man eine eingebundene Tabelle mit anderen per Abfrage verknüpfen will und das wird immer mehr obsolet. Daten kommen immer öfter von Webservices und - falls überhaupt - von direktem DB-Zugriff.

Es sind allerdings noch viele Legacy-Programme im Umlauf, die das nutzen und es gibt reichlich Leute, die nach einer Alternative suchen, damit die auch auf modernen Systemen noch laufen.

 

[inflamer]

Danke für die vielen hilfreichen Antworten. Zumindest das Problem mit MS SQL konnte ich schließlich lösen:

An den JDBC-Treiber einfach keine Portnummer übergeben, stattdessen nur den Namen der Datenbank-Instanz (eben so, wie von einem anderen User hier nochmal zusätzlich bestätigt). Dabei muss der Dienst "SQL Server Browser" auf dem Server aktiv sein. Bei diesem erfragt der Treiber dann über den UDP-Port 1434 den "eigentlichen" TCP-Port. Ende.

Dummerweise wird all das in der "offiziellen" Microsoft-Dokumentation zu deren JDBC-Treiber, wie gesagt, mit keinem Wort erwähnt. Wo es erwähnt wird, habe ich weiter oben ja schon mal verlinkt.

Das Prob mit dem Font Rendering scheint allerdings noch etwas komplexer geartet zu sein als gedacht. Falls ich's doch noch hinbekomme, werde ich die Lösung hier entsprechend kurz niederschreiben...

 

[KonradN]

Die Dokumentation, die Du vermisst, ist Bestandteil der SQL Server Dokumentation. Und daher: Der Administrator sollte sagen, wie sein Server zu erreichen ist. Deine Lösung mag jetzt für Dich funktionieren, aber in einem anderen Umfeld kann der SQL Server browser deaktiviert worden zu sein.

Welche Ports wie benutzt werden, findet man z.B. unter https://docs.microsoft.com/en-us/sq...allow-sql-server-access?view=sql-server-ver15

Es gibt viele Möglichkeiten einen Server zu konfigurieren. Davon hängt ab, wie auf den Server zugegriffen werden kann. Und der Administrator ist verantwortlich dafür. Daher ist die generelle Antwort schlicht: Frag den Admin und nutze die Daten, die er Dir gibt. (Und wenn der server sich Ports heraus sucht, dann hat der Admin dies eingestellt - dann ist das Feature Dynamic Ports aktiv. Das ist aber nur ein Feature und das kann aktiv sein aber muss nicht.)

Das nur noch einmal als dezenter Hinweis, nicht dass Du Dich wunderst, dass es irgendwann evtl. nicht mehr geht oder woanders nicht geht.

 

[inflamer]

@Konrad. Danke für den Tipp! In meinem Proggi, welches ein Client ist, wo der Enduser die Verbindungsparameter eingibt, sind nun beide Möglichkeiten soweit abgedeckt - statische und dynamische Ports. Bei einem dynamischen Port muss er im Notfall - wenn denn kein "SQL Server Browser"-Service läuft, dann halt tatsächlich den Admin nach der Port-Nr fragen. Das ist dann sozusagen seine Angelegenheit.

 

[yfons123]

@Konrad. Danke für den Tipp! In meinem Proggi, welches ein Client ist, wo der Enduser die Verbindungsparameter eingibt, sind nun beide Möglichkeiten soweit abgedeckt - statische und dynamische Ports. Bei einem dynamischen Port muss er im Notfall - wenn denn kein "SQL Server Browser"-Service läuft, dann halt tatsächlich den Admin nach der Port-Nr fragen. Das ist dann sozusagen seine Angelegenheit.

warum soll sich ein client direkt über den Port mit der sql db verbinden dürfen?

 

[inflamer]

warum soll sich ein client direkt über den Port mit der sql db verbinden dürfen?

Bei MySQL ist das z.B. der Normalfall, bin mir nicht sicher ob es da überhaupt ohne Portangabe geht... Ich bin noch weniger MS SQL-Kenner, aber solche Konfigurationen (mit Port als Pflichtangabe) wird es in der "freien Wildbahn" doch wohl auch geben oder? Z.B. eben dann, wenn kein "SQL Server Browser"-Service läuft... Dann geht's doch gar nicht ohne Port, oder?

 

[KonradN]

warum soll sich ein client direkt über den Port mit der sql db verbinden dürfen?

Wo siehst du denn Probleme?

Bei Verbindungen über tcp/ip benötigt man nun einmal auch einen Port. Dieser kann festgelegt sein oder dynamisch beim Start vergeben werden. Bei dynamischen Ports muss der Port halt erst angefragt werden, aber am Ende ist es einfach eine direkte tcp/ip Verbindung zu einer SQL Server Instanz.

Bei MySQL ist das z.B. der Normalfall, bin mir nicht sicher ob es da überhaupt ohne Portangabe geht... Ich bin noch weniger MS SQL-Kenner, aber solche Konfigurationen (mit Port als Pflichtangabe) wird es in der "freien Wildbahn" doch wohl auch geben oder? Z.B. eben dann, wenn kein "SQL Server Browser"-Service läuft... Dann geht's doch gar nicht ohne Port, oder?

Wobei mysql auch einen default Port hat und wenn die Datenbank auf dem default Port läuft, dann muss man diesen nicht angeben.

So man nur ein MS SQL Server Instanz laufen lassen will, dann wird in der Regel die Default Instanz (MSSQLSERVER wäre der Name der default instance) verwendet und diese hört eigentlich immer auf 1433. ==> Da muss man dann also weder Port noch Instanzname angeben.

Aber generell ist jede Instanz beliebig konfigurierbar. So ist es möglich, da beliebige Ports zu nutzen. Dazu einfach SQL Server Configuration Manager starten, da dann auf die Instanz gehen und bei den Protocols auf TCP/IP gehen und die Eigenschaften öffnen. Da ist dann alles konfigurierbar. Wenn man einen SQL Server aufsetzt, dann muss man da eh rein, denn per Default dürfte tcp/ip deaktiv sein. Shared Memory und Named Pipes sind die aktiven Zugriffsmöglichkeiten meine ich (So sich das in den letzten Jahren nicht geändert hat).

Das kann man übrigens frei ausprobieren. SQL Server Developer Edition ist frei verfügbar und läuft (dank Docker Image) auch unter Linux und auf Macs. Wenn einen sowas interessiert, dann kann ich also nur dazu raten, sich das einfach mal im Detail anzusehen.

Für die reine Java Entwicklung mit Zugriff auf MS SQL Server ist dies aber nicht notwendig. Da würde einfach die URL konfigurierbar gemacht und z.B. in einem Properties File abgelegt. Dann kann da jeder einen beliebigen Connection String hinterlegen.

Noch paar Dinge zu JDBC und MS SQL, weil es mir gerade so durch den Kopf geht:

- Ich weiss nicht, ob Microsoft nachgelegt hat beim JDBC Treiber. Named Pipes wurden damals nicht unterstützt. Da ist dann z,B. http://jtds.sourceforge.net/features.html interessant.

- Windows Integrated Authentication ist in Windows Umgebungen das, was ich als üblich ansehen würde und das verwendet werden sollte. ==> Keine Speicherung von User / Passwort Kombinationen! -> Setzt aber halt Windows und eine Domain voraus.