Hi Petr,
The fix looks fine to me. Only one question:
src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
234 } catch (IOException e) {
235 System.err.println("Warning reading flavor mapping: " +
e.getMessage());
Is there a reason to hide the stack trace of the exception? Why wouldn't
a simple call to e.printStackTrace() work? Or why not to throw an
InternalError(e) in this case? We already throw it at line 228 if the
resource cannot be open.
--
best regards,
Anthony
On 7/1/2014 12:35 PM, Petr Pchelko wrote:
Hello,
The changes in the public API have been approved, so let me continue the
review process.
For your convenience:
The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
Until now we've been discussing an abstract question of moving the
properties to a different location and agreed that it's possible.
Now it's time for an official code review. Could someone please make one?
Also some feedback from the build team is still required. Could someone
from the build team review this fix please?
(The question is that I've made a separate explicit rule for
flavormap.properties file. If I add it to COPY_PATTERNS than the solaris
version get's copied on Mac. Is that a bug in the build system? Is my
current solution good enough?)
Thank you.
With best regards. Petr.
On 20 июня 2014 г., at 15:50, Alan Bateman <alan.bate...@oracle.com
<mailto:alan.bate...@oracle.com>> wrote:
On 20/06/2014 12:41, Petr Pchelko wrote:
Hello, Anthony, Artem.
Do we officially declare that we drop support for this possibility?
This possibility will be dropped regardless of the current Petr's
fix, since there will be no single "jre" folder in jigsaw world.
Probably, some other mechanism to customize files like
flavormap.properties or logging.properties will be introduced.
And we can add a system property to set an alternative
flavormap.properties file later if someone would request such a feature.
BTW, the current fix is not about flavormap.properties on its own,
but about removing AWT.DnD.flavorMapFileURL toolkit property. I
would suggest to push this change as a separate bug fix, not as a
part of 8047336.
And also about changing flavormap.properties format) The current fix
is all the work in datatransfer modularization that needs a CCC. All
changes seem related, so I would prefer no to split it further,
because it would make it harder to track when all the peaces are
integrated to jake repository to continue the work. And it would need
more CCC requests which consume time.
The forum post looks like is from 2001. If there doesn't appear that
many developers have resorted to editing that file then I would
suggest just going with what you have. If it really becomes necessary
to support having configuration elsewhere (not in the JDK image) then
I don't think anything that you have now precludes that.
-Alan.
