You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Vladimir Beliaev <vl...@gmail.com> on 2007/04/19 15:11:56 UTC
[classlib][kernel] removing SecurityUtils from classlib
Hello,
Your comments are welcome on the points below - please take a look & comment
if you see the issues.
I'm fixing compliation warnings in DRLVM Kernel Classes (to increase the
overall visual quality of this component - 98 warnings seem to be quite a
lot). Please see
http://issues.apache.org/jira/browse/HARMONY-3694 for details...
Anyway, it turned out that both DRLVM & CLASSLIB have two same classes
defined - SecurityUtils & PolicyUtils. These classes are the same in
general, so looks like they worth being removed from one of locations.
PolicyUtils is used both in CLASSLIB & DRLVM. So I want to remove
PolicyUtils copy from DRLVM:
- what I do not like here is that DRLVM Kernel Classes implementation
starts depending from CLASSLIB implementation (since CLASSLIB's PolicyUtils
is located in implementatioj package
org.apache.harmony.security.fortresspackage). Still the duplication
seems to be the worse case.
SecuirtyUtils is never used in CLASSLIB. So I want to remove its copy from
CLASSLIB. There are two points here:
1. DRLVM version is located in a bit different package:
org.apache.harmony.fortress.security. So I want to rename the package to one
used in CLASSLIB. The reason is that this package classes define the public
API which should be accessible from system classes only. The coresponding
settings controls this in java.security file.
2. DRLVM does not use error messages internationalization (like CLASSLIB
version does). The diff shows something like:
<[classlib] throw new NullPointerException(Messages.getString("
security.140")); //$NON-NLS-1$
---
>[drlvm ] throw new NullPointerException("thread can not be
null");
I want to keep not internationalized version of SecurityUtils. The reason is
that such an itternationalization requires a use of CLASSLIB implementation
specific class - org.apache.harmony.security.internal.nls.Messages - which
is not right (as I wrote above).
--
Vladimir Beliaev
Re: [classlib][kernel] removing SecurityUtils from classlib
Posted by Vladimir Beliaev <vl...@gmail.com>.
Thanks for answers. SecurityUtils was removd from CLASSLIB.
PolicyUtils was removed from DRLVM. Again, there is a drawback - Kernel
Classes refer to particular Classlib implementation. Still because of there
are a lot of calls in CLASSLIB to PolicyUtils.matchSubset & there is no
another CLASSLIB implementation on top of DRLVM I did not copy "matchSubset"
to AccessControlContext - this allows avoiding duplicating 'matchSubset'...
Thanks
Vladimir Beliaev
2007/4/20, Leo Li <li...@gmail.com>:
>
> +1
> Besides, I have tried to remove the SecurityUtils class, and it is OK with
> IBM VME.
>
> On 4/20/07, Stepan Mishura <st...@gmail.com> wrote:
> >
> > On 4/19/07, Vladimir Beliaev wrote:
> > > Hello,
> > >
> > > Your comments are welcome on the points below - please take a look &
> > comment
> > > if you see the issues.
> > >
> > > I'm fixing compliation warnings in DRLVM Kernel Classes (to increase
> the
> > > overall visual quality of this component - 98 warnings seem to be
> quite
> > a
> > > lot). Please see
> > > http://issues.apache.org/jira/browse/HARMONY-3694 for details...
> > >
> > > Anyway, it turned out that both DRLVM & CLASSLIB have two same classes
> > > defined - SecurityUtils & PolicyUtils. These classes are the same in
> > > general, so looks like they worth being removed from one of locations.
> > >
> > > PolicyUtils is used both in CLASSLIB & DRLVM. So I want to remove
> > > PolicyUtils copy from DRLVM:
> > > - what I do not like here is that DRLVM Kernel Classes
> implementation
> > > starts depending from CLASSLIB implementation (since CLASSLIB's
> > PolicyUtils
> > > is located in implementatioj package
> > > org.apache.harmony.security.fortresspackage). Still the duplication
> > > seems to be the worse case.
> > >
> >
> > Only PolicyUtils.matchSubset method is used by DRL VM. The method is
> > quite small and does nothing special - just matches two arrays. Why
> > not copy it to DRL VM's AccessControlContext class?
> >
> > Thanks,
> > Stepan.
> >
> > > SecuirtyUtils is never used in CLASSLIB. So I want to remove its copy
> > from
> > > CLASSLIB. There are two points here:
> > >
> > > 1. DRLVM version is located in a bit different package:
> > > org.apache.harmony.fortress.security. So I want to rename the package
> to
> > one
> > > used in CLASSLIB. The reason is that this package classes define the
> > public
> > > API which should be accessible from system classes only. The
> > coresponding
> > > settings controls this in java.security file.
> > >
> > > 2. DRLVM does not use error messages internationalization (like
> CLASSLIB
> > > version does). The diff shows something like:
> > > <[classlib] throw new NullPointerException(
> > Messages.getString("
> > > security.140")); //$NON-NLS-1$
> > > ---
> > > >[drlvm ] throw new NullPointerException("thread can not
> > be
> > > null");
> > >
> > > I want to keep not internationalized version of SecurityUtils. The
> > reason is
> > > that such an itternationalization requires a use of CLASSLIB
> > implementation
> > > specific class - org.apache.harmony.security.internal.nls.Messages -
> > which
> > > is not right (as I wrote above).
> > >
> > > --
> > > Vladimir Beliaev
> > >
> >
> >
> > --
> > Stepan Mishura
> > Intel Enterprise Solutions Software Division
> >
>
>
>
> --
> Leo Li
> China Software Development Lab, IBM
>
--
Vladimir Beliaev
Intel Middleware Products Division
Re: [classlib][kernel] removing SecurityUtils from classlib
Posted by Leo Li <li...@gmail.com>.
+1
Besides, I have tried to remove the SecurityUtils class, and it is OK with
IBM VME.
On 4/20/07, Stepan Mishura <st...@gmail.com> wrote:
>
> On 4/19/07, Vladimir Beliaev wrote:
> > Hello,
> >
> > Your comments are welcome on the points below - please take a look &
> comment
> > if you see the issues.
> >
> > I'm fixing compliation warnings in DRLVM Kernel Classes (to increase the
> > overall visual quality of this component - 98 warnings seem to be quite
> a
> > lot). Please see
> > http://issues.apache.org/jira/browse/HARMONY-3694 for details...
> >
> > Anyway, it turned out that both DRLVM & CLASSLIB have two same classes
> > defined - SecurityUtils & PolicyUtils. These classes are the same in
> > general, so looks like they worth being removed from one of locations.
> >
> > PolicyUtils is used both in CLASSLIB & DRLVM. So I want to remove
> > PolicyUtils copy from DRLVM:
> > - what I do not like here is that DRLVM Kernel Classes implementation
> > starts depending from CLASSLIB implementation (since CLASSLIB's
> PolicyUtils
> > is located in implementatioj package
> > org.apache.harmony.security.fortresspackage). Still the duplication
> > seems to be the worse case.
> >
>
> Only PolicyUtils.matchSubset method is used by DRL VM. The method is
> quite small and does nothing special - just matches two arrays. Why
> not copy it to DRL VM's AccessControlContext class?
>
> Thanks,
> Stepan.
>
> > SecuirtyUtils is never used in CLASSLIB. So I want to remove its copy
> from
> > CLASSLIB. There are two points here:
> >
> > 1. DRLVM version is located in a bit different package:
> > org.apache.harmony.fortress.security. So I want to rename the package to
> one
> > used in CLASSLIB. The reason is that this package classes define the
> public
> > API which should be accessible from system classes only. The
> coresponding
> > settings controls this in java.security file.
> >
> > 2. DRLVM does not use error messages internationalization (like CLASSLIB
> > version does). The diff shows something like:
> > <[classlib] throw new NullPointerException(
> Messages.getString("
> > security.140")); //$NON-NLS-1$
> > ---
> > >[drlvm ] throw new NullPointerException("thread can not
> be
> > null");
> >
> > I want to keep not internationalized version of SecurityUtils. The
> reason is
> > that such an itternationalization requires a use of CLASSLIB
> implementation
> > specific class - org.apache.harmony.security.internal.nls.Messages -
> which
> > is not right (as I wrote above).
> >
> > --
> > Vladimir Beliaev
> >
>
>
> --
> Stepan Mishura
> Intel Enterprise Solutions Software Division
>
--
Leo Li
China Software Development Lab, IBM
Re: [classlib][kernel] removing SecurityUtils from classlib
Posted by Stepan Mishura <st...@gmail.com>.
On 4/19/07, Vladimir Beliaev wrote:
> Hello,
>
> Your comments are welcome on the points below - please take a look & comment
> if you see the issues.
>
> I'm fixing compliation warnings in DRLVM Kernel Classes (to increase the
> overall visual quality of this component - 98 warnings seem to be quite a
> lot). Please see
> http://issues.apache.org/jira/browse/HARMONY-3694 for details...
>
> Anyway, it turned out that both DRLVM & CLASSLIB have two same classes
> defined - SecurityUtils & PolicyUtils. These classes are the same in
> general, so looks like they worth being removed from one of locations.
>
> PolicyUtils is used both in CLASSLIB & DRLVM. So I want to remove
> PolicyUtils copy from DRLVM:
> - what I do not like here is that DRLVM Kernel Classes implementation
> starts depending from CLASSLIB implementation (since CLASSLIB's PolicyUtils
> is located in implementatioj package
> org.apache.harmony.security.fortresspackage). Still the duplication
> seems to be the worse case.
>
Only PolicyUtils.matchSubset method is used by DRL VM. The method is
quite small and does nothing special - just matches two arrays. Why
not copy it to DRL VM's AccessControlContext class?
Thanks,
Stepan.
> SecuirtyUtils is never used in CLASSLIB. So I want to remove its copy from
> CLASSLIB. There are two points here:
>
> 1. DRLVM version is located in a bit different package:
> org.apache.harmony.fortress.security. So I want to rename the package to one
> used in CLASSLIB. The reason is that this package classes define the public
> API which should be accessible from system classes only. The coresponding
> settings controls this in java.security file.
>
> 2. DRLVM does not use error messages internationalization (like CLASSLIB
> version does). The diff shows something like:
> <[classlib] throw new NullPointerException(Messages.getString("
> security.140")); //$NON-NLS-1$
> ---
> >[drlvm ] throw new NullPointerException("thread can not be
> null");
>
> I want to keep not internationalized version of SecurityUtils. The reason is
> that such an itternationalization requires a use of CLASSLIB implementation
> specific class - org.apache.harmony.security.internal.nls.Messages - which
> is not right (as I wrote above).
>
> --
> Vladimir Beliaev
>
--
Stepan Mishura
Intel Enterprise Solutions Software Division