date:20060821


+1

2006/8/18, Geir Magnusson Jr. [EMAIL PROTECTED]:

All is in order and in SVN for Harmony-1125 wrt BCC and ACQ.

Please vote to accept or reject this codebase into the Apache Harmony
class library :

[ ] + 1 Accept
[ ] -1 Reject  (provide reason below)

Lets let this run a minimum of 3 days unless a) someone states they need
more time or b) we get all committer votes before then.

geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][rmi] What's what

2006-08-21 Thread Alexey Petrenko


As far as I understood we are using rmi module in our build.

SY, Alexey

2006/8/20, Nathan Beyer [EMAIL PROTECTED]:

I must apologize for not paying the appropriate attention to the topics of
the RMI codebase, but is there anyone who can give an overview of what's
what?



There are three RMI folders under 'modules': 'rmi', 'rmi2' and 'rmi2.1.4'. I
believe that 'rmi' and 'rmi2' are two different submissions and 'rmi2.1.4'
is a Java 1.4 restricted version of 'rmi2'. Which one is actually getting
built and tested in the current builds? What are the major hold ups for
integration of the three codebases?



Thanks.



-Nathan






--
Alexey A. Petrenko
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] HARMONY-1105 : Accept Java Management Console


+1

2006/8/18, Geir Magnusson Jr. [EMAIL PROTECTED]:

All is in order and in SVN for Harmony-1105 wrt BCC and ACQ.

Please vote to accept or reject this codebase into the Apache Harmony
class library :

[ ] + 1 Accept
[ ] -1 Reject  (provide reason below)

Lets let this run a minimum of 3 days unless a) someone states they need
more time or b) we get all committer votes before then.

geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] HARMONY-1044 : Contribution of RMI Registry Service


+1

2006/8/18, Geir Magnusson Jr. [EMAIL PROTECTED]:

All is in order and in SVN for Harmony-1044 wrt BCC and ACQ.

Please vote to accept or reject this codebase into the Apache Harmony
class library :

[ ] + 1 Accept
[ ] -1 Reject  (provide reason below)

Lets let this run a minimum of 3 days unless a) someone states they need
more time or b) we get all committer votes before then.

geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][luni] Suspicious behavior of java.util.EnumSet


Spark Shen wrote:


But, do you agree to following RI on this strange behavior? 
Personally, I think throw an IllegalStateException here is more 
appropriate.

The spec for Iterator.remove() says:

Throws ||IllegalStateException - if the next method has not yet been 
called, or the remove method has already been called after the last call 
to the next method.


So IMHO, it doesn't follow spec to throw IllegalStateException here, if 
we think RI has bug here, the more careful solution is do nothing and 
return.


Best regards




--
Paulex Yang
China Software Development Lab
IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[classlib][instrument]and[VM]:launcher with parameter javaagent

2006-08-21 Thread Jimmy, Jing Lv


Hi,

On writing tests for java.lang.instrument, I find it nice Harmony 
launcher can accept parameter -javaagent currently. Look deep into the 
launcher code, I find the parameter was really parsed by VM itself 
currently.
And if I use J9VM, it can accept such parameter but ask for 
instrument.dll. As we know, Harmony naming convention use hyXXX.dll 
as dll-file name. So vm fails to load lib here. However if I copy the 
file hyinstrument.dll to instrument.dll, J9VM load it happily and 
pass my test on Instrument.
I do not know what does DRLVM or other VMs do here (I'd like to 
hear if jvmti has been implemented in DRLVM).


So Instrument testcases can not be put to svn until this problem is 
solved (or it'll break build!). I guess there are two ways here:
1. to work around, add a line in build.xml, copy the file to 
instrument.dll, and wait for VM to get updated. Or we change filename 
in build system forever?
2. I wonder if we can modify in launcher, parse the parameter and 
pass the dll filename to VM?


Any suggestions?Thanks!


--

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][luni] Suspicious behavior of java.util.EnumSet

2006-08-21 Thread Spark Shen

Leo Li 写道:
 If so, we cannot regard it as RI's bug. And I believe the size of 64
 and the
 existence of the deleted element depends on RI's algorithm especially it
 does not provide concurrent assurance. Maybe it is due to performance
 concerns, I am not sure.
 The curious thing is whether we should behave as RI since it says it
 may or
 may not show the effects of any modifications to the set that occur while
 the iteration is in progress.


So, what is your opinion? Should we follow RI on this behavior?

Best regards
 On 8/21/06, Spark Shen [EMAIL PROTECTED] wrote:

 Leo Li 写道:
  Hi, Spark:
  Yes, I think it is RI's bug.
  But It should throw ConcurrentModificationException as spec says:
  1. This exception may be thrown by methods that have detected
  concurrent modification of an object when such modification is not
  permissible.
  2. Note that this exception does not always indicate that an object
 has
  been concurrently modified by a *different* thread. If a single thread
  issues a sequence of method invocations that violates the contract
 of an
  object, the object may throw this exception. For example, if a thread
  modifies a collection directly while it is iterating over the
 collection
  with a fail-fast iterator, the iterator will throw this exception.
 
  The iterator 's remove() action relies on the result of previous
  next(), but is interrupted by the set.remove() method. I think it
 is the
  case.
 
  Besides, If the same thing is applied to Hashset:
  public static void main(String[] args) {
  HashSet set = new HashSet();
  Object o = new Object();
  set.add(o);
  Iterator iter = set.iterator();
  iter.next();
  set.remove(o);
  iter.remove();
  }
  It will throw ConcurrentModificationException as expected.:)
 
 
 There is a paragraph from spec clearly states that
 ConcurrentModificationException will never be thrown out from the
 iterator returned
 by EnumSet. Cited below:
 The returned iterator is /weakly consistent/: it will never throw
 |ConcurrentModificationException|
 cid:part1.01020909.06080700@gmail.com
 and it may or may not show the effects of any modifications to the set
 that occur while the iteration is in progress.

 Best regards
  On 8/19/06, Spark Shen [EMAIL PROTECTED] wrote:
 
  Hi All:
  The following behavior of RI java.util.EnumSet seems odd. Do you have
  any opinion on whether it is a bug of RI?
 
  import java.util.EnumSet;
  import java.util.Iterator;
  public class Test {
  static enum EnumFoo {
  a, b,
  }
 
  public static void main(String[] args){
  EnumSetEnumFoo set = EnumSet.noneOf(EnumFoo.class);
  set.add(EnumFoo.a);
  IteratorEnumFoo iterator = set.iterator();
  iterator.next();
 
  set.remove(EnumFoo.a);
  iterator.remove(); (1)
  // The output value is true
  System.out.println(set.contains(EnumFoo.a));
  // The output value is 64
  System.out.println(set.size());
  }
  }
  IMHO, when (1) is executed, an IllegalStateException should be thrown
  out, since the element EnumFoo.a does not exist at the moment.
  Any thoughts?
 
  Best regards
 
  --
  Spark Shen
  China Software Development Lab, IBM
 
 
  -
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:
 [EMAIL PROTECTED]
 
 
 
 


 -- 
 Spark Shen
 China Software Development Lab, IBM


 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]






-- 
Spark Shen
China Software Development Lab, IBM


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][luni] Suspicious behavior of java.util.EnumSet

2006-08-21 Thread Leo Li


In my opinion, it is just RI' s implementation and it is up to you as a
developer to make the choice.:)

On 8/21/06, Spark Shen [EMAIL PROTECTED] wrote:


Leo Li 写道:
 If so, we cannot regard it as RI's bug. And I believe the size of 64
 and the
 existence of the deleted element depends on RI's algorithm especially it
 does not provide concurrent assurance. Maybe it is due to performance
 concerns, I am not sure.
 The curious thing is whether we should behave as RI since it says it
 may or
 may not show the effects of any modifications to the set that occur
while
 the iteration is in progress.


So, what is your opinion? Should we follow RI on this behavior?

Best regards
 On 8/21/06, Spark Shen [EMAIL PROTECTED] wrote:

 Leo Li 写道:
  Hi, Spark:
  Yes, I think it is RI's bug.
  But It should throw ConcurrentModificationException as spec says:
  1. This exception may be thrown by methods that have detected
  concurrent modification of an object when such modification is not
  permissible.
  2. Note that this exception does not always indicate that an object
 has
  been concurrently modified by a *different* thread. If a single
thread
  issues a sequence of method invocations that violates the contract
 of an
  object, the object may throw this exception. For example, if a thread
  modifies a collection directly while it is iterating over the
 collection
  with a fail-fast iterator, the iterator will throw this exception.
 
  The iterator 's remove() action relies on the result of previous
  next(), but is interrupted by the set.remove() method. I think it
 is the
  case.
 
  Besides, If the same thing is applied to Hashset:
  public static void main(String[] args) {
  HashSet set = new HashSet();
  Object o = new Object();
  set.add(o);
  Iterator iter = set.iterator();
  iter.next();
  set.remove(o);
  iter.remove();
  }
  It will throw ConcurrentModificationException as expected.:)
 
 
 There is a paragraph from spec clearly states that
 ConcurrentModificationException will never be thrown out from the
 iterator returned
 by EnumSet. Cited below:
 The returned iterator is /weakly consistent/: it will never throw
 |ConcurrentModificationException|
 cid:part1.01020909.06080700@gmail.com
 and it may or may not show the effects of any modifications to the set
 that occur while the iteration is in progress.

 Best regards
  On 8/19/06, Spark Shen [EMAIL PROTECTED] wrote:
 
  Hi All:
  The following behavior of RI java.util.EnumSet seems odd. Do you
