JOSM starts as few pixel width window.

[kendzi]

Current latest and tested (6767) version of JOSM fail to open normal window during startup. JOSM starts as few pixel width window. Real problem appear when during startup pop-up request for updating plugins. That pop-up has only 1 pixel width window and it is impossible to resize it. Last tested by me version 6502 was working correctly.

Reproduced with cleaned profile.

Run on Ubuntu 13.10

java version "1.7.0_51"
OpenJDK Runtime Environment (IcedTea 2.4.4) (7u51-2.4.4-0ubuntu0.13.10.1)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)

java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

[kendzi]

JOSM opens as few pixel width window

[kendzi]

Ticket #9698 has been marked as a duplicate of this ticket.

[kendzi]

Is any archive of JOSM build between 6502 and 6767?

[kendzi]

I had check archive of snapshot and last working version is josm-snapshot-6513.jar
Next snapshot josm-snapshot-6527.jar is failing to open window.

[Don-vip]

You're obviously the only one facing this issue as nobody else complained in 7 weeks.

It seems a side effect of r6522 but I need to know more about your setup, especially window manager, number of screens and resolution.

Thanks.

[kendzi]

It was broken in commit 6522/josm. I have rollback that commit and It start working. Screenshot is attached to issue. I have Ubuntu with current Unity. I have two screens with resolutions: 1920x1080 and 1280x1024.

[Don-vip]

ok thanks.

[kendzi]

Oh it seams it is related to java version in java6 it is working correctly.

[kendzi]

It seems it is related to result of that method:
Rectangle maxbounds = GraphicsEnvironment.getLocalGraphicsEnvironment().getMaximumWindowBounds();

on java6 it results with:
java.awt.Rectangle[x=1920,y=0,width=1280,height=1024]

on java7 it results with:
java.awt.Rectangle[x=3905,y=24,width=-705,height=1000]

I think both results are wrong, but I'm really don't know why...

[kendzi]

After short research it seems both values generated from java6 and java7 are wrong. For me it looks like bug in Java and I made bug request to them. In the mean time I made patch with workaround for ignoring not correct values when calculating windows bounds. I tested it on both java6 and java7.

[kendzi]

It seems Ubuntu community simple ignoring it:
​https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1171563

[Don-vip]

Thanks for investigating. If you filed a Java bug, can you give me the bug ID Oracle assigned to you ?

In the meanwhile I have created a bug on IcedTea bugzilla:
​http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1669

[kendzi]

I get review ID: JI-9010334 It hasn't appeared on bugs.java.com yet.

[Don-vip]

Yep, it can take months, even years before showing up :(
It will be accessible through this URL someday: ​https://bugs.openjdk.java.net/browse/JI-9010334

Looking at your patch right now.

[stoecker]

Why should the value from Java 6 be wrong?

[x=1920,y=0,width=1280,height=1024]

Means right screen with offset 1920 (i.e. size of left screen) and the dimensions you specified.

[Don-vip]

In 6828/josm:

fix #9699 - workaround to java bug in getMaximumWindowBounds() (patch by kendzi)

[kendzi]

In javadoc: on multi-screen systems where Windows should be centered across all displays, this method returns the bounds of the entire display area.
So I assumed it should return something from size of both screens.

Value 1920 is little strange for me because program window can appear on both screens and that method always result with same x.

[Don-vip]

Wow, you're lucky:
​https://bugs.openjdk.java.net/browse/JDK-8034224

I have never seen a bug reaching public tracker so fast. I'm jealous :(