Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #38852 > unrolled thread

more porting issues to Java 11

Back to article view | Back to comp.lang.java.programmer

Contents

  more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-04-03 17:21 +0000
    Re: more porting issues to Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2019-04-03 14:28 -0400
      Re: more porting issues to Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2019-04-03 14:32 -0400
        Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-04-04 12:52 +0000
          Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-04-04 14:11 +0000
            Re: more porting issues to Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2019-04-04 20:08 -0400
    Re: more porting issues to Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2019-04-03 14:37 -0400
      Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-04-04 13:04 +0000
        Re: more porting issues to Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2019-04-04 20:22 -0400
          Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-04-08 16:40 +0000
            Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-04-08 17:14 +0000
              Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-04-10 18:08 +0000
                Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-04-10 18:32 +0000
                Re: more porting issues to Java 11 Sebastian <nowhere@nirvana.org> - 2019-04-11 11:05 +0200
                  Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-04-29 08:23 +0000
                Re: more porting issues to Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2019-04-12 10:08 -0400
                  Re: more porting issues to Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2019-04-12 07:35 -0700
                Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-04-29 08:39 +0000
                  Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-05-03 13:10 +0000
                    Re: more porting issues to Java 11 Knute Johnson <groups@585ranch.com> - 2019-05-04 11:24 -0500
                      Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-05-04 21:58 +0000
                        Re: more porting issues to Java 11 Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2019-05-06 11:25 -0500
                          Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-05-29 12:20 +0000
                            Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2020-01-30 15:07 +0000
            Re: more porting issues to Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2019-04-08 18:41 -0400
              Re: more porting issues to Java 11 Sebastian <nowhere@nirvana.org> - 2019-04-10 15:46 +0200
                Re: more porting issues to Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2019-04-10 12:31 -0400
              Re: more porting issues to Java 11 Andreas Leitgeb <avl@logic.at> - 2019-04-10 18:13 +0000
                Re: more porting issues to Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2019-04-13 20:39 -0400

Page 1 of 2  [1] 2  Next page →

#38852 — more porting issues to Java 11

My application unfortunately uses a couple of features that were removed
in Java 11.

One, of which I was a bit more optimistic of finding a substitute was the
package hierarchy javax.xml.bind  and in particular (among others) the classes
  JAXBContext, Marshaller and Unmarshaller
therein.

Some googling led me to:
  https://blog.codefx.org/java/java-11-migration-guide/
and a section named "Fixes", that names "JAXB: com.sun.xml.bind:jaxb-impl" ->
   https://search.maven.org/search?q=g:com.sun.xml.bind%20AND%20a:jaxb-impl&core=gav
of which I picked the latest 2.3.2 (Jan '19)

Now it seems I don't really have a grasp on the problem yet, because
the jarfile I got from maven didn't have either of the classes mentioned
above - it had some *Impl classes in entirely different packages, but
not the said ones. And even  JAXBContextImpl  didn't have the static
method "newInstance(Class)" that is expected in my code, thus isn't
a substitute for JAXBContext.


Another problem will be Corba:
I've been using JacORB for the Corba implementation so far, but it
just doesn't include the central interfaces and stubs that once were
in the jdk).
When just running the old compiled code with new Java 11, then a
java.lang.NoClassDefFoundError is thrown for nonexistant class
javax/rmi/CORBA/Stub, and the stacktrace reveals, that JacORB
is the one who attempted to use/load it - in particular from
org.jacorb.orb.ORB._getDelegate(ORB.java:586)   (JacORB 3.9)

[toc] | [next] | [standalone]

#38856