have
  any opinion on whether it is a bug of RI?
 
  import java.util.EnumSet;
  import java.util.Iterator;
  public class Test {
  static enum EnumFoo {
  a, b,
  }
 
  public static void main(String[] args){
  EnumSetEnumFoo set = EnumSet.noneOf(EnumFoo.class);
  set.add(EnumFoo.a);
  IteratorEnumFoo iterator = set.iterator();
  iterator.next();
 
  set.remove(EnumFoo.a);
  iterator.remove(); (1)
  // The output value is true
  System.out.println(set.contains(EnumFoo.a));
  // The output value is 64
  System.out.println(set.size());
  }
  }
  IMHO, when (1) is executed, an IllegalStateException should be
thrown
  out, since the element EnumFoo.a does not exist at the moment.
  Any thoughts?
 
  Best regards
 
  --
  Spark Shen
  China Software Development Lab, IBM
 
 
 
-
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:
 [EMAIL PROTECTED]
 
 
 
 


 --
 Spark Shen
 China Software Development Lab, IBM


 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]






--
Spark Shen
China Software Development Lab, IBM


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Leo Li
China Software Development Lab, IBM

Re: [DRLVM][MMTk] Jitrino.JET design questions on integrating the object allocation APIs

2006-08-21 Thread Mikhail Fursov


Hi Weldon,
I saw Alex 2 or 3 days ago and he told me that he will travel a lot for 2
weeks and will have a problems with access to the computer with Internet.
Anyway I think I can help you with the problem you have.

DRLVM already has a mechanism to filter methods between different execution
engines (JITs) by method names: Execution Manager's filters. So the easiest
way to call different object allocation helpers for different methods is to
build 2 jitrino.dll's. The first JIT library should keep the old helper call
and the second one should be patched to call a new helper.

After you have 2 libraries you can configure EM
http://incubator.apache.org/harmony/subcomponents/drlvm/emguide.html
which library(JIT version) to use to compile a method using method name
filters.

Is this solution solves your problem?

On 8/15/06, Weldon Washburn  [EMAIL PROTECTED] wrote:


Alex,

How hard would it be to modify Jitrino.JET to call a different object
allocation helper function on a method-by-method basis?  This would
help a bunch with integrating MMTk into DRLVM.  It would also be nice
to enable write barriers on a method-by-method basis.

Thanks
--
Weldon Washburn
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Mikhail Fursov

Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic

2006-08-21 Thread Egor Pasko

On the 0x1CB day of Apache Harmony Robin Garner wrote:
  The alternative method is to allow tlsSet and tlsGet be vmmagic
  themselves. Now system-dependent code is hidden within a JIT. The
  JIT-Threading is probably more tight here because JIT takes more
  code as vmmagic. Another obvious disadvantage is that JIT has to do
  more here.
 This is a slightly less general approach than what I suggested here:
 
  My thoughts on the thread-local storage issue is that it's a more
  general issue of accessing  shared data structures from the Java
  side of the fence.  So perhaps a method such as
 
  Object org.vmmagic.utility.accessVmStructure(identifier)
 
  where the identifier is some abstract constant that identifies all of
  the vm-specific data structures one might want to access.  Some of
  them might be slots in the tls area, but others might be elsewhere in
  the VM.
 
 As long as vmmagic is processed by the JIT after some constant
 propagation takes place it should be quite possible to compile this
 down to an optimal sequence of instructions.

Good idea, thanks! Let's start using it one day :)

  Hm, but I like this way more. The idea is quite elegant: hide
  system-dependent implementation details in high-level magics and let
  JIT optimize them out. Provide a slow implementation in API in case
  JIT does not recognize the magic. I Hope, there will be not a lot of
  large high-level system-dependente vmmagics around. In this case this
  approach is ideal for me.

 I agree completely, and heartily recommend using a small number of
 high-level features for these things.  When I first started work
 porting MMTk, the interface to the VM had a large number of ad-hoc
 methods for accessing all sorts of things.  The present state of
 vmmagic reflects a lot of work and thought by quite a few people on
 how to abstract over the many low-level mechanisms that the VM and
 MMTk used to use to interact.
 
 The idea of providing a slow implementation of higher level vmmagic in
 Java is interesting, but begs the question of which vmmagics you are
 ultimately going to use to implement *them*.

I am proposing to make no extra vmmagic for the slow implementation of
VM-specific accessors. We can make accessors using JNI calls directly
to VM (just like now in DRLVM)
 
 Finding the right level of abstraction has a payoff on both sides of
 the fence - the java code is cleaner, and there should be less work on
 the JIT side to implement a single general-purpose mechanism.

100% agree :)

-- 
Egor Pasko, Intel Managed Runtime Division


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New IBM VME available soon

2006-08-21 Thread Oliver Deakin


Leo Li wrote:

Hi, Oli:
It is really a problem that System.getenv fails to behave as RI on
windows. I will fix it by get env string out by os function such
as getenvironmentvariable and getenv. Thank you for your tips.


Thanks for looking at fixing this Leo :)


  Besides, the returned environment variables is only defined  in
the process of the java application, for example, the command windows, 
and

remains the same during the life cycle. :)


It's not possible that the environment variables could change during the 
lifetime
of the VM? If, for example, a Java program made a call out to native 
code, isn't it
quite possible that that native code to alter the environment variables, 
and thus

when we return to Java the environment of the process has changed?

Regards,
Oliver




Thank you, Oli.

Good luck!


--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[tools] Need a volunteer to write documentation for Keytool

2006-08-21 Thread Anton Rusanov


We have Keytool utility developed now and a draft of its user's guide
can be found at
enhanced/classlib/trunk/doc/tools/Keytool/Keytool_help.html. If there
is a person with technical writer skills who wants to evolve the draft
into real documentation I will be happy to answer all related
questions.

I would be very thankful if somebody will volunteer to write the documentation.

--
Thanks,
Anton

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][rmi] What's what

We are, but it's high time to put this to rest...

I'll start a separate thread to drive this to conclusion.

geir


Alexey Petrenko wrote:
 As far as I understood we are using rmi module in our build.
 
 SY, Alexey
 
 2006/8/20, Nathan Beyer [EMAIL PROTECTED]:
 I must apologize for not paying the appropriate attention to the
 topics of
 the RMI codebase, but is there anyone who can give an overview of what's
 what?



 There are three RMI folders under 'modules': 'rmi', 'rmi2' and
 'rmi2.1.4'. I
 believe that 'rmi' and 'rmi2' are two different submissions and
 'rmi2.1.4'
 is a Java 1.4 restricted version of 'rmi2'. Which one is actually getting
 built and tested in the current builds? What are the major hold ups for
 integration of the three codebases?



 Thanks.



 -Nathan



 
 

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[classlib][rmi] DISCUSSION : Use the RMI modiule and move the others to archive

We've had multiple RMI modules hanging around for a while due to our
fortune of multiple submissions.

Would anyone have a problem if we 'retired' all except modules/rmi to
the archive, and then took whatever was needed from there?

geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)

2006-08-21 Thread Ivanov, Alexey A

Vladimir,

I am working to minimize hang-up of swing tests.

Regards,
--
Alexey A. Ivanov
Intel Middleware Product Division


-Original Message-
From: Vladimir Ivanov [mailto:[EMAIL PROTECTED]
Sent: Friday, August 18, 2006 4:28 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] [testing] Coverage (was Re: 37% of total test
execution time is spent in a single test)

The coverage information was updated on the wiki. Also, coverage for
accessibility, awt, instrument and sound modules was added. I have a
problem
to calculate coverage for swing module (test run hang up) so issue 564
will
be updated later.

 thanks, Vladimir


On 6/20/06, Paulex Yang [EMAIL PROTECTED] wrote:

 Vladimir Ivanov wrote:
  Classes from exclude list are now specified as green.
  I've update wiki
(http://wiki.apache.org/harmony/Coverage_information)
  and
  coverage pages.
 
 Great, thank you, Vladimir!
  Thanks,
   Vladimir
 
 
  On 6/16/06, Paulex Yang [EMAIL PROTECTED] wrote:
 
  Vladimir
 
  Vladimir Ivanov wrote:
  
   The current reports don't provide code source linking. Are you
  going to
 
   add it?
  
  
   There were no information for 'security' and 'auth' modules,
but, I
  have
   updated the pages and now there is source code linking for all
  modules.
  
   One more issue to discuss: excluded classes present in the
coverage
  table
   now with 0 coverage. May be it is more convenient do not have
these
   classes
   in coverage tables at all? In this case one won't wonder why the
 class
   has 0
   coverage - go to exclude list to look at the class and decide
whether
  the
   class is really untested or just excluded from coverage,
instead,
all
   really
   uncovered classes will be shown with 0 coverage, if a class is
  missed in
   coverage table - it is in exclude list.
  +1 for current 0 coverage is not convenient. But if we can
remove
 them
  from the report, how about just mark them in another way? say,
mark
the
  excluded class with different background colors?
 
  At least people don't need to care about two documents for one
package.
   Thanks,
 Vladimir
  
  
  
   Now I have 2 questions/ issues to discuss:
1) preferable VM to calculate coverage (seems, the exclude
list
  is a
little
bit different for j9 and drlvm)
  
  
   If the only difference is the exclude list then I'd suggest
using
VM
   with
   the shortest one. :-)
  
   2) preferable sorting mode for results (by name, by blocks or
by
   methods)
  
  
   IMHO, sorting by name looks more natural.
  
   Thanks,
   Stepan.
  
   Thanks,
