1

Since yesterday's new java JRE 1.8.0.45 our applet takes 1 minute and 30 seconds to load, instead of 1-2 seconds. All communicacion is https, and it connects with server also through https.

After some testings we have seen that it could be a DNS resolution problem, because if we add to the "etc\hosts" the domain and ip of our servers, it seems to work properly again, as with previous Java versions.

Our applet downloads several images from server; we've changed it to take them from the JAR file, but it still takes around 1:30min to startup.

At the beggining we thought that it was a graphics problem, because showing applet logs, it took 3-4 seconds to load each image, but even loading them form JAR file, it doesn't solve the problem.

It's like if the first "http/https" connection (that can be a "http" connectio to get "crossdomain.xml") takes that time to timeout. And after that (may be the DNS resolution?) it works properly.

Any idea will be great.

Regards

Vanji
  • 1,696
  • 14
  • 23
Vicente
  • 11
  • 3
  • We've finally found a workaround: as images are small, we've included them in the java code as static Base64 strings, and then loaded as images with ImageIO as bytearray input stream. – Vicente Apr 21 '15 at 08:40
  • vincente, can you post your solution as an answer? – Barett Apr 23 '15 at 18:43

3 Answers3

1

We have the same problem at one of our client websites. That didn't have a proper reverse dns record on DNS server, and therefore the java applet was blocked ~2 minutes while loading. Can you check your DNS?

Also "crossdomain.xml" can help with this [https://weblogs.java.net/blog/joshy/archive/2008/05/java_doodle_cro.html] if you are unable to configure DNS.

Regards, Viktor

0

Our Applet didn't worked downloading images from server nor getting them from the Jar file.

For example, we had a method like this to get images from Jar:

public Image getJarImage(String strFile) {
    Image image = null;
    byte[] tn = null;
    Toolkit toolkit = Toolkit.getDefaultToolkit();
    InputStream in = getClass().getResourceAsStream(strFile);
    try {
        int length = in.available();
        tn = new byte[length];
        in.read(tn);
        image = toolkit.createImage(tn);
    } catch (Exception exc) {
        return null;
    }
    return image;
}

To solve the problem , we generated the Base64 string from all the images and put them in a static hashtable (the "images" object), and transform again to Java images like this:

public Image getJarImage(String strFile) {
        String base64String=(String)images.get(strFile);
        byte[] bytearray = Base64.base64ToByteArray(base64String);  
        Image image=null;
        try {
            image = ImageIO.read(new ByteArrayInputStream(bytearray));
        } catch (IOException e) {
            return null;
        }
        return image;
    }   

To get the Base64 string from your images you can use several websites or simply javascript: How to convert image into base64 string using javascript

Hope it helps.

Community
  • 1
  • 1
Vicente
  • 11
  • 3
0

Vicente,

I have read in other posts that strangely using getResourceAsStream causes a server roundttrip although the resource should be read from the JAR file. This should be visible in a network trace. This can be avoided by setting codebase_lookup=false in the JNLP (which might or might not have other side effects - please do some research).

Remigius Stalder
  • 1,921
  • 2
  • 26
  • 31
  • Hi Remigius, we tested codebase_lookup and it didn't worked. And we did a network trace and nothing happened between browser and server. We belive it was a java plugin problem. It worked the same way if tryed to get resources from server or from Jar. – Vicente May 08 '15 at 07:42