Skip to main content

JDK collaboration bug fixes in recent Mustang builds

19 replies [Last post]
timbell
Offline
Joined: 2003-06-10
Points: 0

JDK collaboration [1] fixes are making their way through our internal bug-fix pipeline. If you look at the change documents provided with each promotion [2], you will find these Bug-IDs listed. I thought it would be useful to give an update on contributed fixes that have been integrated in recent Mustang builds:

Build Bug-ID Synopsis
----- ------- --------
b34 6257449 Concurrency bug in com.sun.media.sound...
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6257449

b43 4238932 JTextField in gridBagLayout does not ...
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4238932

b43 5073365 (thread) java.lang.Thread.SetPriority() ...
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5073365

b47 6248507 AbstractStringBuilder.replace does not handle...
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6248507

b48 6205522 (cal) javadoc warnings for GregorianCalendar...
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6205522

Coming soon (Mustang build 50 was promoted today and should be available early next week):

b50 6182942 JButton.isEnabled() return false however the...
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182942

b50 6298940 AbstractButton.setModel doesn't fully update...
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6298940

To the project members who contributed these fixes: Thank You. We have more on the way.

[1] https://jdk-collaboration.dev.java.net

[2] https://mustang.dev.java.net/servlets/ProjectDocumentList?folderID=2855

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cayhorstmann
Offline
Joined: 2003-06-13
Points: 0

I submitted a fix to bug 4827318 on 07/13/2005. I emailed it to Tim Bell who promised to pass it on. (That was before there was an official channel.) It's not on your list. Should I resubmit it?

Thanks,

Cay

kennardconsulting
Offline
Joined: 2005-10-25
Points: 0

Brinkley,

You legend! Thank you SO much for providing an update.

In keeping with the old addage of 'give 'em an inch and they'll take a mile...' could you please put something on the page that describes the various states and how long a job typically sits in each?

My fix (6306820) has been in '3-Accepted' (which I assume is a very early state) for over 6 weeks now and nobody has contacted me, though that may be quite normal?

cayhorstmann
Offline
Joined: 2003-06-13
Points: 0

Thanks for the update! I now see a couple of my submissions "in play". However, I am still looking for one submission, a fix to bug 4827318 that also includes an enhancement of interest to the ACM Java Task Force. The enhancement modifies the program launcher. if "public void main(String[])" exists and is not static, and the class has a default constructor, the launcher calls the default constructor and the non-static main. Of course, if main is static, the launcher does what it always did.

I realize that this is a more substantial contribution than a mere bug fix, and I am very interested in seeing what happens to it.

Cheers,

Cay

kenrodd
Offline
Joined: 2003-06-18
Points: 0

cayhorstmann:

> Thanks for the update! I now see a couple of my submissions "in play".

Sorry - I must have missed a link somewhere? What 'update'? Are you referring to the update on Sep 16?

mthornton:

Thank you for that link to the blog of suggested bug fixes, though I was hoping for something more 'official'.

Also, you didn't respond to my original question? I was hoping for an update along the lines that timbell provided on Sep 16, but covering progress on Peabody jobs in the last month? In particular, I was hoping to get an indication of when my assigned Responsible Engineer will be contacting me?

Thanks,

Richard.

kennardconsulting
Offline
Joined: 2005-10-25
Points: 0

Any chance of a Peabody progress update now that b57 has been released?

darcy
Offline
Joined: 2003-06-15
Points: 0

I have submiktted 4 fixes between September 20th and September 22nd with no reply beyond the automated ones and the ones telling me that someone will get back to me...

Sort of dissapointing to not have any clue as to what is going on. Is there going to be something put into place soon to let us know what is going on with submissions?

brinkley
Offline
Joined: 2003-06-06
Points: 0

> I have submiktted 4 fixes between September 20th and
> September 22nd with no reply beyond the automated
> ones and the ones telling me that someone will get
> back to me...
>
> Sort of dissapointing to not have any clue as to what
> is going on. Is there going to be something put into
> place soon to let us know what is going on with
> submissions?

Understood. There is now JDK Community Contribution Bug Status page at http://download.java.net/jdk/JDK-Contribution.html where anyone can find the status of contributed bug fix. The list will be updated weekly. If your bug isn't on the list let us know so we can track it down.

Roger Brinkley
JDK Community Leader

darcy
Offline
Joined: 2003-06-15
Points: 0

"There is now JDK Community Contribution Bug Status page"

Thanks! This makes it easier to decide if we want to tackle a bug too since we can see at least some of the bugs being worked on by others.

robilad
Offline
Joined: 2004-05-05
Points: 0

If I see that correctly, that's less than one fix per build/week. I'm flabberghasted if that's the whole result of the huge Peabody marketing effort.

Even Kaffe, ocassionally labelled as dead by people not using the CVS head, gets a lot more than one external fix per week.

cheers,
dalibor topic

uncle_alice
Offline
Joined: 2003-06-16
Points: 0

It's early days yet, dalibor.

kenrodd
Offline
Joined: 2003-06-18
Points: 0