Vladimir
   
SNIP
   
  
  
   --
   Terms of use : http://incubator.apache.org/harmony/mailing.html
   To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
   For additional commands, e-mail:
  [EMAIL PROTECTED]
  
  
  
 
 
  --
  Paulex Yang
  China Software Development Lab
  IBM
 
 
 
 
-
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail:
[EMAIL PROTECTED]
  For additional commands, e-mail:
[EMAIL PROTECTED]
 
 
 


 --
 Paulex Yang
 China Software Development Lab
 IBM



 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:
[EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] HARMONY-1044 : Contribution of RMI Registry Service


+1

-Mark

On 17 August 2006 at 15:53, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 All is in order and in SVN for Harmony-1044 wrt BCC and ACQ.
 
 Please vote to accept or reject this codebase into the Apache Harmony
 class library :
 
 [ ] + 1 Accept
 [ ] -1 Reject  (provide reason below)
 
 Lets let this run a minimum of 3 days unless a) someone states they need
 more time or b) we get all committer votes before then.
 
 geir
 
 
 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] HARMONY-1105 : Accept Java Management Console

+1

-Mark.

On 17 August 2006 at 15:53, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 All is in order and in SVN for Harmony-1105 wrt BCC and ACQ.
 
 Please vote to accept or reject this codebase into the Apache Harmony
 class library :
 
 [ ] + 1 Accept
 [ ] -1 Reject  (provide reason below)
 
 Lets let this run a minimum of 3 days unless a) someone states they need
 more time or b) we get all committer votes before then.
 
 geir
 
 
 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] HARMONY-1125 : thread manager patch for DRLVM

+1

-Mark.

On 17 August 2006 at 15:53, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 All is in order and in SVN for Harmony-1125 wrt BCC and ACQ.
 
 Please vote to accept or reject this codebase into the Apache Harmony
 class library :
 
 [ ] + 1 Accept
 [ ] -1 Reject  (provide reason below)
 
 Lets let this run a minimum of 3 days unless a) someone states they need
 more time or b) we get all committer votes before then.
 
 geir
 
 
 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[legal] Re: Bringing License arguments to Sun



Stefano Mazzocchi wrote:
 Geir Magnusson Jr wrote:
 
 CDDL is an example of clever lawyer work to modernize best licensing
 practices, but those are best practices in protection not in social
 empowerment!
 I don't understand that.  Do you see the CDDL as somehow restricting
 communities? 
 
 No, I see CDDL something that will significantly slow or hinter the
 licensing compatibility assessment from both the ASF and the FSF.
 
 I fully recognize the lack of IP protection in older licenses (which
 might look like a naive if we ignore it maybe it will go away policy )
 but I think that licensing the code, the trademarks and the IP
 separately is another fully viable strategy.

I'm going to assume that from here forward, when you say IP you mean
'patent'?

 
 I would use an MIT license for the code and a different license for the
 IP. The injected IP problem can be dealt with a contribution agreement
 which does *not* need to be part of the license (like apache did, for
 example).

But our license is very explicit about patents as well.

 
 As far as IP protection is concerned, Sun owns (or has acquired the
 rights to relicense) the existing IP, they will only need to be
 concerned about new ones coming in from contributions and for that they
 can have contributors sign IP agreements (like we do for Harmony, for
 example, even if the license, in theory, already covers that).

Yes

 
 So, in theory, one could take an MIT-licensed RI, add some code with
 special IP (say a new garbage collector), pass the tests and then decide
 to charge people for the license of that IP.

Yes - I'm all for that.  And you can achieve that w/ CDDL also.  (I'm
not pushing CDDL here - my choice would be Apache License knowing that
all will be well w/ GPLv3, which I thought was scheduled to arrive at
about the same time as the code from Sun anyway...

 
 Sun could decide that they consider this free riding and that they
 want everybody to have a piece of that cake, so they can use a license
 that is not violently reciprocal on code donations but it is on IP (and
  CDDL falls under this category).
 
 The problem with this, it's that it makes it incompatible with the GPL,
 ending up alienating some of the very people they are counting on
 pleasing (and you can expect all sort of internal and external
 frustration would that happen).

But GPLv3 is coming.

 
 So, the choice is, in my eyes, whether to 'enforce' the reciprocity of
 IP licensing of not.
 
 Here, there is a lesson to be learned from the reciprocity on code: the
 BSD license does *not* force you to contribute back but many do anyway,
 and the freedom of being allowed *not to* is what makes the BSD license
 more palatable than, say, the GPL to many (unless you use a mysql-like
 unlock-the-gpl business model, which is another [legal]story).

Few things in this paragraph :

1) I prefer to think of BSD as not restricting your freedom, rather than
 allowing you to something, but as it is a license, it is in a sense
allowing the freedom.

2) MySQL - No comment, other than I'd not be too keen in participating
in a MySQL-like ecosystem around a Java implementation.

 
 People contribute back even if they are not forced to because it's
 convenient for them to do so, or they are left with the burden of
 maintaining a branch. The same exact argument applies to IP.

I don't see that.  There's no burden to not contributing patent licenses
to a codebase, compared to maintaining an internal fork if you choose
not to give modifications back to the community.

 
 So, if the RI license does *not* force people to donate the IP to the
 modifications that are made and redistributed (after passing the tests
 and obtaining certification), they are actually forking, just like OSI
 licenses are designed to allow. But they are now on their own, against
 the rest of the world. The FOSS ecology has shown that branches are very
 hard to maintain anyway, especially against very active and healthy
 communities (which has become the ASF motto, community is more important
 than code, and, I would add, a license has to protect the community more
 than the code).

I'm still not seeing it if my assumption about you meaning patent when
you say IP is valid - what it could do is create a situation where no
one would want to do anything out of fear of patent action.  Modern OSS
licenses solve this partway by having contributors explicitly license
patents they own that are covered by their contributions.


 
 And if the fork is killed or goes unfeasible and people try to inject
 known or submerged IP with contributions to the RI, the community
 watching and a solid contribution agreement will prevent that.
 
 In case of contributions that are covered by unknown IP, there is very
 little one can do to prevent in the license that covers the usage of
 the code.

I don't understand that sentence.

 
 My reasoning for going simple and non-reciprocal for both code and IP is
 *not* that I'm ignoring the issue,

Re: Bringing License arguments to Sun



robert burrell donkin wrote:
 On 8/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
 The only problem I see with the MIT license is the lack of modern patent
 language.   I'd like to see a license with that in place.
 
 there is no reason why patent and copyrights need to be covered
 together by a single license. the MIT license could be used for the
 copyright with a separate license to cover the patents.
 

How much would you pay for that license? ;)

geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][concurrent] Integrating into builds and snapshot



Nathan Beyer wrote:
 Now that we're getting some good submissions to make the
 java.util.concurrent code to work with DRLVM, I'd like make a proposal for
 getting the code in the Class Library and a part of our regular builds,
 tests and snapshots.
 
  
 
From a technical/code integration standpoint, the go ahead assumption is
 that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
 class, such that the concurrent code, most of which is in the public domain,
 from the Concurrency Interest Site [1] can be used as-is, as least to the
 greatest extent possible. Are there any major dissents to this?

This is my understanding of what we already agreed to, and I'm getting a
note from Doug about the code provenance.


 Now, the issue that's of most contention, at least from our past
 conversations, is the code management. First and foremost, we must consider
 the realities of the situation.
 
  
 
 1. The concurrency interest group, the JSR-166 expert group, Doug Lea and
 others are NOT producing distributable builds, so we can not integrate the
 code like we do other components, like Xerces, Xalan, MX4J, etc. I don't
 want to speak for anyone here, so I'll qualify this by saying that I haven't
 been told this explicitly, so this is just my inference from discussions and
 documentation. If this is not the case, then someone please speak up. There
 is an experimental JAR on the site [1], but it's meant specifically to run
 with the Sun RI and it contains code outside of the java.util.concurrent
 package space. Additionally, the TCK tests from the site [1], which we'd
 like to use are not packaged in any way.

Right - we should be able to slurp the tests in the same way as we do
the rest of it.  In fact, we are less worried about the tests because we
don't ship those.

And lets just call them tests, not TCK test, because while they are
used in the TCK,  something we get from Sun, they are just tests :)

 
  
 
 2. The code on the site [1] is only accessible through a ViewCVS Web
 interface. As such, it's not exactly easy to interact with in terms of
 created an automated checkout of the source to integrate into a build. One
 of my thoughts was using the svn:externals feature to download source
 dynamically, but there are additional issues that make that especially
 difficult; these issues follow. Besides that, I'm not sure that
 svn:externals works with arbitrary URLs that aren't SVN repositories.

Who cares?  We're not going to slurp the code from their site for
building...

 
 3. There is at least one source file that MUST NOT be used from the site [1]
 because it's not open to the public domain, the CopyOnWriteArrayList [2].
 This will require at least one class to be developed as part of the Harmony
 Class Library.

Yes.

 
 4. It's currently NOT feasible for Harmony to use the HEAD version of the
 code, as it has been updated to utilize several Java 6 APIs, which Harmony
 does not current provide, not even in stub form. Additionally, there is only
 one viable CVS tag (JSR166_PFD), but this tag is two years old and some of
 the code in it does not compile on current JLS3 compilers. This has been
 discussed on the mailing list previously; please search the archives if
 you're curious. As such, any checkouts out code that compiles would have to
 be done either using a date-based checkout (not really possible with
 ViewCVS) or a specific revision number for each file would have to be
 determined.
 
  
 
 Tactical Proposal (next 6 to 12 to ?? months) - 
 
 My proposals for integration of the concurrency code is to retrieve the
 latest possible codebase from the site [1], which is open to the public
 domain and check it into our repository.
 
 * This code would include the TCK tests. 

