[rfc][icedtea-web] PolicyEditor gains a real parser

[Jiri Vanek]

I was not reading whole thread (lazyyY!)

So maybe those were already answered:

Why OPTIONS.CODEBASE disapeared??? I can not see its replacement.

Also the patch do not apply   the  -        FILE("-file", "policy_file", "PBOFile"), and 
CODEBASE("-codebase", "url", "PBOCodebase"); definitions changed.

The code itself is pretty god - especially via using the
import sun.security.provider.PolicyParser;

*however*

http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/008072.html
"In JDK-9 we would have modules and you will not be able to use the sun.* packages at all, so this 
changeset is useless for JDK9. "

Makes me worrying about this approach. Especially also because of 
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-October/029989.html

So if we are going to use it, it sholdbe changed to public api. So you should have some adapter, 
which will allow simply switch between old and new api. And ofcourse, somebody have to negotiate it 
with upstream.. oh dear....

Also, I.m aware of
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-November/030101.html thread. It died 
without push. Or am I wrong?




To code:


  Why DisplayablePermission isnt regualr class?

the

+    /**
+     * PolicyEditor is only designed to deal with grant entries with a single codeBase -
+     * no signedBy and no principals. Any "identifiers" attached to grant entries which
+     * do not strictly match this will be ignored and not displayed in the UI.
+     */
+    static boolean isCodeBaseIdentifier(final PolicyIdentifier identifier) {
+        return (identifier.getSignedBy() == null || identifier.getSignedBy().isEmpty())
+                && (identifier.getPrincipals() == null || identifier.getPrincipals().isEmpty())
+                && identifier.getCodebase() != null;


MEans, that all other policies will be unvisible, but not lost.

What about showing them at least read only? Aka as plain text or something like it... It wouldbe 
suspicious if they are "just not there"



Why
  +public enum PolicyEditorPermissions implements Serializable {
is now serializable?
+public class PolicyEntry implements Serializable, Transferable {
again.. why so?
Because of: public static final DataFlavor DATA_FLAVOR
What is it for? For clipboard actions only?

MAybe rneame the DATA_FLAVOR o POLICY_ENTRY_DATA_FLAVOR or similar.


Why   public static class PolicyEntryBuilder { is initernal class?


May you please higligh usage of import sun.security.provider.PolicyParser; ?


The net.sourceforge.jnlp.security.policyeditor package have grown a lot. Maybe separate it to 
data/gui/rest/ ? Can be doen as another (following) changeset.



J.