On 4/3/2019 1:21 PM, Andreas Leitgeb wrote:
> My application unfortunately uses a couple of features that were removed
> in Java 11.
> 
> One, of which I was a bit more optimistic of finding a substitute was the
> package hierarchy javax.xml.bind  and in particular (among others) the classes
>    JAXBContext, Marshaller and Unmarshaller
> therein.
> 
> Some googling led me to:
>    https://blog.codefx.org/java/java-11-migration-guide/
> and a section named "Fixes", that names "JAXB: com.sun.xml.bind:jaxb-impl" ->
>     https://search.maven.org/search?q=g:com.sun.xml.bind%20AND%20a:jaxb-impl&core=gav
> of which I picked the latest 2.3.2 (Jan '19)
> 
> Now it seems I don't really have a grasp on the problem yet, because
> the jarfile I got from maven didn't have either of the classes mentioned
> above - it had some *Impl classes in entirely different packages, but
> not the said ones. And even  JAXBContextImpl  didn't have the static
> method "newInstance(Class)" that is expected in my code, thus isn't
> a substitute for JAXBContext.

I go to:

https://javaee.github.io/jaxb-v2/

Download:

https://repo1.maven.org/maven2/com/sun/xml/bind/jaxb-ri/2.3.1/jaxb-ri-2.3.1.zip

Unzip.

Add all jar files in the mod dir to classpath.

And my JAXB example works.

Actually I did only need:

istack-commons-runtime.jar
javax.activation-api.jar
jaxb-api.jar
jaxb-runtime.jar

But OK that is only version 2.3.1.

Let me see if I can find 2.3.2 as well.

Arne

[toc] | [prev] | [next] | [standalone]

#38857

On 4/3/2019 2:28 PM, Arne Vajhøj wrote:
> On 4/3/2019 1:21 PM, Andreas Leitgeb wrote:
>> My application unfortunately uses a couple of features that were removed
>> in Java 11.
>>
>> One, of which I was a bit more optimistic of finding a substitute was the
>> package hierarchy javax.xml.bind  and in particular (among others) the 
>> classes
>>    JAXBContext, Marshaller and Unmarshaller
>> therein.
>>
>> Some googling led me to:
>>    https://blog.codefx.org/java/java-11-migration-guide/
>> and a section named "Fixes", that names "JAXB: 
>> com.sun.xml.bind:jaxb-impl" ->
>>     
>> https://search.maven.org/search?q=g:com.sun.xml.bind%20AND%20a:jaxb-impl&core=gav 
>>
>> of which I picked the latest 2.3.2 (Jan '19)
>>
>> Now it seems I don't really have a grasp on the problem yet, because
>> the jarfile I got from maven didn't have either of the classes mentioned
>> above - it had some *Impl classes in entirely different packages, but
>> not the said ones. And even  JAXBContextImpl  didn't have the static
>> method "newInstance(Class)" that is expected in my code, thus isn't
>> a substitute for JAXBContext.
> 
> I go to:
> 
> https://javaee.github.io/jaxb-v2/
> 
> Download:
> 
> https://repo1.maven.org/maven2/com/sun/xml/bind/jaxb-ri/2.3.1/jaxb-ri-2.3.1.zip 
> 
> 
> Unzip.
> 
> Add all jar files in the mod dir to classpath.
> 
> And my JAXB example works.
> 
> Actually I did only need:
> 
> istack-commons-runtime.jar
> javax.activation-api.jar
> jaxb-api.jar
> jaxb-runtime.jar
> 
> But OK that is only version 2.3.1.
> 
> Let me see if I can find 2.3.2 as well.

https://github.com/eclipse-ee4j/jaxb-ri

https://github.com/eclipse-ee4j/jaxb-ri/releases/download/2.3.2-RI/jaxb-ri-2.3.2.zip

has the same mod dir with jar files.

I am willing to guess that they also work.

Arne

[toc] | [prev] | [next] | [standalone]

#38860

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/3/2019 2:28 PM, Arne Vajhøj wrote:
>> On 4/3/2019 1:21 PM, Andreas Leitgeb wrote:
>>> My application unfortunately uses a couple of features that were removed
>>> in Java 11.
>>> One, of which I was a bit more optimistic of finding a substitute was the
>>> package hierarchy javax.xml.bind  and in particular (among others) the 
>>> classes
>>>    JAXBContext, Marshaller and Unmarshaller
>>> therein.
>> I go to:
> https://github.com/eclipse-ee4j/jaxb-ri
> https://github.com/eclipse-ee4j/jaxb-ri/releases/download/2.3.2-RI/jaxb-ri-2.3.2.zip

Thanks, they did indeed contain the sought classes.

For a short time it even looked like I'd be getting on, until...

after adding all the jars from jaxb-ri-2.3.2, Eclipse still
didn't find some other classes e.g. org.w3c.dom.Document .

I scanned local repositories for jar-files containing that class
and found some "xml-apis-1.4.01.jar" - it doesn't matter where it
was from and how old it was, because the gist of my problem doesn't
involve it.) 

After adding that jar file it *no longer* knew other stuff like
javax.xml.namespace.NamespaceContext, so I removed the jar again, and
looked for where it had found javax.xml.namespace.NamespaceContext
before: in jdk-11 module "java.xml"  - and this very module has
"org.w3c.dom.Document" sitting there as well!

Now, the new question driving me crazy is: why doesn't eclipse find
org.w3c.dom.Document, when it perfectly well can find
javax.xml.namespace.NamespaceContext almost right next to the other,
and why doesn't it find javax.xml.namespace.NamespaceContext anymore
once I add a jar file with org.w3c.dom.Document ?.

[toc] | [prev] | [next] | [standalone]

#38864

Andreas Leitgeb <avl@logic.at> wrote:
> Now, the new question driving me crazy is: why doesn't eclipse find
> org.w3c.dom.Document, when it perfectly well can find
> javax.xml.namespace.NamespaceContext almost right next to the other,
> and why doesn't it find javax.xml.namespace.NamespaceContext anymore
> once I add a jar file with org.w3c.dom.Document ?.

Well, after a pause to cool down from fury, I now got to not just look
at the red wavy lines, but actually trying to understand their message...

It turned out, that some of the jar files in the classpath were really
too much, because the message really said, that the particular packages
were found both in unnamed and some of Java's modules.

Kicking those jars out of the classpath was the way to go.

Remains the quest for some JDK11-compatible Corba...

[toc] | [prev] | [next] | [standalone]

#38869

On 4/4/2019 10:11 AM, Andreas Leitgeb wrote:
> Andreas Leitgeb <avl@logic.at> wrote:
>> Now, the new question driving me crazy is: why doesn't eclipse find
>> org.w3c.dom.Document, when it perfectly well can find
>> javax.xml.namespace.NamespaceContext almost right next to the other,
>> and why doesn't it find javax.xml.namespace.NamespaceContext anymore
>> once I add a jar file with org.w3c.dom.Document ?.
> 
> Well, after a pause to cool down from fury, I now got to not just look
> at the red wavy lines, but actually trying to understand their message...
> 
> It turned out, that some of the jar files in the classpath were really
> too much, because the message really said, that the particular packages
> were found both in unnamed and some of Java's modules.
> 
> Kicking those jars out of the classpath was the way to go.
:-)