tests

 
 * From a build standpoint, this code would be handled just like any other
 module. 

For now, we stuff it into the harmony/standard part of the repo.

 
 * As a general rule, this code would NOT be subject to normal code patches.
 The suggested process would be to submit patches and fixes to the
 concurrency interest group [1] and if/when the patches are accepted and
 committed, the code can synchronized to get the updates. Upon occasion
 (every few months), code updates can be take from the site [1], if deemed
 necessary and appropriate. 

Right - I think people can and should submit the patches here to us
first, and we decide to reject or go to EG with them.  Of course, people
can independently talk to the EG, but they shouldn't try to represent
Harmony.


 
 * A minor issue is where the stub for the sun.misc.Unsafe class would be
 placed (for compiles); my suggestion would be to just make it part of the
 luni-kernel-stubs, but we can look at a concurrent-kernel-stubs JAR.

Sure.

 
 Strategic Proposal -
 
 Once we have code working, at least in a snapshot state, we can attempt to
 do a number of this to ease the process and discrepancies.
 
 * Once a CopyOnWriteArrayList implementation is completed, we

Re: [classlib][instrument]and[VM]:launcher with parameter javaagent



Jimmy, Jing Lv wrote:
 Hi,
 
 On writing tests for java.lang.instrument, I find it nice Harmony
 launcher can accept parameter -javaagent currently. Look deep into the
 launcher code, I find the parameter was really parsed by VM itself
 currently.
 And if I use J9VM, it can accept such parameter but ask for
 instrument.dll. As we know, Harmony naming convention use hyXXX.dll
 as dll-file name. 

Time to fix that.

 So vm fails to load lib here. However if I copy the
 file hyinstrument.dll to instrument.dll, J9VM load it happily and
 pass my test on Instrument.

Yay!

 I do not know what does DRLVM or other VMs do here (I'd like to hear
 if jvmti has been implemented in DRLVM).

I have zero interest in perpetuating the hy abhorrence.
 
 So Instrument testcases can not be put to svn until this problem is
 solved (or it'll break build!). I guess there are two ways here:
 1. to work around, add a line in build.xml, copy the file to
 instrument.dll, and wait for VM to get updated. Or we change filename
 in build system forever?

Yay!

 2. I wonder if we can modify in launcher, parse the parameter and
 pass the dll filename to VM?

That's a very good idea - then you can A/B test with known good
instrumentation.

geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New IBM VME available soon



Oliver Deakin wrote:
 Leo Li wrote:
 Hi, Oli:
 It is really a problem that System.getenv fails to behave as RI on
 windows. I will fix it by get env string out by os function such
 as getenvironmentvariable and getenv. Thank you for your tips.
 
 Thanks for looking at fixing this Leo :)
 
   Besides, the returned environment variables is only defined  in
 the process of the java application, for example, the command windows,
 and
 remains the same during the life cycle. :)
 
 It's not possible that the environment variables could change during the
 lifetime
 of the VM? If, for example, a Java program made a call out to native
 code, isn't it
 quite possible that that native code to alter the environment variables,
 and thus
 when we return to Java the environment of the process has changed?

Would you really ever want that?  Seems to be a safety issue.

geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Updated: (HARMONY-584) missing descriptions in @param tags


On 4 August 2006 at 6:49, Tim Ellison (JIRA) [EMAIL PROTECTED] wrote:
  [ http://issues.apache.org/jira/browse/HARMONY-584?page=all ]
 
 Tim Ellison updated HARMONY-584:
 
 
 Component/s: Contributions
  (was: Classlib)
 
  missing descriptions in @param tags
  ---
 
  Key: HARMONY-584
  URL: http://issues.apache.org/jira/browse/HARMONY-584
  Project: Harmony
   Issue Type: Improvement
   Components: Contributions
 Reporter: Anton Luht
 Priority: Trivial
  Attachments: check_incorrect_param.sh, incorrect_param.zip
 
 
  Some of .java sources have empty descriptions in @param tags, for example
  @param param name
  though they should have descriptions, e.g.
  @param param name description
  Please see the script for detecting such problems  and results of checking 
 SVN 412715 attached

I wonder if doctorj[1] checks for this.  It certainly does pick up some
other useful issues.

-Mark.

[1] doctorj.sf.net



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [legal] Re: Bringing License arguments to Sun

2006-08-21 Thread Dalibor Topic

On Mon, Aug 21, 2006 at 10:12:30AM -0400, Geir Magnusson Jr wrote:
 
 
 Stefano Mazzocchi wrote:

  That said, it's hard to deny that the ASF has never experienced, in 10
  years of operation, a single fork, despite the complete lack of
  reciprocity provisions in its licensing strategy, showing that, although
  counterintuitive, healthy communities are even more effective than
  licensing restrictions in protecting the evolution of a codebase.
 
 I agree with you, but there have been several forks over the years.  IBM
 forked httpd, IBM, JBoss, ObjectWeb others forked WS...  I'd even argue
 that Sun is technically forking Derby in their JavaDB product, and IBM
 pre-forked Derby with the Cloudscape product that was the source of
 Derby ... :)

I'd add OpenBSD's fork of httpd to that pile. It was created since
Apache License 2.0 was unacceptable for a core component of the OpenBSD 
distribution, and accordingly, the last acceptable version of httpd was
forked, cleaned up from no longer necessary code, and is being 
maintained by OpenBSD developers separately.

I also recall ASF's Director Roy Fielding posting on the debian-legal 
mailing list on November 14th, 2003, accusing Debian of maliciously 
forking httpd ... I assume he was whistled back by whoever holds the 
reigns on that project, as Apache didn't take legal action for all 
those alleged license violations, afaik, and Debian continues to 
distribute patched httpd packages, of course.

cheers,
dalibor topic

 
 There's nothing wrong with that, and it really never hurt our
 communities (as evidenced by the strength of httpd and WS as
 examples...), and in some cases, they came back or gave back.  We have
 no problems with people forking if they choose, as they tend to come
 back anyway.
 
 And I'm expecting that people will fork Harmony code, and I don't think
 that's bad.
 
 But that's orthogonal to the notion of patent freedom - I want to make
 sure we don't wind up in a situation where no one wants to do anything
 because of patent fears.
 
 Maybe the thing to do of patent-silent license is necessary is for Sun
 to work with the rest of the industry (IBM, BEA, Apple, MSFT, Intel etc)
 and create a patent commons of all patents each company owns related
 to Java, managed runtimes, etc, with a clear covenant not to sue...
 
 geir
 
 (Given that I mentioned my employer, Intel,  I want to make it clear
 that this is my personal opinion and should not be taken to represent
 the position of Intel Corporation)
 
 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] HARMONY-1125 : thread manager patch for DRLVM

2006-08-21 Thread Weldon Washburn


+1

On 8/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

All is in order and in SVN for Harmony-1125 wrt BCC and ACQ.

Please vote to accept or reject this codebase into the Apache Harmony
class library :

[ ] + 1 Accept
[ ] -1 Reject  (provide reason below)

Lets let this run a minimum of 3 days unless a) someone states they need
more time or b) we get all committer votes before then.

geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Weldon Washburn
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][concurrent] Integrating into builds and snapshot

2006-08-21 Thread Weldon Washburn


On 8/21/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:



Nathan Beyer wrote:
 Now that we're getting some good submissions to make the
 java.util.concurrent code to work with DRLVM, I'd like make a proposal for
 getting the code in the Class Library and a part of our regular builds,
 tests and snapshots.



From a technical/code integration standpoint, the go ahead assumption is
 that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
 class, such that the concurrent code, most of which is in the public domain,
 from the Concurrency Interest Site [1] can be used as-is, as least to the
 greatest extent possible. Are there any major dissents to this?

This is my understanding of what we already agreed to, and I'm getting a
note from Doug about the code provenance.



I was not able to see any open documentation on sun.misc.Unsafe on the
web.  I did notice emails that describe using sun.misc.Unsafe to
read/write specific memory addresses.  I suspect that both
sun.misc.Unsafe and Jikes vmmagic do essentially the same thing.  That
is, read/write and also compare/swap specific memory addresses from
Java code.

MMTk definitely relies on efficient JIT inlining of Jikes vmmagic.  It
also looks like java.util.concurrent needs efficient JIT inlining of
sun.misc.Unsafe.  If indeed both vmmagic and Unsafe do the same thing,
it probably does not make sense to rewrite Concurrency or MMTk.  In
other words, we might be stuck with supporting both APIs in the short
term.

In any case, can the sun.misc.Unsafe API be described on this mailing
list?  It would help us all figure out what existing pieces can be
reused to support high-performance java.util.concurrent.

Thanks

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Bringing License arguments to Sun

2006-08-21 Thread Wes Felter


Chris Gray wrote:

TCKs are special 
in that a particular version of the code is normative, so modified versions 
need to be clearly marked as such (Apache licence?).


If One TCK is so important, let me propose a semi-heretical idea: don't 
open it. Certainly the 400 JVM developers should be able to run the TCK, 
but it's not clear that they need to distribute modified versions. (Of 
course, they could still submit bug fixes and such to the TCK 
maintainers.) I don't think the Linux distros need to distribute the TCK 
either, so their OSI or die policy doesn't appear to affect the TCK.


