The fix looks good to me.
Thanks,
Alexandr.
On 17/02/16 19:20, Sergey Bylokhov wrote:
Looks fine.
On 15.02.16 18:17, Semyon Sadetsky wrote:
Please look at the updated webrev:
http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.05/
Changes was made According to off-line discussion wit Ser
Looks fine.
On 15.02.16 18:17, Semyon Sadetsky wrote:
Please look at the updated webrev:
http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.05/
Changes was made According to off-line discussion wit Sergey:
- IAE -> NPE for file == null
- FNFE is corrected for getLinkLocation()
--Semyon
On 1
Please look at the updated webrev:
http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.05/
Changes was made According to off-line discussion wit Sergey:
- IAE -> NPE for file == null
- FNFE is corrected for getLinkLocation()
--Semyon
On 1/22/2016 9:34 AM, Semyon Sadetsky wrote:
On 1/21/201
On 1/21/2016 6:25 PM, Sergey Bylokhov wrote:
On 21/01/16 09:16, Semyon Sadetsky wrote:
There are still inconsistency. The isFileSystem(), isParent(),
getSystemIcon, getSystemDisplayName() etc do not throw an exception in
case of null, but return some default value(null,true,false). Same for
F
On 21/01/16 09:16, Semyon Sadetsky wrote:
There are still inconsistency. The isFileSystem(), isParent(),
getSystemIcon, getSystemDisplayName() etc do not throw an exception in
case of null, but return some default value(null,true,false). Same for
FileNotFoundException() most of the methods just
On 1/20/2016 3:45 PM, Sergey Bylokhov wrote:
On 24/11/15 13:01, Semyon Sadetsky wrote:
On 11/2/2015 11:09 PM, Sergey Bylokhov wrote:
On 29.10.15 21:30, Phil Race wrote:
We should specify what happens if you pass in to get(String)
a) null
b) an unrecognised name.
Would it make sense to def
On 24/11/15 13:01, Semyon Sadetsky wrote:
On 11/2/2015 11:09 PM, Sergey Bylokhov wrote:
On 29.10.15 21:30, Phil Race wrote:
We should specify what happens if you pass in to get(String)
a) null
b) an unrecognised name.
Would it make sense to define string constants on FileSystemView
as otherw
Hi Semyon,
> The webrev is updated:
> http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.04/
Thanks! Looks good for me (I'm not a reviewer).
Best regards,
Andrej Golovnin
The fix looks good to me.
Thanks,
Alexandr.
On 1/19/2016 3:15 PM, Semyon Sadetsky wrote:
Hi Andrej,
The webrev is updated:
http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.04/
--Semyon
On 1/19/2016 2:28 PM, Andrej Golovnin wrote:
Hi Semyon,
http://cr.openjdk.java.net/~ssadets
Hi Andrej,
The webrev is updated:
http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.04/
--Semyon
On 1/19/2016 2:28 PM, Andrej Golovnin wrote:
Hi Semyon,
http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.03/
get(String) is replaced with getChooserComboBoxFiles(). Other get() keys are
Hi Semyon,
> http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.03/
> get(String) is replaced with getChooserComboBoxFiles(). Other get() keys are
> not in use by NetBeans.
Please move the new methods after the constructor of the FileSystemView class.
The description of the return value should
On 12/3/2015 2:02 PM, Alexander Scherbatiy wrote:
It is better to have concrete methods like Image
getFileChooserIcon(String iconName) rather to have one unified method
for all cases.
Please see the updated webrev:
http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.03/
get(String) is replac
I think this version looks OK. Don't forget it needs a CCC ..
-phil.
On 11/24/2015 02:01 AM, Semyon Sadetsky wrote:
On 11/2/2015 11:09 PM, Sergey Bylokhov wrote:
On 29.10.15 21:30, Phil Race wrote:
We should specify what happens if you pass in to get(String)
a) null
b) an unrecognised name.
It is better to have concrete methods like Image
getFileChooserIcon(String iconName) rather to have one unified method
for all cases.
Thanks,
Alexandr.
On 24/11/15 14:01, Semyon Sadetsky wrote:
On 11/2/2015 11:09 PM, Sergey Bylokhov wrote:
On 29.10.15 21:30, Phil Race wrote:
We should s
On 11/2/2015 11:09 PM, Sergey Bylokhov wrote:
On 29.10.15 21:30, Phil Race wrote:
We should specify what happens if you pass in to get(String)
a) null
b) an unrecognised name.
Would it make sense to define string constants on FileSystemView
as otherwise people have to spell these exactly righ
On 29.10.15 21:30, Phil Race wrote:
We should specify what happens if you pass in to get(String)
a) null
b) an unrecognised name.
Would it make sense to define string constants on FileSystemView
as otherwise people have to spell these exactly right without compiler
help ?
Also I expect (hope!)
Hello Phil,
On 10/29/2015 9:30 PM, Phil Race wrote:
We should specify what happens if you pass in to get(String)
a) null
b) an unrecognised name.
Yes. I forget this.
Would it make sense to define string constants on FileSystemView
as otherwise people have to spell these exactly right without
sorry, forget the updated webrev
http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.01/
On 10/30/2015 12:07 PM, Semyon Sadetsky wrote:
Hello Phil,
On 10/29/2015 9:30 PM, Phil Race wrote:
We should specify what happens if you pass in to get(String)
a) null
b) an unrecognised name.
Yes. I f
We should specify what happens if you pass in to get(String)
a) null
b) an unrecognised name.
Would it make sense to define string constants on FileSystemView
as otherwise people have to spell these exactly right without compiler
help ?
Also I expect (hope!) that we do not assert any privilege
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8081722
webrev: http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.00
As the solution it is suggested to have 3 new static methods in the
javax.swing.filechooser.FileSystemView class. Those methods proxy
sun.aw
20 matches
Mail list logo