I will consider to be "as expected" that one can get JAXB working
in Java 11 as JAXB is a current technology.

Arne

[toc] | [prev] | [next] | [standalone]

#38858

On 4/3/2019 1:21 PM, Andreas Leitgeb wrote:
> Another problem will be Corba:
> I've been using JacORB for the Corba implementation so far, but it
> just doesn't include the central interfaces and stubs that once were
> in the jdk).
> When just running the old compiled code with new Java 11, then a
> java.lang.NoClassDefFoundError is thrown for nonexistant class
> javax/rmi/CORBA/Stub, and the stacktrace reveals, that JacORB
> is the one who attempted to use/load it - in particular from
> org.jacorb.orb.ORB._getDelegate(ORB.java:586)   (JacORB 3.9)

Say hi to the 1990's.

:-)

The latest JacORB release predates Java 11.

The two most obvious solutions IMHO:
* let that CORBA stuff continue to run on Java 8
* find another Java CORBA implementation that supports
   Java 11

Trying to use Java 11 + some CORBA classes from X + JacORB
to work seems risky to me.

Arne

[toc] | [prev] | [next] | [standalone]

#38862

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/3/2019 1:21 PM, Andreas Leitgeb wrote:
>> Another problem will be Corba:
>> I've been using JacORB for the Corba implementation so far, but it
>> just doesn't include the central interfaces and stubs that once were
>> in the jdk).
>> When just running the old compiled code with new Java 11, then a
>> java.lang.NoClassDefFoundError is thrown for nonexistant class
>> javax/rmi/CORBA/Stub, and the stacktrace reveals, that JacORB
>> is the one who attempted to use/load it - in particular from
>> org.jacorb.orb.ORB._getDelegate(ORB.java:586)   (JacORB 3.9)
>
> Say hi to the 1990's.