Wes Felter - [EMAIL PROTECTED]


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Bringing License arguments to Sun



Wes Felter wrote:
 Chris Gray wrote:
 
 TCKs are special in that a particular version of the code is
 normative, so modified versions need to be clearly marked as such
 (Apache licence?).
 
 If One TCK is so important, let me propose a semi-heretical idea: don't
 open it. Certainly the 400 JVM developers should be able to run the TCK,
 but it's not clear that they need to distribute modified versions. (Of
 course, they could still submit bug fixes and such to the TCK
 maintainers.) I don't think the Linux distros need to distribute the TCK
 either, so their OSI or die policy doesn't appear to affect the TCK.


No one needs to redistribute the TCK, but I can't see any problem in it
happening.  Any derivative work isn't the TCK anyway, so there's no risk
 to the ecosystem there.

But having it in open source is a good thing - it means that more people
can have access to it.  I can see no reason to keep it closed.

geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Created: (HARMONY-1113) [classlib][beans]Harmony does not throw IllegalArgumentException for java.beans.PropertyEditorSupport.setAsText() while RI does.

2006-08-21 Thread Alexei Zakharov

Hi Mikhail,

BTW, there is a looking similar failure in the test
o.a.h.beans.tests.java.beans.CustomizedPersistenceDelegateTest#testProxyPD
:)

It doesn't seem to be a completely similar failure to me. IMO the
above test fails due the fact that we simply don't have persistence
delegates for proxies, nobody have implemented them till now. Well,
the similarity here is that we need to deal with the same mysterious
java.lang.reflect.Proxy class. :)
I'm going to occupy myself with the above issue on this weekend if
nobody objects.

Regards,

2006/8/16, Mikhail Loenko [EMAIL PROTECTED]:

It works, thanks for the patch!

BTW, there is a looking similar failure in the test

o.a.h.beans.tests.java.beans.CustomizedPersistenceDelegateTest#testProxyPD

Thanks,
Mikhail

2006/8/16, Mikhail Loenko [EMAIL PROTECTED]:
Sure!

2006/8/16, Alexei Zakharov [EMAIL PROTECTED]:
Mikhail,

But there are two remaining failures related to
Proxy. That area is completely new for me and I guess it's caused
by incorrect process of Object's methods including equals().
Can you guys take a look?

I have created HARMONY-1207 that fixes the above problem. Could you
please take a look at it?

Thanks,

2006/8/14, Mikhail Loenko [EMAIL PROTECTED]:
2006/8/14, Alexei Zakharov [EMAIL PROTECTED]:
Ilya,

Thus test_setAsTextNull is redundant but
other two test cases have to be added.

This is exactly what I mean.
BTW, If you have more patches (or free time) for java.beans you are
highly welcome. I have already tired from working on this package
alone. :)

You are not alone :)

BTW, I've managed to fix most of the failures in
org.apache.harmony.beans.tests.java.beans.PropertyEditorSupportTest
they were caused by a bug in no-arg constructor of
PropertyEditorSupport
I'll commit the fix tomorrow. But there are two remaining failures
related to
Proxy. That area is completely new for me and I guess it's caused
by incorrect process of Object's methods including equals().

Can you guys take a look?

Thanks,
Mikhail

Regards,

2006/8/14, Ilya Okomin [EMAIL PROTECTED]:
On 8/14/06, Alexei Zakharov [EMAIL PROTECTED] wrote:

Hi Ilya,

FYI there is the existing class
org.apache.harmony.beans.tests.java.beans.PropertyEditorSupportTest
that contains all tests for PropertyEditorSupport. IMHO it would be
better if you embed your tests into this class. BTW, you may also
take
a look at existent
testSetAsText
method since it seems it does the same job.

Thanks for suggested solution, I've already done it before read your
message
:-)

Hmmm..you right, existing one test testSetAsText is the same as
test_setAsTextNull.
Actually existing testSetAsText test doesn't cover the problem,
according to
the documentation setAsText method behavior depends on the object
state
(rather newValue field type), thus we have to take into account the
type of
the newValue before setAsText call, if it is instanse of String or
not. I've
created tests for these cases. Thus test_setAsTextNull is redundant
but
other two test cases have to be added.

Regards,
Alexei

P.S. thanks for the patch :)

Always welcome!

Thanks,
Ilya.

2006/8/14, Ilya Okomin [EMAIL PROTECTED]:
Hello, Mikhail!

Provided test case can work from classpath of course. It's my
mistake,
thanks for noticed it. I'll prepare updated test case' patch with
correct
packaging and taking into account exceptions handling
recommendation
ASAP.

Thanks,
Ilya.

On 8/14/06, Mikhail Loenko [EMAIL PROTECTED] wrote:

Hi Ilya

Is it significant that the test code is in bootclasspath, or it
can
work from classpath?

There were some discussions around the tests that might be
interesting,
please look at [1].

Please look at the section
Utilize JUnit's assert/fail methods and exception handling for
clean
test
code

This also might be useful [2]

Thanks,
Mikhail

[1]

http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL PROTECTED]

[2]

http://incubator.apache.org/harmony/subcomponents/classlibrary/agreements.html

2006/8/9, Ilya Okomin (JIRA) [EMAIL PROTECTED]:
[classlib][beans]Harmony does not throw
IllegalArgumentException for
java.beans.PropertyEditorSupport.setAsText() while RI does.

Re: [vote] HARMONY-1105 : Accept Java Management Console

2006-08-21 Thread Alexei Zakharov


+1 from me

2006/8/21, Mark Hindess [EMAIL PROTECTED]:

+1

-Mark.

On 17 August 2006 at 15:53, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 All is in order and in SVN for Harmony-1105 wrt BCC and ACQ.

 Please vote to accept or reject this codebase into the Apache Harmony
 class library :

 [ ] + 1 Accept
 [ ] -1 Reject  (provide reason below)

 Lets let this run a minimum of 3 days unless a) someone states they need
 more time or b) we get all committer votes before then.

 geir


 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Alexei Zakharov,
Intel Middleware Product Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DRLVM][MMTk] Jitrino.JET design questions on integrating the object allocation APIs

2006-08-21 Thread Weldon Washburn


Hi Mikhail,
I think your suggestion below will work.  I will try it hopefully in
the next few weeks.
 Thanks



On 8/21/06, Mikhail Fursov [EMAIL PROTECTED] wrote:

Hi Weldon,
I saw Alex 2 or 3 days ago and he told me that he will travel a lot for 2
weeks and will have a problems with access to the computer with Internet.
Anyway I think I can help you with the problem you have.

DRLVM already has a mechanism to filter methods between different execution
engines (JITs) by method names: Execution Manager's filters. So the easiest
way to call different object allocation helpers for different methods is to
build 2 jitrino.dll's. The first JIT library should keep the old helper call
and the second one should be patched to call a new helper.

After you have 2 libraries you can configure EM
http://incubator.apache.org/harmony/subcomponents/drlvm/emguide.html
which library(JIT version) to use to compile a method using method name
filters.

Is this solution solves your problem?

On 8/15/06, Weldon Washburn  [EMAIL PROTECTED] wrote:

 Alex,

 How hard would it be to modify Jitrino.JET to call a different object
 allocation helper function on a method-by-method basis?  This would
 help a bunch with integrating MMTk into DRLVM.  It would also be nice
 to enable write barriers on a method-by-method basis.

 Thanks
 --
 Weldon Washburn
 Intel Middleware Products Division

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
Mikhail Fursov





--
Weldon Washburn
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

java.rmi package contribution test suites

2006-08-21 Thread FaeLLe


Hello,

I have pulled the java.rmi.* contribution code from the Harmony SVN and was
examining the test cases for the RMI DGC.Have a few questions about how the
test is performed if anyone can clarify them for me.

As far as I have understood the following is how the operation is,


  - TestDistributedGarbageCollector.java acts as the RMI server.
  - It creates a RMI registry on port 1099.
  - Sets the Garbage collection parameters.
  - Creates a new echoServer.
  - Binds echoServer as Echo2.
  - Uses ProcessBuilder to launch EchoClient2 process.
  - Unbind's Echo2 after Thread sleep.
  - The RMI client Echo2 looks for Echo2 in RMI Registry.
  - Enters EchoTest2 after echo(String) is called on stub.
  - Returns the display to be shown.
  - Invoke's System.gc().


When the client is Garbage collected it creates a new file name done.


However some things confuse me and it would nice if you could clarify them
for me.


  - I notice the TestDistributedGarbageCollector class has two Threads
  that perform sleep, what is the second sleep Thread for ?
  - I notice it invokes runGc() method but what does it test ? I have
  seen WeakReference being created and a GC call being performed but what does
  it test ?
  - Why after the second sleep Thread is a file f created ?
  - How does the assertTrue function of JUnit work with file f ?
  - How does it determine if GC has taken place ? How will it use f to
  determine that
  - If it determines that garbage collection has failed if f still
  exists why is f created before the assert statement ?

Thanks for helping me out and I know it is quite a lot of questions but your
help will benifit me greatly.

Yours Sincierly,

- Vikram Mohan


--
www.FaeLLe.com
www.VikramMohan.com

Re: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the others to archive

2006-08-21 Thread FaeLLe


I have examined the ITC rmi suite contribution and I think they should work
with the Intel contribution to integrate the best of two.

On 8/21/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:


We've had multiple RMI modules hanging around for a while due to our
fortune of multiple submissions.

