Skip to main content

Open plea to Sun: please include bug 6784816 in 6u12

23 replies [Last post]
jacobdk
Offline
Joined: 2008-04-21
Points: 0

Hi forum

This thread is actually a spinoff of my postings in another thread in this forum:

http://forums.java.net/jive/thread.jspa?threadID=33331

The story so far is - during my test of the new 6u10 plugin together with Oracle Forms, I encountered a critical issue introduced with this plugin. Through my postings on Oracle's support site and this thread, I had the problem nailed down, and Artem Ananiev (ixmal) logged the mentioned bug on the issue.

We are currently about to deploy an important new component to our Oracle Forms application, which currently serves about 400-500 unique users. However, this component will never run correctly on Windows Vista, unless we force our users to upgrade to 6u10 or newer due to the new improved Vista support for signed applets.

I know, that Oracle on behalf of me and their other Forms customers has created an escalation request on this bug, which has Sun case ID #66165649. Artem has told me the following:

"6u12 has entered development freeze, and the core JDK team will only allow showstopper bugs from now on."

My reason for this plea is simply to emphasize, that this IS a showstopper bug for everyone using Oracle Forms, who also has to support the Forms applet for Windows Vista. I hope, that whoever is in the "JDK core team" will reconsider the "development freeze" and let this bug find its way into 6u12...

You would give me and other Forms developers such a tremendous help by letting a fix for bug 6784816 make it into 6u12.

Thanks in advance,
Jacob Madsen

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jacobdk
Offline
Joined: 2008-04-21
Points: 0

The fix for bug 6784816 does not seem to be implemented in 6u14-b01. The issue reproduces again now in this build, no matter if I turn the new GC on or not.

Please include this fix in the next beta build of 6u14.

Jacob

ixmal
Offline
Joined: 2004-08-08
Points: 0

> Please include this fix in the next beta build of
> 6u14.

The fix is absent in first builds of 6u14 due to some technical reasons. I've already reported about this problem and AFAIK it is already resolved by additional synchronization between the latest 6u12 and current 6u14 workspaces.

Artem

jacobdk
Offline
Joined: 2008-04-21
Points: 0

I have verified the fix in 6u14-b02, and now it seems to work correctly. Thereby I believe this case can be closed for good. Thanks :)

Regards,
Jacob

mutantpenguin
Offline
Joined: 2009-01-05
Points: 0

Great to know!

Thanks for your work on this ixmal!

Markus

ixmal
Offline
Joined: 2004-08-08
Points: 0

The fix has been integrated to 6u12.

jacobdk
Offline
Joined: 2008-04-21
Points: 0

Awesome news Artem :)

I believe the fix will be available in 6u12-beta-b04? Do you have any release schedule for this one? Or will b04 be the final version?

Jacob

michaelcox
Offline
Joined: 2009-01-05
Points: 0

The product that our company develops is based upon the Oracle Forms RAD. We have many clients that are wanting to upgrade to Vista and we cannot certify our product to work with this Operating System.

As has been noticed by other companies wishing to upgrade this problem became visible during the 6u10. This defect is affecting our business and Oracle Development Companies. I would like to see Oracle and Sun push harder to get this resolved.

Please include a fix for 6784816 in 6u12 as this is critical to our business.

Thanks,

-->michael.cox

mutantpenguin
Offline
Joined: 2009-01-05
Points: 0

Hi,

the company i am working for is affected by this bug too, but in a different way than you might think.

We encountered crashes with popup-menus first, and after that got crashes due to rezising of the applet too.

The difference with us is that we don't try to deploy on Vista, but on 64-bit Windows Terminal Server 2003 SP1 (but Vista might be a target for us soon enough).
Due to increased load on our 32-bit Terminal Servers, we are forced to migrate to 64-bit soon. Actually our Forms-Application is the last application blocking this migration, but we originally planned to fully migrate on November 2008!

