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

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

Warning, bad Java

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

Contents

  Warning, bad Java Eric Douglas <e.d.programmer@gmail.com> - 2016-10-07 08:32 -0700
    Re: Warning, bad Java j4n bur53 <janburse@fastmail.fm> - 2016-10-07 22:37 +0200
      Re: Warning, bad Java j4n bur53 <janburse@fastmail.fm> - 2016-10-07 22:59 +0200
    Re: Warning, bad Java Silvio <silvio@internet.com> - 2016-10-08 12:00 +0200
    Re: Warning, bad Java Arne Vajhøj <arne@vajhoej.dk> - 2016-10-08 09:54 -0400
      Re: Warning, bad Java Eric Douglas <e.d.programmer@gmail.com> - 2016-10-10 05:07 -0700
        Re: Warning, bad Java Arne Vajhøj <arne@vajhoej.dk> - 2016-10-10 09:17 -0400

#35736 — Warning, bad Java

The JDK download page has 2 versions available, 101 and 102.
Apparently there's a bug in 102 that's not in 101, and the bug report says it's been fixed but the fix is in the next release which is not yet available.
The download page doesn't say which version to download, just that 102 has "some new features" which are not in 101, so I tried the 102 and it's been hanging.

https://bugs.openjdk.java.net/browse/JDK-8161700

[toc] | [next] | [standalone]

#35737

Worst of all, the whole JNLP bloat doesn't seem
to offer many ways the break a deadlock.

For example through decompiling I find:

package com.sun.deploy.util;

public class SyncAccess {

     [...]
     private void acquireLock(int var1, int var2) {
         Object var3 = this.syncObj;
         synchronized(this.syncObj) {
             while((this.lockedOP & var1) != 0) {
                 try {
                     this.syncObj.wait();
                 } catch (InterruptedException var6) {
                     ;
                 }
             }

             this.lockedOP |= var2;
         }
     }
     [...]

}

So basically an InterruptedException will just
be swallowed by the above code.

Making it impossible to write some supervisor that
gracefully stops a hanging code.

P.S.: The package com.sun.corba.se.impl.orbutil.concurrent;
looks slightly better, but I don't know why they need a
notify after a catch, we find throughout the following idiom:

    try {
       [...]
    } catch (InterruptedException ex) {
       notify();
       throw ex;
    }

I don't think the notify() is needed, since there is no
state change.

If the notify() is not needed the whole try/catch is not
needed, and they could just add the exception to the
method signature.

Eric Douglas schrieb:
> The JDK download page has 2 versions available, 101 and 102.
> Apparently there's a bug in 102 that's not in 101, and the bug report says it's been fixed but the fix is in the next release which is not yet available.
> The download page doesn't say which version to download, just that 102 has "some new features" which are not in 101, so I tried the 102 and it's been hanging.
>
> https://bugs.openjdk.java.net/browse/JDK-8161700
>

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

#35738

<begin-rant>

j4n bur53 schrieb:
> P.S.: The package com.sun.corba.se.impl.orbutil.concurrent;
Of the 67 occurence of wait() in the JDK 1.8, most
of them don't know what to do with an interrupt.

Worst of it one occurence is in the inet
host to ip translation I guess.

I even find funny comments such as:

// %TBD% -- Declare? Encapsulate? Ignore? Or
// dance widdershins about the instruction cache?

// %TBD% -- Declare? Encapsulate? Ignore? Or
// dance deasil about the program counter?

<end-rant>

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

#35739

On 10/07/2016 05:32 PM, Eric Douglas wrote:
> The JDK download page has 2 versions available, 101 and 102.
> Apparently there's a bug in 102 that's not in 101, and the bug report says it's been fixed but the fix is in the next release which is not yet available.
> The download page doesn't say which version to download, just that 102 has "some new features" which are not in 101, so I tried the 102 and it's been hanging.
>
> https://bugs.openjdk.java.net/browse/JDK-8161700
>

Perhaps they are trying to prepare us for retraction of JNLP support in 
the JDK.

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

#35740

On 10/7/2016 11:32 AM, Eric Douglas wrote:
> The JDK download page has 2 versions available, 101 and 102.
> Apparently there's a bug in 102 that's not in 101, and the bug report
> says it's been fixed but the fix is in the next release which is not
> yet available. The download page doesn't say which version to
> download, just that 102 has "some new features" which are not in 101,
> so I tried the 102 and it's been hanging.
>
> https://bugs.openjdk.java.net/browse/JDK-8161700

Well - that is why Oracle put out the N and N+1 versions.

N is the safe choice. N+1 is latest and greatest.

I think that in general N+1 are quite safe. But there is
a risk. And apparently something slipped into 102.

It does probably not help that JNLP is so little used as
it is. Less focus.

Arne

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

#35743

On Saturday, October 8, 2016 at 9:54:39 AM UTC-4, Arne Vajhøj wrote:
> Well - that is why Oracle put out the N and N+1 versions.
> 
> N is the safe choice. N+1 is latest and greatest.
> 
> I think that in general N+1 are quite safe. But there is
> a risk. And apparently something slipped into 102.
> 
> It does probably not help that JNLP is so little used as
> it is. Less focus.
> 
> Arne

The past several releases they've had an N and N+1.  I used the N+1 since I thought it would just be better (security patches?  new features that shouldn't hurt existing code?) and they were fine previously.  You'd think it should be bug free when they call it public release, and when they fix a critical bug like this they should get it into the public release, but they just put the fix into the beta 122.  I downloaded 122 and it seems fine, if not better, there may be performance enhancements.  I didn't see a workaround for this, some way to tell my thread to timeout and move on if it hits this deadlock, so our only solution is to install 101 on every client, now that we've already pushed 102 through group policy which doesn't seem to want to remove it.

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

#35744

On 10/10/2016 8:07 AM, Eric Douglas wrote:
> On Saturday, October 8, 2016 at 9:54:39 AM UTC-4, Arne Vajhøj wrote:
>> Well - that is why Oracle put out the N and N+1 versions.
>>
>> N is the safe choice. N+1 is latest and greatest.
>>
>> I think that in general N+1 are quite safe. But there is a risk.
>> And apparently something slipped into 102.
>>
>> It does probably not help that JNLP is so little used as it is.
>> Less focus.
>
> The past several releases they've had an N and N+1.  I used the N+1

Me too.

> since I thought it would just be better (security patches?  new
> features that shouldn't hurt existing code?) and they were fine

N is security patches only.

N is security patches and other patches.

> previously.  You'd think it should be bug free when they call it
> public release,

Bug free software??

:-)

>                and when they fix a critical bug like this they
> should get it into the public release, but they just put the fix into
> the beta 122.

They can not have two 102's.

They could have rushed a 104 out.

And if it had been sufficient important then I guess they would.

JNLP is just put in next planned release.

>                                       I didn't see a workaround for
> this, some way to tell my thread to timeout and move on if it hits
> this deadlock, so our only solution is to install 101 on every
> client, now that we've already pushed 102 through group policy which
> doesn't seem to want to remove it.

:-(

Arne

[toc] | [prev] | [standalone]

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

csiph-web