Would anyone have a problem if we 'retired' all except modules/rmi to
the archive, and then took whatever was needed from there?

geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
www.FaeLLe.com
www.VikramMohan.com

Re: [tools] Need a volunteer to write documentation for Keytool

2006-08-21 Thread Geir Magnusson Jr.


Anton Rusanov wrote:

We have Keytool utility developed now and a draft of its user's guide
can be found at
enhanced/classlib/trunk/doc/tools/Keytool/Keytool_help.html. If there
is a person with technical writer skills who wants to evolve the draft
into real documentation I will be happy to answer all related
questions.

I would be very thankful if somebody will volunteer to write the 
documentation.




What might be helpful is to create a new JIRA issue with this, under the 
'doc' category.


geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [classlib][concurrent] Integrating into builds and snapshot

2006-08-21 Thread Nathan Beyer

I think we're on the same page for all of this except for the placement of
the public domain code. I didn't state it explicitly, but my assumption was
that all of the code would go under the
'enhanced/classlib/trunk/modules/concurrent'. I probably should have stated
this, but I so rarely work outside of 'enhanced' that it slipped my mind. I
don't really care, but I'm not sure how we'd work the build.

Are you thinking that we can svn:external the code from 'standard' to
'enhanced', such that most of it just overlays a normal module code layout?

The other options are having the build traverse up from classlib to standard
or have two JARs one with the public domain code and one with Harmony code
(COWAL). The public domain JAR could be built once and checked into the
depends under classlib.

-Nathan

 -Original Message-
 From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
 Sent: Monday, August 21, 2006 9:21 AM
 To: harmony-dev@incubator.apache.org
 Subject: Re: [classlib][concurrent] Integrating into builds and snapshot
 
 
 
 Nathan Beyer wrote:
  Now that we're getting some good submissions to make the
  java.util.concurrent code to work with DRLVM, I'd like make a proposal
 for
  getting the code in the Class Library and a part of our regular builds,
  tests and snapshots.
 
 
 
 From a technical/code integration standpoint, the go ahead assumption is
  that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
  class, such that the concurrent code, most of which is in the public
 domain,
  from the Concurrency Interest Site [1] can be used as-is, as least to
 the
  greatest extent possible. Are there any major dissents to this?
 
 This is my understanding of what we already agreed to, and I'm getting a
 note from Doug about the code provenance.
 
 
  Now, the issue that's of most contention, at least from our past
  conversations, is the code management. First and foremost, we must
 consider
  the realities of the situation.
 
 
 
  1. The concurrency interest group, the JSR-166 expert group, Doug Lea
 and
  others are NOT producing distributable builds, so we can not integrate
 the
  code like we do other components, like Xerces, Xalan, MX4J, etc. I don't
  want to speak for anyone here, so I'll qualify this by saying that I
 haven't
  been told this explicitly, so this is just my inference from discussions
 and
  documentation. If this is not the case, then someone please speak up.
 There
  is an experimental JAR on the site [1], but it's meant specifically to
 run
  with the Sun RI and it contains code outside of the java.util.concurrent
  package space. Additionally, the TCK tests from the site [1], which we'd
  like to use are not packaged in any way.
 
 Right - we should be able to slurp the tests in the same way as we do
 the rest of it.  In fact, we are less worried about the tests because we
 don't ship those.
 
 And lets just call them tests, not TCK test, because while they are
 used in the TCK,  something we get from Sun, they are just tests :)
 
 
 
 
  2. The code on the site [1] is only accessible through a ViewCVS Web
  interface. As such, it's not exactly easy to interact with in terms of
  created an automated checkout of the source to integrate into a build.
 One
  of my thoughts was using the svn:externals feature to download source
  dynamically, but there are additional issues that make that especially
  difficult; these issues follow. Besides that, I'm not sure that
  svn:externals works with arbitrary URLs that aren't SVN repositories.
 
 Who cares?  We're not going to slurp the code from their site for
 building...
 
 
  3. There is at least one source file that MUST NOT be used from the site
 [1]
  because it's not open to the public domain, the CopyOnWriteArrayList
 [2].
  This will require at least one class to be developed as part of the
 Harmony
  Class Library.
 
 Yes.
 
 
  4. It's currently NOT feasible for Harmony to use the HEAD version of
 the
  code, as it has been updated to utilize several Java 6 APIs, which
 Harmony
  does not current provide, not even in stub form. Additionally, there is
 only
  one viable CVS tag (JSR166_PFD), but this tag is two years old and some
 of
  the code in it does not compile on current JLS3 compilers. This has been
  discussed on the mailing list previously; please search the archives if
  you're curious. As such, any checkouts out code that compiles would have
 to
  be done either using a date-based checkout (not really possible with
  ViewCVS) or a specific revision number for each file would have to be
  determined.
 
 
 
  Tactical Proposal (next 6 to 12 to ?? months) -
 
  My proposals for integration of the concurrency code is to retrieve the
  latest possible codebase from the site [1], which is open to the public
  domain and check it into our repository.
 
  * This code would include the TCK tests.
 
 tests
 
 
  * From a build standpoint, this code would be handled just like any
 other
  module.
 
 For

RE: [vote] HARMONY-1105 : Accept Java Management Console

2006-08-21 Thread Nathan Beyer

+1 (a little late)

 -Original Message-
 From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
 Sent: Thursday, August 17, 2006 2:54 PM
 To: harmony-dev@incubator.apache.org
 Subject: [vote] HARMONY-1105 : Accept Java Management Console
 
 All is in order and in SVN for Harmony-1105 wrt BCC and ACQ.
 
 Please vote to accept or reject this codebase into the Apache Harmony
 class library :
 
 [ ] + 1 Accept
 [ ] -1 Reject  (provide reason below)
 
 Lets let this run a minimum of 3 days unless a) someone states they need
 more time or b) we get all committer votes before then.
 
 geir
 
 
 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the others to archive

2006-08-21 Thread Nathan Beyer

I like this approach. Anyone that wants to integrate changes can just submit
patches.

 -Original Message-
 From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
 Sent: Monday, August 21, 2006 8:34 AM
 To: harmony-dev@incubator.apache.org
 Subject: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the
 others to archive

 We've had multiple RMI modules hanging around for a while due to our
 fortune of multiple submissions.

 Would anyone have a problem if we 'retired' all except modules/rmi to
 the archive, and then took whatever was needed from there?

 geir

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[classlib][security] SecurityManager.checkPropertyAccess(String) bug?

2006-08-21 Thread Andrew Zhang


Hi all,

I noticed that Harmony security manager throws unexpected security exception
even when policy file allows the permission. I have raised HARMONY-1242(
http://issues.apache.org/jira/browse/HARMONY-1242) for record.  Would
anybody help have a look? Thanks!



On 8/21/06, Andrew Zhang (JIRA) [EMAIL PROTECTED] wrote:


[classlib][security] SecurityManager.checkPropertyAccess(java.version)
throws unexpected exception.

--

Key: HARMONY-1242
URL: http://issues.apache.org/jira/browse/HARMONY-1242
Project: Harmony
 Issue Type: Bug
 Components: Classlib
   Reporter: Andrew Zhang


Following test reproduces the bug:

public void test_checkPropertyAccess() throws Exception {
 SecurityManager manager = new SecurityManager();
 manager.checkPropertyAccess(java.version);
   }

The test passes against RI while fails against Harmony.
I have checked  java.policy security file, which also allows permission
java.util.PropertyPermission java.version,read; by default.

Would any security guys help investigate this issue? Thanks a lot!

Best regards,
Andrew


--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira






--
Andrew Zhang
China Software Development Lab, IBM

Re: [classlib][security] SecurityManager.checkPropertyAccess(String) bug?


Looking

2006/8/22, Andrew Zhang [EMAIL PROTECTED]:

Hi all,

I noticed that Harmony security manager throws unexpected security exception
even when policy file allows the permission. I have raised HARMONY-1242(
http://issues.apache.org/jira/browse/HARMONY-1242) for record.  Would
anybody help have a look? Thanks!



On 8/21/06, Andrew Zhang (JIRA) [EMAIL PROTECTED] wrote:

 [classlib][security] SecurityManager.checkPropertyAccess(java.version)
 throws unexpected exception.

 
--

 Key: HARMONY-1242
 URL: http://issues.apache.org/jira/browse/HARMONY-1242
 Project: Harmony
  Issue Type: Bug
  Components: Classlib
Reporter: Andrew Zhang


 Following test reproduces the bug:

 public void test_checkPropertyAccess() throws Exception {
  SecurityManager manager = new SecurityManager();
  manager.checkPropertyAccess(java.version);
}

 The test passes against RI while fails against Harmony.
 I have checked  java.policy security file, which also allows permission
 java.util.PropertyPermission java.version,read; by default.

 Would any security guys help investigate this issue? Thanks a lot!

 Best regards,
 Andrew


 --
 This message is automatically generated by JIRA.
 -
 If you think it was sent incorrectly contact one of the administrators:
 http://issues.apache.org/jira/secure/Administrators.jspa
 -
 For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Andrew Zhang
China Software Development Lab, IBM




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][security] SecurityManager.checkPropertyAccess(String) bug?


Andrew Zhang wrote:

Hi all,

I noticed that Harmony security manager throws unexpected security 
exception

even when policy file allows the permission. I have raised HARMONY-1242(
http://issues.apache.org/jira/browse/HARMONY-1242) for record.  Would
anybody help have a look? Thanks!

Seems SecurityManager pass correct permission instance to 
AccessController, should it be AccessController's issue?



On 8/21/06, Andrew Zhang (JIRA) [EMAIL PROTECTED] wrote:


[classlib][security] SecurityManager.checkPropertyAccess(java.version)
throws unexpected exception.

-- 



Key: HARMONY-1242
URL: http://issues.apache.org/jira/browse/HARMONY-1242
Project: Harmony
 Issue Type: Bug
 Components: Classlib
   Reporter: Andrew Zhang


Following test reproduces the bug:

public void test_checkPropertyAccess() throws Exception {
 SecurityManager manager = new SecurityManager();
 manager.checkPropertyAccess(java.version);
   }

The test passes against RI while fails against Harmony.
I have checked  java.policy security file, which also allows 
permission

java.util.PropertyPermission java.version,read; by default.

Would any security guys help investigate this issue? Thanks a lot!

Best regards,
Andrew


--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: 
http://www.atlassian.com/software/jira










--
Paulex Yang
China Software Development Lab
IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] HARMONY-1044 : Contribution of RMI Registry Service


+1

Geir Magnusson Jr. wrote:

All is in order and in SVN for Harmony-1044 wrt BCC and ACQ.

Please vote to accept or reject this codebase into the Apache Harmony
class library :

[ ] + 1 Accept
[ ] -1 Reject  (provide reason below)

Lets let this run a minimum of 3 days unless a) someone states they need
more time or b) we get all committer votes before then.

geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Paulex Yang
China Software Development Lab
IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] HARMONY-1105 : Accept Java Management Console


+1

Geir Magnusson Jr. wrote:

All is in order and in SVN for Harmony-1105 wrt BCC and ACQ.

Please vote to accept or reject this codebase into the Apache Harmony
class library :

[ ] + 1 Accept
[ ] -1 Reject  (provide reason below)

Lets let this run a minimum of 3 days unless a) someone states they need
more time or b) we get all committer votes before then.

geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Paulex Yang
China Software Development Lab
IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][concurrent] Integrating into builds and snapshot

2006-08-21 Thread Geir Magnusson Jr.


Nathan Beyer wrote:

I think we're on the same page for all of this except for the placement of
the public domain code. I didn't state it explicitly, but my assumption was
that all of the code would go under the
'enhanced/classlib/trunk/modules/concurrent'. I probably should have stated
this, but I so rarely work outside of 'enhanced' that it slipped my mind. I
don't really care, but I'm not sure how we'd work the build.


Right - we'll figure that out.  I hope to get it into enhanced as well.



Are you thinking that we can svn:external the code from 'standard' to
'enhanced', such that most of it just overlays a normal module code layout?


Nope :)  I wasn't thinking anything.  it's a ugly mess that makes my 
head hurt.




The other options are having the build traverse up from classlib to standard
or have two JARs one with the public domain code and one with Harmony code
(COWAL). The public domain JAR could be built once and checked into the
depends under classlib.


That would be odd, code from std checked in.  Maybe we just tell devs to 
do it and drop the jar in there...


geir



-Nathan


-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
Sent: Monday, August 21, 2006 9:21 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][concurrent] Integrating into builds and snapshot



Nathan Beyer wrote:

Now that we're getting some good submissions to make the
java.util.concurrent code to work with DRLVM, I'd like make a proposal

for

getting the code in the Class Library and a part of our regular builds,
tests and snapshots.



From a technical/code integration standpoint, the go ahead assumption is
that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
class, such that the concurrent code, most of which is in the public

domain,

from the Concurrency Interest Site [1] can be used as-is, as least to

the

greatest extent possible. Are there any major dissents to this?

This is my understanding of what we already agreed to, and I'm getting a
note from Doug about the code provenance.



Now, the issue that's of most contention, at least from our past
conversations, is the code management. First and foremost, we must

consider

the realities of the situation.



1. The concurrency interest group, the JSR-166 expert group, Doug Lea

and

others are NOT producing distributable builds, so we can not integrate

the

code like we do other components, like Xerces, Xalan, MX4J, etc. I don't
want to speak for anyone here, so I'll qualify this by saying that I

haven't

been told this explicitly, so this is just my inference from discussions

and

documentation. If this is not the case, then someone please speak up.

There

is an experimental JAR on the site [1], but it's meant specifically to

run

with the Sun RI and it contains code outside of the java.util.concurrent
package space. Additionally, the TCK tests from the site [1], which we'd
like to use are not packaged in any way.

Right - we should be able to slurp the tests in the same way as we do
the rest of it.  In fact, we are less worried about the tests because we
don't ship those.

And lets just call them tests, not TCK test, because while they are
used in the TCK,  something we get from Sun, they are just tests :)




2. The code on the site [1] is only accessible through a ViewCVS Web
interface. As such, it's not exactly easy to interact with in terms of
created an automated checkout of the source to integrate into a build.

One

of my thoughts was using the svn:externals feature to download source
dynamically, but there are additional issues that make that especially
difficult; these issues follow. Besides that, I'm not sure that
svn:externals works with arbitrary URLs that aren't SVN repositories.

Who cares?  We're not going to slurp the code from their site for
building...


3. There is at least one source file that MUST NOT be used from the site

[1]

because it's not open to the public domain, the CopyOnWriteArrayList

[2].

This will require at least one class to be developed as part of the

Harmony

Class Library.

Yes.


4. It's currently NOT feasible for Harmony to use the HEAD version of

the

code, as it has been updated to utilize several Java 6 APIs, which

Harmony

does not current provide, not even in stub form. Additionally, there is

only

one viable CVS tag (JSR166_PFD), but this tag is two years old and some

of

the code in it does not compile on current JLS3 compilers. This has been
discussed on the mailing list previously; please search the archives if
you're curious. As such, any checkouts out code that compiles would have

to

be done either using a date-based checkout (not really possible with
ViewCVS) or a specific revision number for each file would have to be
determined.



Tactical Proposal (next 6 to 12 to ?? months) -

My proposals for integration of the concurrency code is to retrieve the
latest possible codebase from the site [1], which is open to the public
domain

Re: [classlib][text] Bidi returns directional runs in visual order rather than in logical

2006-08-21 Thread Richard Liang


Sorry for my late reply, Alexey.

I'm discussing this issue with ICU team, and have not drawn any conclusion till now. 


Richard.

Ivanov, Alexey A wrote:

Hello Richard,

Have you taken a look at this issue?

Thanks, 
--

Alexey A. Ivanov
Intel Middleware Product Division

  

-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 08, 2006 12:12 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][text] Bidi returns directional runs in visual


order
  

rather than in logical

Hello Ivanov,

I will have a look at this issue, and will give my feedback later.
Thanks a lot.

Best regards,
Richard.

Ivanov, Alexey A wrote:


All,

I'd like to attract more attention to this problem because this
incompatibility makes many tests in javax.swing.text package fail.
  

The
  

implementation of jx.s.t.AbstractDocument depends on j.t.Bidi.

The root of the problem lies in ICU library. Here we have two
  

options:
  

1. Fix the Bidi implementation, to be more precise its counterpart in
ICU;
2. Fix AbstractDocument to handle such illogical run order.


Can text guys comment on this issue?


I decided to cite the test case from the JIRA:
public class Test {
public static final String LTR = \u0061\u0062; // these are
  

ab
  

public static final String RTL = \u05DC\u05DD;
public static final String newLine = \n;

public static final String defText = LTR + newLine
 + RTL + LTR + RTL;
public static void main(String[] args) {
Bidi bi = new Bidi(defText,
   Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);

System.out.println(Runs: );
final int count = bi.getRunCount();
for (int i = 0; i  count; i++) {
System.out.println(i + :  + bi.getRunLevel(i)
   +  [ + bi.getRunStart(i)
   + ,  + bi.getRunLimit(i)
   + ]);
}
}
}


Thank you in advance.
--
Alexey A. Ivanov
Intel Middleware Product Division


P.S. Shall I add compatibility to the subject line?



  

-Original Message-
From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 01, 2006 3:27 PM
To: harmony-dev@incubator.apache.org
Subject: [classlib][text] Bidi returns directional runs in visual


order
  

rather than in logical

Hi all.

Harmony implementation of java.text.Bidi returns directional runs
(getRunStart(), getRunLimit(), getRunLevel()) in visual order if
paragraph reading order is Right-to-Left. I mean the first run is at



the

  

end of character buffer, and the last is at the beginning. I'd


expect
  

directional runs are enumerated in the order of the characters in


the
  

buffer, i.e. the logical order.

I've created a JIRA issue for this:
https://issues.apache.org/jira/browse/HARMONY-1028

Another difference from the RI is that in Harmony the text is


divided
  

into paragraphs before directional analysis, which is not done in


the
  

RI

  

despite the Unicode Bidirectional Algorithm [1] requires it.


The output of the test case when run on Harmony:
0: 0 [0, 3]
1: 1 [7, 9]
2: 2 [5, 7]
3: 1 [3, 5]

However, I'd expect the following output:
0: 0 [0, 3]
1: 1 [3, 5]
2: 2 [5, 7]
3: 1 [7, 9]

The output of the test case when run on the RI:
0: 0 [0, 3]
1: 1 [3, 5]
2: 0 [5, 7]
3: 1 [7, 9]


Any thoughts?

[1] http://www.unicode.org/reports/tr9/


Regards,
--
Alexey A. Ivanov
Intel Middleware Product Division




-
  

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:


[EMAIL PROTECTED]
  

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
  

[EMAIL PROTECTED]
  


  