I "inherited" maintenance of that program in the early 2000s, and
these say "hi, back" :-)

> The two most obvious solutions IMHO:
> * [...]
> * find another Java CORBA implementation that supports
>    Java 11

For this one, I hoped that asking here on c.l.j.p might push me
a bit along that way...

[toc] | [prev] | [next] | [standalone]

#38870

On 4/4/2019 9:04 AM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> The two most obvious solutions IMHO:
>> * [...]
>> * find another Java CORBA implementation that supports
>>     Java 11
> 
> For this one, I hoped that asking here on c.l.j.p might push me
> a bit along that way...

Fair enough.

The most promising candidate from googling seems to be:

https://github.com/eclipse-ee4j/orb

Arne

[toc] | [prev] | [next] | [standalone]

#38883

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/4/2019 9:04 AM, Andreas Leitgeb wrote:
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> The two most obvious solutions IMHO:
>>> * [...]
>>> * find another Java CORBA implementation that supports
>>>     Java 11
>> For this one, I hoped that asking here on c.l.j.p might push me
>> a bit along that way...
> Fair enough.
> The most promising candidate from googling seems to be:
> https://github.com/eclipse-ee4j/orb

Promising indeed (given that latest change in the repo was
only 7days ago), thanks.

My attempt to compile it (using maven and jdk 11) however failed with
a couple of errors about missing several packages like org.omg.CORBA
and others below it.

literal example (long line) :

[ERROR] /home/avl/RNVS/ORB/csiv2-idl/target/generated-sources/idl/com/sun/corba/ee/org/omg/CSI/MessageInContext.java:[11,70] package org.omg.CORBA.portable does not exist

So, either it just isn't jdk11-ready yet, or I've been doing something
wrong. (although it seems hard to do something wrong with "mvn compile")
If it does work for someone else, and it didn't just pick an older javac,
then I'd like to know

PS: I'd also appreciate hints about what people are *supposed* to use
 instead of corba nowadays. (Server is in C++ and client in Java, and
 getting them into the same language is infeasible.)

[toc] | [prev] | [next] | [standalone]

#38884

I'm posting updates of my progress:  (FWI maybe W)

> My attempt to compile it (using maven and jdk 11) however failed with
> a couple of errors about missing several packages like org.omg.CORBA
> and others below it.

That was in "CSIv2 APIs".  I could solve that by adding the omgapi
module as a dependency to csiv2-idl/pom.xml  - seems like I'm slowly
getting the hang of maven's pom files)