1st problem:
Because of the Java-Bug 6532730 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532730) we are forced to use Java 1.6_10 or later. With versions prior to 1.6_10 it is not possible for us to start Java-Applets at all on 64-bit Windows Terminal Server 2003 SP1! (Has nothing to do with the Forms-Applet. Standard Java-Demos won't work too.)

2nd problem:
Since upgrading to Java 1.6_10 or later will give us crashes with popups and resizing, we cant' upgrade.

So either way we have a non-functioning application. Best of all there is no solution or workaround for this!

Actually this application is business-critical for us since our whole workflow (from creating a new order, having many coworkers involved in working off the order and finally creating an invoice) depends on it.

I can just repeat what Jacob Madsen said : For Oracle Forms users this indeed is a showstopper bug!

Please get a fix for this into Java 6u12, quite a few Forms users will be grateful for it.

Thanks in advance
Markus Lobedann

trembovetski
Offline
Joined: 2003-12-31
Points: 0

I'm not sure these bugs are related. The symptom of 6784816 is a deadlock, not a crash.

Could it be that your issues are related to the d3d pipeline? Have you tried running with -Dsun.java2d.d3d=false?

Dmitri

jacobdk
Offline
Joined: 2008-04-21
Points: 0

It's not related to the Direct3D pipeline - both me and Oracle support can verify this, as it's tested both with and without the Direct3D parameter. I also have encountered the variation with popup menus, Markus described. However, Oracle support had at that point already determined, that it's caused by the same base issue in the JDK, as they had labeled the Oracle bug, which originally was filed on my behalf, as being the "base bug" for the issue, Markus is talking about.

If you have access to Oracle's support site MetaLink on metalink2.oracle.com, look up these Oracle bugs to see what I mean:

7582339 - this is the bug Markus had logged, which he describes here. It's waiting for 7485019 to be fixed. ("base bug=7485019")

7485019 - this is the bug I originally had logged with Oracle. It is waiting for 7597589 to be fixed. ("base bug=7597589")

7597589 ("Deadlock due to newly added AWTTreeLock in getComponentCount()")- this is the base JDK bug, which was logged by the Oracle Forms development team for internal analysis. It has now been determined to be the same bug as Sun bug 6784816. See the discussion thread with Artem I posted earlier, where this was verified. This is also why Oracle has posted an escalation request for this Sun bug.

So in the end, all of these Oracle bugs are pointing directly to Sun bug 6784816 and waits for it to be fixed. When Markus talks about a "crash", he probably means that the applet freezes=deadlocks - right, Markus?

Dmitri: Can you say anything about the possibility of putting a fix for 6784816 into 6u12 based on mine and the other feedback? Are you part of the "JDK core team", who determines which bugs are to be scheduled for what release? As I understood on Artem, it's not something he has any influence on...

Thanks in advance,
Jacob

mutantpenguin
Offline
Joined: 2009-01-05
Points: 0

Sorry for the confusion, with "crash" i meant "deadlock" (actually i provided some stacktrackes for the deadlock on my Metalink Service Request).

With Java-Bug 6532730 it really crashes, no deadlock to see for me there.

I was able to rule out that Direct3D had anything to do with it too!

Just a single statement if a fix for Java-Bug 6784816 will be included/is worked on in 6u12 would be nice.

Regards
Markus

jacobdk
Offline
Joined: 2008-04-21
Points: 0

My latest information from Oracle Support regarding bug 6784816 is here:

>Update from Sun:
>"Hi Bill,
>Thanks for your patience.
>I got feedback Friday that engineering thought they knew the cause and expected to have a fix shortly. I'll ping them this afternoon if I don't get another update today."
>
>Additionally the next feedback (a few hours afterwards)
>"Feedback from Sun:
>The fix is in code review at the moment. Can't commit to 6u12 yet though. Will update once we have more"

Oracle is unable to provide me with more information than this... Could someone from Sun please comment on, how this review process is proceeding? Dmitri? Roger? Artem? Anyone please?

Regards,
Jacob

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Unfortunately I think this bug fix missed 6u12. It will likely get into 6u13 (if allowed) or 6u14 (for sure).

Dmitri

andreas_leidner
Offline
Joined: 2007-11-16
Points: 0

Hello Dmitri,

is there anything we can do to have this fix in 6u12 nonetheless? Any suggestions are appreciated :) We'd even consider buying support from Sun directly to build a custom JRE release (I've heard that's possible with Sun's "business support") - however, Oracle probably wouldn't support us using those custom releases...

Do you have an idea when 6u12, 6u13, 6u14 are planned to be released?

Andreas

trembovetski
Offline
Joined: 2003-12-31
Points: 0

I don't think it's at all possible to get it fixed in u12. The fix is being reviewed for u13 afaik.

> Do you have an idea when 6u12, 6u13, 6u14 are planned to be released?

u12 in Feb, u13 Apr-Mar.

Dmitri

jacobdk
Offline
Joined: 2008-04-21
Points: 0

I had seen this coming - for that reason, I have already asked Oracle Support to request a special release at Sun, which includes the fix.

Sun has done this before. Some of you might have heard of the special "1.5.0_10-erdist" release, which also was made especially to Oracle to fix some critical Forms-related bugs in a very similar way. I can only hope, that it could be possible, that Sun could produce such an interim JRE release again.

In any case, I'm glad to hear, that 6u13 is scheduled to include the fix at least, since it couldn't be in 6u12... I believe 6u12 currently is in its final testing phase, scheduled for release soon - that's why you don't let any other bugfixes in anymore?

Also - could you please make 6u13 an open beta, as you did with 6u12, so we can test and verify the fix to this bug as soon as possible?

Thanks in advance,

Jacob

javajustin
Offline
Joined: 2009-01-05
Points: 0

Hi Jacob,

