|
Replies:
19
-
Last Post:
Nov 29, 2005 2:13 PM
by: cayhorstmann
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Sep 16, 2005 2:13 PM
in response to: timbell
|
|
|
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
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Sep 16, 2005 5:53 PM
in response to: cayhorstmann
|
|
|
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
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Sep 17, 2005 6:53 AM
in response to: timbell
|
|
|
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
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Sep 18, 2005 10:45 PM
in response to: robilad
|
|
|
It's early days yet, dalibor.
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 6, 2005 11:14 PM
in response to: uncle_alice
|
|
|
It would be great to get an update on peabody jobs committed/under review now that b55 has been released?
Thanks,
Richard.
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 11, 2005 4:16 PM
in response to: kenrodd
|
|
|
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?
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 12, 2005 1:30 AM
in response to: kenrodd
|
|
|
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.html
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
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 12, 2005 2:01 PM
in response to: mthornton
|
|
|
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.
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 12, 2005 2:35 PM
in response to: steevcoco
|
|
|
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
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 27, 2005 3:50 PM
in response to: mthornton
|
|
|
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.
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 12, 2005 3:52 PM
in response to: timbell
|
|
|
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
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 12, 2005 5:22 PM
in response to: cayhorstmann
|
|
|
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.
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 25, 2005 3:57 PM
in response to: kenrodd
|
|
|
Any chance of a Peabody progress update now that b57 has been released?
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 26, 2005 9:08 PM
in response to: kennardconsulting
|
|
|
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?
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 27, 2005 1:23 PM
in response to: darcy
|
|
|
> 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
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 28, 2005 8:18 AM
in response to: brinkley
|
|
|
"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.
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Nov 29, 2005 2:13 PM
in response to: brinkley
|
|
|
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
|
|
|
|
|
|
|
|
|
Re: JDK collaboration bug fixes in recent Mustang builds
Posted:
Oct 27, 2005 3:36 PM
in response to: timbell
|
|
|
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?
|
|
|
|
|
java.net RSS