--
Richard Liang
China Software Development Lab, IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  


--
Richard Liang
China Software Development Lab, IBM

Re: [classlib][security] SecurityManager.checkPropertyAccess(String) bug?


No

The reason is these lines behave differently

import java.security.*;
import java.util.*;
public class a {
   static public void main(String[] args) throws Exception {
   Permission p = new PropertyPermission(java.version, read);
   ProtectionDomain d = a.class.getProtectionDomain();
   System.out.println( ==  + d.implies(p));
   }
}

2006/8/22, Paulex Yang [EMAIL PROTECTED]:

Andrew Zhang wrote:
 Hi all,

 I noticed that Harmony security manager throws unexpected security
 exception
 even when policy file allows the permission. I have raised HARMONY-1242(
 http://issues.apache.org/jira/browse/HARMONY-1242) for record.  Would
 anybody help have a look? Thanks!

Seems SecurityManager pass correct permission instance to
AccessController, should it be AccessController's issue?


 On 8/21/06, Andrew Zhang (JIRA) [EMAIL PROTECTED] wrote:

 [classlib][security] SecurityManager.checkPropertyAccess(java.version)
 throws unexpected exception.

 
--


 Key: HARMONY-1242
 URL: http://issues.apache.org/jira/browse/HARMONY-1242
 Project: Harmony
  Issue Type: Bug
  Components: Classlib
Reporter: Andrew Zhang


 Following test reproduces the bug:

 public void test_checkPropertyAccess() throws Exception {
  SecurityManager manager = new SecurityManager();
  manager.checkPropertyAccess(java.version);
}

 The test passes against RI while fails against Harmony.
 I have checked  java.policy security file, which also allows
 permission
 java.util.PropertyPermission java.version,read; by default.

 Would any security guys help investigate this issue? Thanks a lot!

 Best regards,
 Andrew


 --
 This message is automatically generated by JIRA.
 -
 If you think it was sent incorrectly contact one of the administrators:
 http://issues.apache.org/jira/secure/Administrators.jspa
 -
 For more information on JIRA, see:
 http://www.atlassian.com/software/jira







--
Paulex Yang
China Software Development Lab
IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[classlib][compatiblity](Re: [jira] Created: (HARMONY-1241) [classlib][util] unexpected IllegalArgumentException for java.util.SimpleTimeZone(13 params))


Seems both Harmony and RI's behavior violates spec, which says:

The mode specifies either wall_time or standard_time or UTC_time. and 
|IAE cid:part1.04040504.00010409@gmail.com| - if the month, day, 
dayOfWeek, time more, or time parameters are out of range for the start 
or end rule, or if a time mode value is invalid.


IIUC, it means only the three constants wall_time(0), standard_time(1) 
and UTC_time(2) are valid values for startTimeMode/endTimeMode, but 
interesting facts are: RI accepts any values from Integer.MIN_VALUE to 
MAX_VALUE, while Harmony accepts 1-4 and throws exception for others. 
Further, seems RI doesn't validate some other parameters as spec,too 
(startDayOfWeek or so).


I suggest to follow RI in this case, but like to listen to others.



Vladimir Ivanov (JIRA) wrote:

[classlib][util] unexpected IllegalArgumentException for 
java.util.SimpleTimeZone(13 params)


 Key: HARMONY-1241
 URL: http://issues.apache.org/jira/browse/HARMONY-1241
 Project: Harmony
  Issue Type: Bug
  Components: Classlib
Reporter: Vladimir Ivanov


The method java.util.SimpleTimeZone.SimpleTimeZone(int rawOffset, String ID, 
int startMonth, int startDay, int startDayOfWeek, int startTime, int 
startTimeMode, int endMonth, int endDay, int endDayOfWeek, int endTime, int 
endTimeMode, int dstSavings) for correct parameters throws 
IllegalArgumentException on Harmony.

=== test.java =
import java.util.SimpleTimeZone;
import java.util.TimeZone;
import java.util.Calendar;

public class test {
public static void main(String args[]) {
System.out.println(DST_OFFSET =  + Calendar.DST_OFFSET);
System.out.println(res =  +  new SimpleTimeZone(
  TimeZone.LONG,
  Europe/Paris,
  SimpleTimeZone.STANDARD_TIME,
  SimpleTimeZone.STANDARD_TIME,
  SimpleTimeZone.UTC_TIME,
  SimpleTimeZone.WALL_TIME,
  SimpleTimeZone.WALL_TIME,
  TimeZone.SHORT,
  SimpleTimeZone.STANDARD_TIME,
  TimeZone.LONG,
  SimpleTimeZone.UTC_TIME,
  SimpleTimeZone.STANDARD_TIME,
  TimeZone.LONG));
}
}
===

Output:
C:\tmp\tmp17C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -cp . -showversion 
test
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32, R25.0.0-75, 
GC: System optimized over throughput (initial strategy singleparpar))

DST_OFFSET = 16
res = 
java.util.SimpleTimeZone[id=Europe/Paris,offset=1,dstSavings=1,useDaylight=true,startYear=0,startMode=2,startMonth=1,startDay=1,startDayOfWeek=2
,startTime=0,startTimeMode=0,endMode=2,endMonth=0,endDay=1,endDayOfWeek=1,endTime=2,endTimeMode=1]

C:\tmp\tmp17C:\harmony\classlib1.5\deploy\jdk\jre\bin\java.exe -cp . 
-showversion test
java version 1.5 (subset)

(c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as 
applicable.
DST_OFFSET = 16
Exception in thread main java.lang.IllegalArgumentException: DST offset: 0
at java.util.SimpleTimeZone.init(SimpleTimeZone.java:216)
at test.main(test.java:8)



  



--
Paulex Yang
China Software Development Lab
IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][compatiblity](Re: [jira] Created: (HARMONY-1241) [classlib][util] unexpected IllegalArgumentException for java.util.SimpleTimeZone(13 params))

2006-08-21 Thread Richard Liang




Paulex Yang wrote:

Seems both Harmony and RI's behavior violates spec, which says:

The mode specifies either wall_time or standard_time or UTC_time. 
and |IAE cid:part1.04040504.00010409@gmail.com| - if the month, 
day, dayOfWeek, time more, or time parameters are out of range for the 
start or end rule, or if a time mode value is invalid.


IIUC, it means only the three constants wall_time(0), standard_time(1) 
and UTC_time(2) are valid values for startTimeMode/endTimeMode, but 
interesting facts are: RI accepts any values from Integer.MIN_VALUE to 
MAX_VALUE, while Harmony accepts 1-4 and throws exception for others. 
Further, seems RI doesn't validate some other parameters as spec,too 
(startDayOfWeek or so).


I suggest to follow RI in this case, but like to listen to others.


+1 to follow RI.



Vladimir Ivanov (JIRA) wrote:
[classlib][util] unexpected IllegalArgumentException for 
java.util.SimpleTimeZone(13 params)
 



 Key: HARMONY-1241
 URL: http://issues.apache.org/jira/browse/HARMONY-1241
 Project: Harmony
  Issue Type: Bug
  Components: Classlib
Reporter: Vladimir Ivanov


The method java.util.SimpleTimeZone.SimpleTimeZone(int rawOffset, 
String ID, int startMonth, int startDay, int startDayOfWeek, int 
startTime, int startTimeMode, int endMonth, int endDay, int 
endDayOfWeek, int endTime, int endTimeMode, int dstSavings) for 
correct parameters throws IllegalArgumentException on Harmony.


=== test.java =
import java.util.SimpleTimeZone;
import java.util.TimeZone;
import java.util.Calendar;

public class test {
public static void main(String args[]) {
System.out.println(DST_OFFSET =  + Calendar.DST_OFFSET);
System.out.println(res =  +  new SimpleTimeZone(
  TimeZone.LONG,
  Europe/Paris,
  SimpleTimeZone.STANDARD_TIME,
  SimpleTimeZone.STANDARD_TIME,
  SimpleTimeZone.UTC_TIME,
  SimpleTimeZone.WALL_TIME,
  SimpleTimeZone.WALL_TIME,
  TimeZone.SHORT,
  SimpleTimeZone.STANDARD_TIME,
  TimeZone.LONG,
  SimpleTimeZone.UTC_TIME,
  SimpleTimeZone.STANDARD_TIME,
  TimeZone.LONG));
}
}
===

Output:
C:\tmp\tmp17C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -cp . 
-showversion test

java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32, 
R25.0.0-75, GC: System optimized over throughput (initial strategy 
singleparpar))


DST_OFFSET = 16
res = 
java.util.SimpleTimeZone[id=Europe/Paris,offset=1,dstSavings=1,useDaylight=true,startYear=0,startMode=2,startMonth=1,startDay=1,startDayOfWeek=2 

,startTime=0,startTimeMode=0,endMode=2,endMonth=0,endDay=1,endDayOfWeek=1,endTime=2,endTimeMode=1] 



C:\tmp\tmp17C:\harmony\classlib1.5\deploy\jdk\jre\bin\java.exe -cp . 
-showversion test

java version 1.5 (subset)

(c) Copyright 1991, 2006 The Apache Software Foundation or its 
licensors, as applicable.

DST_OFFSET = 16
Exception in thread main java.lang.IllegalArgumentException: DST 
offset: 0

at java.util.SimpleTimeZone.init(SimpleTimeZone.java:216)
at test.main(test.java:8)



  





--
Richard Liang
China Software Development Lab, IBM 




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][security] SecurityManager.checkPropertyAccess(String) bug?