It would be great to get an update on peabody jobs committed/under review now that b55 has been released?

Thanks,

Richard.

kenrodd
Offline
Joined: 2003-06-18
Points: 0

I think the Peabody initiative is a brilliant idea, and I am very excited about the opportunity to give back to something that has given me so much for so long (and for free :)

However, it has been over a month since I submitted my own Peabody fix and I have not heard anything, other than a 'thanks for submitting your fix' message.

Given that I anticipate a bit of back-and-forth with the Responsible Engineer before my fix is up to scratch for approval into the Mustang build, how long should I expect to wait? The message I got when I first submitted advised I should wait a week, so perhaps that should be amended to be more realistic?

Also, the list of 'smallish bugs that need fixing' that I asked for (and was agreed to) has not been posted anywhere as far as I know?

I realize you guys are very busy, and you do fantastic work, but surely helping others to share the workload is, in the long term, a productive use of your time?

mthornton
Offline
Joined: 2003-06-10
Points: 0

A few suggestions for small bugs have been posted to John O'Conner's blog

http://weblogs.java.net/blog/joconner/archive/2005/10/contributing_to_1....

Also some possible fixes for bug 4117557 (in top 25) are quite simple, but there may be more trouble deciding what is the appropriate way to fix it. The 'simple' solution would be to prevent user.dir from being changed from within an application (throw an exception), and if specified on the command line, the launcher can just change the current directory to the given value before proceeding further.

Message was edited by: mthornton

steevcoco
Offline
Joined: 2004-05-23
Points: 0

Hi.

Regarding the "user.dir" property: I have posted this to the bug parade and the mentioned blog, because it seemed that there was some inclination to change this behavior in unkonwn ways. I got a little worried. I'll re-post it here, hoping for "wise eyes" to find it:

DO NOT MODIFY THIS BEHAVIOR UNLESS YOU ARE ABLE TO PROVE THAT ALL SECURITY MECHANISMS WILL AVOID ANY BREACH AS A RESULT OF THE CHANGE!

Specifically: new FilePermission("*", ...), for one.

A comment on the bug parade mentioned "application so-and-so would not be able to so-and-so" without being able to change the property. This is completely specious.

The point is that user.dir is not a mutable property. This is to be specified and rigidly enforced by the user: to the point of it being a security breach if your Java code attempts to change it in a manner visible outside the VM.

Ideally, maybe: each invocation of System.getProperty("user.dir") would ask the host platform for the current user directory. If the host does not support the notion of a user directory -- and there are such platforms, right? -- some fallback should be returned. And then, any API method that supposedly resolves against this property should diligently check it wherever needed.

As far as operating scripts go:

Operating system scripts were designed to be hand-written by the computer's user, not some "at-whim" library function for unseen code to invoke!

If it is impinging to consider this, remember that the notion of a separation, or mediation between an application and the host it is running on -- in other words, a viable virtual machine -- is a /new/ concept, not an old one! The ability for some MSDOS program to "modify" the user directory, or something similar, does not make precedence for future applications!

Regards,
Steev.

mthornton
Offline
Joined: 2003-06-10
Points: 0

My suggested fix is simply to throw an exception on System.setProperty("user.env", ...) and equivalent calls,
and to make
java -Duser.env=MyDirectory ...
equivalent to
cd MyDirectory
java ...

It would be even simpler to just reject attempts to set user.dir on the command line, but it is hard to find a good reason other than rather minor implementation convenience. What this does not do is answer the RFE requesting a CD function from with Java. I agree that this should be rejected.

The bug is that user.dir currently *is* a mutable property with rather inconsistent consequences.

Message was edited by: mthornton

steevcoco
Offline
Joined: 2004-05-23
Points: 0

Hi.

Sorry for the quite late response to this, but I'd like to try to reply again to mthornton above:

> My suggested fix is simply to throw an exception on
> System.setProperty("user.env", ...) and equivalent
> calls,
> and to make
> java -Duser.env=MyDirectory ...
> equivalent to
> cd MyDirectory
> java ...
>
> It would be even simpler to just reject attempts to
> set user.dir on the command line, but it is hard to
> find a good reason other than rather minor
> implementation convenience. What this does not do is
> answer the RFE requesting a CD function from with
> Java. I agree that this should be rejected.
>
> The bug is that user.dir currently *is* a mutable
> property with rather inconsistent consequences.

I wanted to post some response so you know what I am or am not up to regarding this [I'm not trying to submit any code related to this]; but also something still strikes me:

What you've said above seems to sound OK though I'm not 100% sure. When you say "equivalent to "cd MyDirectory" how exactly do you mean? - Please note that I don't know how the launcher is currently implemented: You could modify the launcher so it ~literally invokes this in the OS; which implies that if it doesn't have permission to run in that directory then some native exception is raised or something; or you could pass a different "user.dir" value into the VM, which at this point does not actually match the user's current directory. There may be something else that happens and I'm not seeing it.

Both of these are odd. The first because like I said, maybe permissions interfere, and other reasons, below; the second for kind of the same reason: If the user can't access the directory that is now in user.dir then (... hopefully you'll stay with me) security exceptions raise if you try to use it (or something!) or else you have successfully subverted the platform's permissions. It depends on what the native launcher can, can't, does, or doesn't do I guess, which /should/ be fine since it won't be able to do anything that the user can't do in theory.