I'm also at Sun. We have been pushing hard internally to get this fix in as early as possible, and there's a chance we may be able to include this in 6u12. It will definitely go into 6u13 if not earlier. I will have a better idea early next week on how early we can get this in and will update you then. Sorry about the inconvenience this is causing your team.

Justin

mutantpenguin
Offline
Joined: 2009-01-05
Points: 0

Dmitri and Justin, thanks to both to you for the update!

Since you don't know for sure if and when this fix will get in, maybe you can tell us a date when we can expect a definite statement about this from SUN? Even knowing for sure if it will be in 6u12 would be good for the company i am working for.

If we really have to wait until April/May we have to plan for some alternatives. (please see my earlier post in this thread why we are forced to upgrade to 6u10 or later).

Thanks
Markus

trembovetski
Offline
Joined: 2003-12-31
Points: 0

You should know within next week when b04 is out whether the fix make it or not.

Dmitri

jjburke
Offline
Joined: 2004-03-16
Points: 0

SUN where is this bug? That's bug 6784816. As of today Friday 01/02/2008 06:30pm CT there are no bugs listed for version 1.6.0_12-ea-b03 over on the bug database? Or am I querying incorrectly by searching using the entire string?

And what category of bug is it?

SUBMITTED 12-DEC-2008. Then today 01/02/2008 its 21 days elapsed and no bug report shows up. IXMAL any inside information on this and the general bug status?

HOW MANY MYSTERY BUGS A ROUGH VIEW Release B03 fixed three bugs higher than our target bug here. How many other bugs are crawling around in Sun's bug land?
Target bug 6784816
B03 fix ---- 6786238 1 - Very High (java:classes_swing)
B03 fix ---- 6784894 2 - High (java_plugin:plugin2)
B03 fix ---- 6787261 2 - High (java_plugin:plugin2)

So lets see if we take 678416 as our low bug # minus 6787261 high bug # is 2445 gross total. Then we subtract three bugs fixed in this range in B03. Final rough total 2442 suspected bugs of some priority somewhere out there in double triple secret bug database land.

I don't think Sun usually lists bugs on the regular bug search. I queried the bug database lots of times after B02 and was pleasantly surprised to see the number of bugs fixed in B03. But those bugs never showed up on the regular bug database.

Thanks,
Jim

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Not sure what is your point, Jim. The bug is http://bugs.sun.com/view_bug.do?bug_id=6784816 . Did you try searching for specific bug id?

The internal bug database is for all Sun products, not just Java-related, so yeah there's lots of bugs being filed. Some of the product categories aren't not exposed, yes, and some bugs (mostly, reasonably, security-related) aren't exposed by default even for products which are listed in the external database. Is that a revelation?

Dmitri

jjburke
Offline
Joined: 2004-03-16
Points: 0

Hi tembovetski, get ready for a staff discussion on the observations below.

There appears to be a long standing problem when bugs are reported. It seems, fields are not properly filled in. One field in particular. This is for the public bug database and not internal bug database.

For this bug, 6784816, and for many bugs, the "Reported Against" field is BLANK. In fact the "Reported Against" field is mostly blank for ALL bugs. Sometimes it says "mantis" or something.

SUGGESTION 1. Sun needs to standardize bug reporting to include the FULL release number in this field. For example "1.6.0_12-ea-b03"? This needs to be the full string to prevent other releases from showing up.

However my suggestion #1 creates immediate additional problems. The "java -version" string reports a lot of information. What exactly to capture? I think ALL information from "java -version" should be captured. So given a typical "java -version" below what should be included?

java -version
java version "1.6.0_12-ea"
Java(TM) SE Runtime Environment (build 1.6.0_12-ea-b03)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)

This is too long for one field. So your database needs additional fields and your web page needs to report these fields.
Suggestion 2. Include a "Java Version" field
Suggestion 3. Include a "Java(TM) SE Runtime Environment build" field
Suggestion 4. Include a "Java HotSpot(TM) Client VM" field.

Do my suggestions present future problems? Absolutely! Now the question is, what will future version reporting by the Java VM reflect? That's the "java -version" command.

So my REAL QUESTION is twofold and gets pretty deep. Consistently and coherently standardize version reporting by the "java -version". Then record these strings in your bug report database.

Yes I found the bug by following the steps below.
1. www.java.sun.com
2. Clicked on the bug database on the right side
3. Now in the bug database panel
4. Category JAVA SE (JDK/JRE)
5. Type Any
6. SubCategory Any
7. Keywords/Bug ID: 6784816
Here if I type "1.6.0_12-ea-b03" scant bugs show up.
Here if I type "B03" lots and lots of old and odd bugs show up.
Because that reported against field is blank.

Hope this helps,
Jim Burke

tullio0106
Offline
Joined: 2004-05-13
Points: 0

I've the same problem on my installed basesa and I hope the problem will be solved as soon as possible.
Tks
Tullio