(Once I get to see some light at end of tunnel, I'll PR it on github)


Now I get a similar error about package javax.transaction and will
continue to search for what dependency to add where... tomorrow.

[toc] | [prev] | [next] | [standalone]

#38896

Next update:    (tl;dr? SimpleDateFormat also changed behaviour)

Synchronous with my own sorry attempts, there was also some action on
glassfish side. Some user posted a PR that made the glassfish ORB
compileable with maven and jdk 11. (It's not yet merged, and it
depends on some other package that isn't yet released to maven repo,
thus needs some extra hoop-diving to let "mvn" find it, but there is
some progress).

For now I only succeeded in getting un-encrypted Corba working -
to use encryption I would now need a client-side keystore (didn't
need that back with an older version of JacORB).
Not ok for production, of course, but enough to allow me to check
other corners of the application:


Next obstacle was SimpleDateFormat:  jdk-8 had no problem at all with
parsing a (German style) "10.04.2019 19:44:45" string with a DateFormat
defined like this: (SSCCE and results further down)
  final int dfMed = DateFormat.MEDIUM; final Locale l_de=new Locale("de","DE");
  DateFormat df   =  DateFormat.getDateTimeInstance(dfMed,dfMed,l_de);

For jdk11, the string would now need a comma "," between date and time 
parts. the blank isn't acceptable any more.


--- snip SSCCE: Foo.java ---
import java.text.DateFormat;
import java.util.Date;
import java.text.ParseException;
import java.util.Locale;

class Foo {
   public static void main(String... args) {
      final int dfMed = DateFormat.MEDIUM;
      final Locale l_de=new Locale("de","DE");
      DateFormat     dfM = DateFormat.getDateTimeInstance(dfMed,dfMed,l_de);
      dfM.setLenient(true);

      String text = "10.04.2019 19:44:45";

      try {
         Date result = dfM.parse(text);
         System.out.println( result );
      } catch (ParseException dfe) {
         System.out.println( dfe );
      }
   }
}
--- end snip --- 
jdk-8:  Wed Apr 10 19:44:45 CEST 2019
jdk-11: java.text.ParseException: Unparseable date: "10.04.2019 19:12:04"
        (That it expected a comma, I learned from a debugging session)

[toc] | [prev] | [next] | [standalone]

#38898

Andreas Leitgeb <avl@logic.at> wrote:
> --- end snip --- 
> jdk-8:  Wed Apr 10 19:44:45 CEST 2019
> jdk-11: java.text.ParseException: Unparseable date: "10.04.2019 19:12:04"

Apparently I forgot one place of changing the time part
from when I made the SSCCE to roughly when I posted it.

[toc] | [prev] | [next] | [standalone]

#38899

Am 10.04.2019 um 20:08 schrieb Andreas Leitgeb:
> Next update:    (tl;dr? SimpleDateFormat also changed behaviour)
> 
[snip]
> 
> Next obstacle was SimpleDateFormat:  jdk-8 had no problem at all with
> parsing a (German style) "10.04.2019 19:44:45" string with a DateFormat
> defined like this: (SSCCE and results further down)
>    final int dfMed = DateFormat.MEDIUM; final Locale l_de=new Locale("de","DE");
>    DateFormat df   =  DateFormat.getDateTimeInstance(dfMed,dfMed,l_de);
> 
> For jdk11, the string would now need a comma "," between date and time
> parts. the blank isn't acceptable any more.
> 
[snip]

Starting in JDK 9, the Unicode Consortium's Common Locale Data 
Repository (CLDR) data is enabled as the default locale data, so that 
you can use standard locale data without any further action.

In JDK 8, although CLDR locale data is bundled with the JRE, it isn't 
enabled by default.

Code that uses locale-sensitive services such as date, time, and number 
formatting may produce different results with the CLDR locale data.

To enable behavior compatible with JDK 8, set the system property 
java.locale.providers to a value with COMPAT ahead of CLDR, for example, 
java.locale.providers=COMPAT,SPI,CLDR. This will have the same behavior 
with the prior JDK releases.

The system property itself dates from Java 8. From the documentation of 
LocaleServiceProvider: “Starting from JDK8, the search order of locale 
sensitive services can be configured by using the 
"java.locale.providers" system property.”

What would be the alternative to using compatibility mode? Answer: 
Sticking to CLDR would most likely imply having to change some patterns 
in the app, e. g. "u" should be used for years for week-based formatting 
or with strict resolvers, the short date format changed from d-M-yy to 
dd-MM-yy, distinguishing between format and standalone style (e vs. c in 
the case of months and perhaps more).

All of this would probably require switching entirely to the standard 
Java date and time API instead of using the outdated SimpleDateFormat 
and relatives, which don't support all of the new format fields or use 
them with a different meaning. Using the old date time classes together 
with GLDR as a data source cannot be recommended.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#38938

Sebastian <nowhere@nirvana.org> wrote:
> Am 10.04.2019 um 20:08 schrieb Andreas Leitgeb:
> [snip]
>> Next obstacle was SimpleDateFormat:  jdk-8 had no problem at all with
>> parsing a (German style) "10.04.2019 19:44:45" string with a DateFormat
>>    DateFormat df   =  DateFormat.getDateTimeInstance(dfMed,dfMed,l_de);
>> For jdk11, the string would now need a comma "," between date and time
>> parts. the blank isn't acceptable any more.
Afternote: the new format would have expected comma and blank between 
date and time.

> Starting in JDK 9, the Unicode Consortium's Common Locale Data 
> Repository (CLDR) data is enabled as the default locale data, so that 
> you can use standard locale data without any further action.
[snip]
> To enable behavior compatible with JDK 8, set the system property 
> java.locale.providers to a value with COMPAT ahead of CLDR, for example, 
> java.locale.providers=COMPAT,SPI,CLDR. This will have the same behavior 
> with the prior JDK releases.

Indeed, that was it.  Setting the property worked as expected, but I 
decided to change creation of DateFormat instances to use exactly the 
format I want.   (There were only a couple of places in my code)

I now use     new SimpleDateFormat("dd.MM.yyyy HH:mm:ss");
The literal String here is really a constant defined in a central place.
That's the spec of the strings I need to parse and it was only "coincidence"
that it even corresponded to German locale before.

Thanks a lot!

[toc] | [prev] | [next] | [standalone]

#38902

On 4/10/2019 2:08 PM, Andreas Leitgeb wrote:
> Synchronous with my own sorry attempts, there was also some action on
> glassfish side. Some user posted a PR that made the glassfish ORB
> compileable with maven and jdk 11. (It's not yet merged, and it
> depends on some other package that isn't yet released to maven repo,
> thus needs some extra hoop-diving to let "mvn" find it, but there is
> some progress).

That is sort of the point in being on something actively
maintained.

You are not alone solving the problems.

Arne

[toc] | [prev] | [next] | [standalone]

#38904

On Friday, April 12, 2019 at 10:08:54 AM UTC-4, Arne Vajhøj wrote:
> That is sort of the point in being on something actively
> maintained.
> 
> You are not alone solving the problems.
> 
> Arne

Advantages to being actively maintained:
- expecting the project to get an update if a Java update would require one
- expecting any bugs to get fixed
Disadvantages:
- maintaining different code to account for changes in the project if you're testing with multiple versions

I have included some rather old projects (ie https://mvnrepository.com/artifact/xml-apis/xml-apis-ext) and some current projects (ie http://poi.apache.org/).

[toc] | [prev] | [next] | [standalone]

#38939

Next update:
  - Corba (glassfish) works - ssl will follow later
  - DateFormat issue solved.

New Issue:

The application uses awt & swing components for the GUI, and all
windows look distorted, fonts are a bit larger, even images look
a bit stretched and moving another window over the jdk 11 application
window leaves behind some spurious lines, as if the refresh had off-
by-one-pixel inaccuracies.

These issues only happen on Windows - on Linux these visual artefacts
don't show up.

Just on Windows, these show up with jdk-11.0.2, jdk-11.0.3 and
jdk-12.0.1 all alike.

Does this ring a bell for someone? 

[toc] | [prev] | [next] | [standalone]

#38941

Andreas Leitgeb <avl@logic.at> wrote:
> The application uses awt & swing components for the GUI, and all
> windows look distorted, fonts are a bit larger, even images look
> a bit stretched and moving another window over the jdk 11 application
> window leaves behind some spurious lines, as if the refresh had off-
> by-one-pixel inaccuracies.

It's not yet solved, but I could narrow it down to what system setting
triggers it:

In the settings dialog for "Screen Resolution", there is an option
labelled "Make text and other items larger or smaller", which on my
desktop was set to 125%.

Java up to 8 totally ignored that setting.
Java 11 tries to follow it (which is arguably an improvement), but
   does so in a somewhat broken way.

[toc] | [prev] | [next] | [standalone]

#38943

On 5/3/2019 8:10 AM, Andreas Leitgeb wrote:
> Andreas Leitgeb <avl@logic.at> wrote:
>> The application uses awt & swing components for the GUI, and all
>> windows look distorted, fonts are a bit larger, even images look
>> a bit stretched and moving another window over the jdk 11 application
>> window leaves behind some spurious lines, as if the refresh had off-
>> by-one-pixel inaccuracies.
> 
> It's not yet solved, but I could narrow it down to what system setting
> triggers it:
> 
> In the settings dialog for "Screen Resolution", there is an option
> labelled "Make text and other items larger or smaller", which on my
> desktop was set to 125%.
> 
> Java up to 8 totally ignored that setting.
> Java 11 tries to follow it (which is arguably an improvement), but
>     does so in a somewhat broken way.
> 

I think that change actually came with Java 9.  It is really a big 
improvement for high dpi screens.

k

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web