It /is still odd/ to pass an argument to the interpreter and all of a sudden "user.dir" is different. I mentioned the scripts are supposed to be for the user, not for the interpreter, but I am certainly not the final authority. But it removes options from the user: Without such a facility, the user can 'cd' wherever they choose in a - perfectly valid - attempt to modify the behavior of your program by forcing it to run somewhere else. With this facility in place, no amount of 'cd'ing will get them anywhere. So they are stripped of some authority here.

I had mentioned too that nothing stops you from putting your own property -- -DmyDir=this user dir -- and using that, /especially/ since in all these scenarios the actual command line arguments have been specified by you (whether it's -Duser.dir... or -Dmy.dir...).

Plus, you're throwing information away, since by specifying your own property you keep whatever the interpreter has been given to maintain more options. Does that make sense?

I my view, throwing the exception when trying to set the property seems fine, and I'd live with that result, but trying to set it from the command line might not be the right route.

Let me know what you think. Or anyone else who might have comment on what I've said also... I think there is a scenario that I might not see.

Thanks!

Take it easy,
Steev.

cayhorstmann
Offline
Joined: 2003-06-13
Points: 0

I submitted several fixes and got no response whatsoever. Is there any way of checking the status? I am reluctant to submit more fixes into a black hole.

Thanks,

Cay

timbell
Offline
Joined: 2003-06-10
Points: 0

We are working to increase the visibility of fixes in the queue.

Stay tuned - I will post a follow-up message with a list of the fixes we have in process. I am asking all managers and engineers to evaluate these fixes and update the bug reports with the status.

Message was edited by: timbell

timbell
Offline
Joined: 2003-06-10
Points: 0

Fri Sep 16 17:54:24 PDT 2005

All peabody related reports that are in play.

If the fix is integrated, you will see the build number ([i]bxx[/i]).

Concurrency bug in com.sun.media.sound.UlawCodec with tempBuffer
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6257449 b34

a JTextField in gridBagLayout does not properly set MinimumSize
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4238932 b43

(thread) java.lang.Thread.SetPriority() raises a NullPointerException if a thread has
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5073365 b43

AbstractStringBuilder.replace does not handle count < start < end
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6248507 b47

(cal) javadoc warnings for GregorianCalendar
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6205522 b48

JButton.isEnabled() return false however the button is enabled
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182942 b50

AbstractButton.setModel doesn't fully update mnemonic
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6298940 b50

(coll) IdentityHashMap.entrySet().toArray(T[] a) is incorrectly implemented
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6197726 b51

(coll) ArrayList made from IdentityHashMap.entrySet() fails to create properly
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6232484 b51

Linux version of JDK doesn't support uk_UA.KOI8-U locale
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4890726

Dialogs and Frames are never garbage collected
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4726458

File should provide access to created and last-access times
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6314708

(reflect) Add support to java.lang.Class for wrapper type conversions
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6176992

(thread) ThreadLocal leak when value references ThreadLocal
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531

Add String.endsWithIgnoreCase(String suffix)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6307387

Extend Java's 'URL parameters' manipulation capabilites
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6306820

the current MD5 implementation is the bottleneck of my application
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6303905

java.security.MessageDigestSpi: re-use byte[] for better performance
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6314710

Lookbehinds with internal quantifiers are unreliable
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6284152

java.io: Need a way to convert Readers into InputStreams
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4094886

JFrame's decorated root pane doesn't like MouseListeners
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4854950

javax.naming.NamingEnuermation should be closed when parent DirContext is closed
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5084229

RFE: Point2D.Double and Point2D.Float should be Serializable
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4263142

wait unprotected from spurious wakeups in EventQueue.invokeAndWait
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4974934

LTP: XMLEncoder ignores persistence delegates when used with java web start
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4741757

String merge/join facility that would be the inverse of java.lang.String.split
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5015163

(so) File descriptor leak when using DatagramChannel.socket()
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6246565

Provide an AbstractTreeModel for the TreeModel hierarchy
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4346256

FileSystemView.getSystemIcon throws NPE for bad soft links
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4854174

(coll) Add java.util.Arrays.binarySearch(a, key, fromIndex, toIndex
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4306897

Locale performance and correctness fixes
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6307385

Additional Compressed Streams Requested
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4679743

PrintWriter.clearError() to reset internal error state
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4491255

String constructors and method which take Charset rather than String as argument
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5005831

(thread) Creating thread local variables from within ThreadLocal.initialValue
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5025230

Construction performance of user created AWT components has become very slow
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6298794

Dropouts in audio recordings
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6261423

Self-closing tags incorrectly parsed by javax.swing.text.html.parser.Parser
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4806463

JPanel not poping up the menu set in the setComponentPopup
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6272233

Message was edited by: timbell