Re: [vote] Graduate Apache Harmony podling from the Incubator

[Pavel Rebriy]

+1

This is a great news!

On 21/10/06, Weldon Washburn [EMAIL PROTECTED] wrote:


+1



On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

 We're trying something a little different.  I think Roy Fielding one
 said something along the lines of when a community gets organized
 enough to vote itself out of the Incubator, it's appropriate.

 So to bring the Harmony community and the Incubator community together
 for this important event in Harmony's life, I'm calling for a vote on
 graduating Harmony here on our own -dev list.  The objective is for all
 in both the Harmony community and the Incubator community that have an
 opinion to vote together, in the same place, and have it hosted by the
 Harmony podling.

 This is an unconventional way to do this, but I think that it's valid
 and could provide one example to the Incubator on how it can work going
 forward.

 So, without any further ado :

 [ ] +1 Graduate Apache Harmony from incubation, and let it petition the
 board for Top Level Project status

 [ ] 0 No opinion

 [ ] -1 No, don't graduate Harmony.  Here's why :


 This vote will end 72 hours from now + time of Apache mail outage.  It
 will therefore end on Monday, October 23, at 3:30 PM eastern, + delta
 for mail outage.

 Thanks

 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





--
Best regards,
Pavel Rebriy

RE: [vote] Graduate Apache Harmony podling from the Incubator

[Ivanov, Alexey A]

+1 

--
Alexey A. Ivanov
Intel Middleware Product Division

-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Friday, October 20, 2006 11:30 PM
To: harmony-dev@incubator.apache.org
Subject: [vote] Graduate Apache Harmony podling from the Incubator

We're trying something a little different.  I think Roy Fielding one
said something along the lines of when a community gets organized
enough to vote itself out of the Incubator, it's appropriate.

So to bring the Harmony community and the Incubator community together
for this important event in Harmony's life, I'm calling for a vote on
graduating Harmony here on our own -dev list.  The objective is for all
in both the Harmony community and the Incubator community that have an
opinion to vote together, in the same place, and have it hosted by
the
Harmony podling.

This is an unconventional way to do this, but I think that it's valid
and could provide one example to the Incubator on how it can work going
forward.

So, without any further ado :

[ ] +1 Graduate Apache Harmony from incubation, and let it petition the
board for Top Level Project status

[ ] 0 No opinion

[ ] -1 No, don't graduate Harmony.  Here's why :


This vote will end 72 hours from now + time of Apache mail outage.  It
will therefore end on Monday, October 23, at 3:30 PM eastern, + delta
for mail outage.

Thanks

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: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

[Pavel Afremov]

Hi

I've developed two "impossible tests, which shows "fake" circularity errors. One test is more simple and use SecurityManager. The other is a bit more complex and usescustom ClassLoader. You can findthem in attachment.


Thanks.
Pavel Afremov
On 10/17/06, Pavel Pervov [EMAIL PROTECTED] wrote:
The scenario I described earlier is impossible. Resolution of any classreferenced in some other class is performed by class loader, which loaded
that other class. So, no chance to load A and referencing class loader(UCL) with this UCL.Sorry for confusion.Regards, Pavel.P.S. Still there are concerns why lazy resolution should be supported by
JITs. But it is absolutely another story.On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote: IMO we shall be between BEA and SUN: to work if both RI work, to fail if
 both RI fail and discuss each test in details if only one RI passes. On 10/17/06, Gregory Shimansky [EMAIL PROTECTED] wrote:   On Friday 13 October 2006 08:04 Alexey Varlamov wrote:
   I'm curious, if we enable controlled recursion in classloading -   will it resolve this kind of issues completely? I'm pretty sure it   would resolve at least some scenarios - like the one Pavel described
   for gc.Finalizers or a case of classloading initiated within   SecurityManager.checkPermission() which we also faced not once.   Controlled recursion here means counting depth of recursion and
   allowing at least 1 recursive iteration. I've seen some tricks in   URLClassLoader which assume such ability, but they do not work with   DRLVM.   I think it is different. URLClassLoader is system class which is loaded
 by  bootstrap, so no recursion happens for classes which it itself requires to  be  loaded when it is being compiled.For the pure user code scenario Pavel suggested above, there may be
   some nuances leading to truly endless recursion, but still we need to   look at particular test first.   It is not endless but it is definitely more than 1 level deep. If user
  sets up  his own class loaders, compiling them may trigger loading some of the user  classes which are in turn loaded by class loaders set up by user. Shall we  then throw NoClassDefFoundError: Class loading recursion limit reached.
  Please rewrite your code? :)   --  Gregory Shimansky, 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: [vote] Graduate Apache Harmony podling from the Incubator

[bootjvm]

+1

Dan Lydick


 [Original Message]
 From: Geir Magnusson Jr. [EMAIL PROTECTED]
 To: harmony-dev@incubator.apache.org
 Date: 10/20/06 2:30:42 PM
 Subject: [vote] Graduate Apache Harmony podling from the Incubator

 We're trying something a little different.  I think Roy Fielding one 
 said something along the lines of when a community gets organized 
 enough to vote itself out of the Incubator, it's appropriate.

 So to bring the Harmony community and the Incubator community together 
 for this important event in Harmony's life, I'm calling for a vote on 
 graduating Harmony here on our own -dev list.  The objective is for all 
 in both the Harmony community and the Incubator community that have an 
 opinion to vote together, in the same place, and have it hosted by the 
 Harmony podling.

 This is an unconventional way to do this, but I think that it's valid 
 and could provide one example to the Incubator on how it can work going 
 forward.

 So, without any further ado :

 [ ] +1 Graduate Apache Harmony from incubation, and let it petition the 
 board for Top Level Project status

 [ ] 0 No opinion

 [ ] -1 No, don't graduate Harmony.  Here's why :


 This vote will end 72 hours from now + time of Apache mail outage.  It 
 will therefore end on Monday, October 23, at 3:30 PM eastern, + delta 
 for mail outage.

 Thanks

 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: [drlvm] A list of drlvm enhancements and limitations

[Weldon Washburn]

All,
Just a few minutes ago I sent a mail titled, [DRLVM][MMTk] current status
and plan.  It is way too long and detailed to include in this list of drlvm
enhancements.  Below is a summary that hopefully is at the appropriate level
of detail.  Please refer to the above email for more information.

Summary of MMTk projects
1)
Move the exiting uswer-level MMTk port to GCV5
2)
Get MMTk SemiSpace, GenMS and CopyMS collector running again.  They were
broken during migration to latest MMTk source and latest drlvm svn HEAD.
3)
Alter DRLVM classloader to force all MMTk classes to be loaded and all
methods to be JITed before any java code is executed.  Integrate MMTk into
an early stage of DRLVM boot.
4)
Fix up MMTk/VM porting layer which is located at:
drlvm/trunk/vm/MMTki/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk
5)
Debug and verify JIT support for MMTk's Uninterruptible class.  Run simple
multithread app and debug.


On 10/17/06, Rana Dasgupta [EMAIL PROTECTED] wrote:


Hi Gregory,
   It is a good idea to put up a live list, thanks. Here are some
suggestions on the contents for development items in the VM/JIT. A few may
be almost done. We can fine tune...and add other work items as well


- MMTk integration:
Support for magic classes in Jitrino
VM/JIT support for MMTk collectors including RSE and thread suspension

( Weldon, could you please add details?)

Thanks
















 On 10/16/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
 
  Once it's more or less ready let's point to that page from TODO on our
  website
 
  Thanks,
  Mikhail
 
  2006/10/17, Gregory Shimansky [EMAIL PROTECTED]:
   Hello
  
   You know that drlvm was donated by Intel and there was some period
of
  time
   while drlvm was developed internally. We had an internal bugzilla
  server to
   track the issues. In an effort to move all development to the open
  this
   internal bugzilla will be closed.
  
   The database is quite big and contains a lot of valuable information
  including
   still open bugs. There are many of them which are not exactly bug
  reports,
   but requests for enhancements or limitation problems. These small
  issues
   didn't make it to README because they are mostly minor and low
  priority, but
   it is better to use information which we have already than
rediscover
  these
   problems again.
  
   So not to create a lot of garbage in JIRA like problem requests
  without
   patches I think it is better to create something like a TODO list
for
  drlvm.
   Not exactly bugs, but more like known limitations list.
  
   To give you an example, vm/vmcore/src/init/properties.cpp contains a
  #define
   MAX_PROP_LINE 5120 which is a maximum property length specified in
   vm.properties file. I am not even sure if this file still used,
  probably not,
   but a buffer length limitation is still a bad thing.
  
   I think a good place for such list would be on wiki. I am going to
  create a
   page for it so that everyone who has open bugs inside of Intel could
  add a
   line or two describing a problem recorded in bugzilla. I have 3 like
  these
   filed myself including the one I gave as an example.
  
   I don't know the number of such bugs overall, maybe it is not so
big.
  But
   before creating JIRAs for them I think it is better to collect a
list
  on
   wiki. What do you think?
  
   --
   Gregory Shimansky, Intel Middleware Products Division
  
 






--
Weldon Washburn
Intel Middleware Products Division

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Sergey Soldatov]

+1

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Richard Liang]

+ 1.  ;-)

Best regards,
Richard

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

We're trying something a little different.  I think Roy Fielding one
said something along the lines of when a community gets organized
enough to vote itself out of the Incubator, it's appropriate.

So to bring the Harmony community and the Incubator community together
for this important event in Harmony's life, I'm calling for a vote on
graduating Harmony here on our own -dev list.  The objective is for all
in both the Harmony community and the Incubator community that have an
opinion to vote together, in the same place, and have it hosted by the
Harmony podling.

This is an unconventional way to do this, but I think that it's valid
and could provide one example to the Incubator on how it can work going
forward.

So, without any further ado :

[ ] +1 Graduate Apache Harmony from incubation, and let it petition the
board for Top Level Project status

[ ] 0 No opinion

[ ] -1 No, don't graduate Harmony.  Here's why :


This vote will end 72 hours from now + time of Apache mail outage.  It
will therefore end on Monday, October 23, at 3:30 PM eastern, + delta
for mail outage.

Thanks

geir


-
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 Development Lab, IBM

[drlvm][jit] Seems like too many classes loaded

[Armand Navabi]

I am trying to become more familiar with the jit code.  I ran the
following to see what all was compiled when running Hello World.
java -Xtrace:compile Hello.  I was very surprised to see the number of
methods that seem to be loaded.  I think there are about 1079 methods
that get compiled for Hello World.

Does harmony just load all the classes in the classlib and compile every
method?  If not, then why would there be so many methods compiled for a
simple hello world program?

Right now I am trying to write a simple profiling tool that counts the
number of certain instructions in a program for a given input (i.e. I
want to run the program, and for every instruction that ends up running,
collect information).  So, since it seems that the jit not only compiles
every instruction in the program (not only the ones that end up
running), but also a bunch of other classes, I thought perhaps I would
be more interested in the interpreter.

Running java -Xint -Xtrace:interpreter Hello then also gave me way
more output then I expected.  For example

...
interpreter: java/lang/String indexOf(II)I
interpreter: java/lang/String startsWith(Ljava/lang/String;)Z
interpreter: java/lang/String startsWith(Ljava/lang/String;I)Z
interpreter: java/lang/String regionMatches(ILjava/lang/String;II)Z
interpreter: java/net/URI
access$1002(Ljava/net/URI;Ljava/lang/String;)Ljava/lang/String;
interpreter: java/net/URI access$1000(Ljava/net/URI;)Ljava/lang/String;
interpreter: java/net/URI$Helper
validatePath(Ljava/lang/String;Ljava/lang/String;I)V
interpreter: java/net/URIEncoderDecoder
validate(Ljava/lang/String;Ljava/lang/String;)V
interpreter: java/lang/String length()I
interpreter: java/lang/String charAt(I)C
interpreter: java/lang/String indexOf(I)I
interpreter: java/lang/String indexOf(II)I
interpreter: java/lang/String length()I
...

I'm not sure why all of this is being interpreted for a simple hello
world program.  My understanding was that the interpreter traverses the
byte code for the given input and then handles the executed byte codes. 
It seems like a lot more is going on here.

Also, I am trying to become familiar with the jit and interpreter by
reading the DRL Developer's Guide.  Are there any other resources other
than the Developer's Guide and this mailing list?


Thanks
Armand

Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov

[Oleg Khaschansky]

Congratulations! Great news!

Sorry for being a bit outdated - I was on vacations last week.

On 10/18/06, Nathan Beyer [EMAIL PROTECTED] wrote:

Congratulations to all the new committers.

-N

On 10/16/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
 Please join the Apache Harmony PPMC in welcoming the project's newest
 committers, in alphabetical order  :

 Oliver Deakin
 Richard Liang
 Alexey Petrenko
 Gregory Shimansky
 Alexey Varlamov
 Alexei Zakharov

 These six individuals have shown sustained dedication to the project, an
 ability to work well with others, and share the common vision we have
 for Harmony. We all continue to expect great things from them.

 Gentlemen, you don't have accounts yet.  When you finally receive your
 new committer account information, as a first step to test your almighty
 powers of committitude, please update the committers page on the
 website.  That should be a good  (and harmless) exercise to test if
 everything is working.

 Things to do :

 1) test ssh-ing to the server people.apache.org.
 2) Change your login password on the machine
 3) Add a public key to .ssh so you can stop using the password
 4) Set your SVN password  : just type 'svnpasswd'

 At this point, you should be good to go.  Checkout the website from svn
 and update it.  See if you can figure out how.

 Also, anything checked out of SVN, be sure that you have checked out via
 'https' and not 'http' or you can't check in. You can switch using svn
 switch. (See the manual)

 Finally, although you now have the ability to commit, please remember :

 1) continue being as transparent and communicative as possible.  You
 earned committer status in part because of your engagement with others.
  While it was a  have to situation because you had to submit patches
 and defend them, but we believe it is a want to.  Community is the key
 to any Apache project.

 2)We don't want anyone going off and doing lots of work locally, and
 then committing.  Committing is like voting in Chicago - do it early and
 often.  Of course, you don't want to break the build, but keep the
 commit bombs to an absolute minimum, and warn the community if you are
 going to do it - we may suggest it goes into a branch at first.  Use
 branches if you need to.

 3) Always remember that you can **never** commit code that comes from
 someone else, even a co-worker.  All code from someone else must be
 submitted by the copyright holder (either the author or author's
 employer, depending) as a JIRA, and then follow up with the required
 ACQs and BCC.

 Again, thanks for your hard work so far, and welcome.

 The Apache Harmony PPMC



 -
 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] Graduate Apache Harmony podling from the Incubator

[Morozova, Nadezhda]

+1

Thank you, 
Nadya Morozova
 
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 20, 2006 11:30 PM
To: harmony-dev@incubator.apache.org
Subject: [vote] Graduate Apache Harmony podling from the Incubator

We're trying something a little different.  I think Roy Fielding one 
said something along the lines of when a community gets organized 
enough to vote itself out of the Incubator, it's appropriate.

So to bring the Harmony community and the Incubator community together 
for this important event in Harmony's life, I'm calling for a vote on 
graduating Harmony here on our own -dev list.  The objective is for all 
in both the Harmony community and the Incubator community that have an 
opinion to vote together, in the same place, and have it hosted by the

Harmony podling.

This is an unconventional way to do this, but I think that it's valid 
and could provide one example to the Incubator on how it can work going 
forward.

So, without any further ado :

[ ] +1 Graduate Apache Harmony from incubation, and let it petition the 
board for Top Level Project status

[ ] 0 No opinion

[ ] -1 No, don't graduate Harmony.  Here's why :


This vote will end 72 hours from now + time of Apache mail outage.  It 
will therefore end on Monday, October 23, at 3:30 PM eastern, + delta 
for mail outage.

Thanks

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: [vote] Graduate Apache Harmony podling from the Incubator

[robert burrell donkin]

On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


[X] +1 Graduate Apache Harmony from incubation, and let it petition the
board for Top Level Project status


the community still has things to learn about the release process (see
http://mail-archives.apache.org/mod_mbox/incubator-general/200610.mbox/[EMAIL 
PROTECTED],
for example) but IMHO the community should prove strong enough to face
successfully these challenges.

(and - with a little bit of luck - the documentation and tools
available should be a little better by then...)

- robert

RE: RE: Thoughtless fixes considered harmful Was: [OT] Automated fixes considered harmful

[Ivanov, Alexey A]

-Original Message-
From: Alex Blewitt [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 21, 2006 3:32 AM
To: harmony-dev@incubator.apache.org
Subject: Re: RE: Thoughtless fixes considered harmful Was: [OT]
Automated
fixes considered harmful

On 21/10/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote:
 Alex,
 I see and accept your point. I believe that partial commits are a
must -
 we should be a community.

 My point is simple - the code under active development shouldn't be a
 subject of beautification - it just should be safe for other Harmony
 modules. The first goal is to make it work.

Completely agree. Code which is fluctuating under development
shouldn't cause a concern that it's generating warnings for this kind
of thing.

Once the code matures, and is fully implemented and tested, *then*
that's the time to start the beautification process :-)


I agree with this too. No beautification should be performed on code
which is actively being developed. I think everybody understands it
clearly.

But once the code is quite stable and only bug fixes are applied to it,
I see no harm from deleting unused local variables and imports. Removing
unreferenced private fields and methods can be dangerous. Nevertheless
I'd vote for removing ones as well. It makes code more concise leaving
no legacy.


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

Harmony passes 94% on derby tests.

[Leo Li]

467 Tests Run
94% Pass (443 tests passed)
6% Fail (24 tests failed)
5 Suites skipped

The main progress focuses here:
1. Harmony classlib fails to load class when user-defined security policy
exists. It is due to the sequence of library loading of VM, which has been
resolved now.
2. A new workround for derby tests which allow useprocess to run test or
else several testcases might fail due to derby lack these tests when
useprocess = false.
3. Derby source code uses the version and the name of java vm to decide what
to do, while current IBM VM has the version of 1.4.2 and the name of j9,
which has different output on the screen from that of standard RI 1.5. At
the same time Derby test compares the output of the iteractive test scripts
to that of expected. I have made some slight modification in its source
code, but I have not throughly change this odd behavior, ...,too much:(

Besides, some testcase fails even on RI. I exclude
a derbynetclientmats test suit since it will hang both RI and Harmony.
Currently all the failure is irrelevant to Harmony. Hope I can find
something in the left.

I have updated the wiki of derby on Hamony:
http://wiki.apache.org/harmony/Apache_Derby.

--
Leo Li
China Software Development Lab, IBM

Re: svn commit: r466154 - in /incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent: ./ locks/

[Nathan Beyer]

This can be controlled a bit more. An svn:externals link can point to
a specific revision, not just a SVN URL. This way the working copy
download has to be changed at the point of link.

-Nathan

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

Great - I wanted to make sure.  I was asking based on a cursory glance.

geir


Nathan Beyer wrote:
 They are in 'standard' and do use 'links' (svn:externals). Check out
 the full path of the original commit message. Using svn:externals just
 makes it seem like it's in 'extended', but that's just in your working
 copy.

 -Nathan

 On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 Thanks for bringing this up. I did a classlib update this morning, and
 saw these files change, and I was confused.

 Why do we have the files here anyway?  I thought we were going to keep
 in /standard and use links?

 geir

 Tim Ellison wrote:
  Mark,
 
  I suggest that this is rolled back since it is modifying the
 concurrency
  code in our 'standard' SVN area that we aim to keep in close sync with
  Doug's repository.
 
  Perhaps we can offer the patch to that community, and/or set up local
  compiler options to hide the warnings in this module.
 
  Regards,
  Tim
 
  [EMAIL PROTECTED] wrote:
  Author: hindessm
  Date: Fri Oct 20 08:47:50 2006
  New Revision: 466154
 
  URL: http://svn.apache.org/viewvc?view=revrev=466154
  Log:
  Applied two patches from [#HARMONY-1926] [build] A lot of never
 used
  and never read warning messages.
 
  Modified:
 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ArrayBlockingQueue.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ConcurrentHashMap.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/CountDownLatch.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/DelayQueue.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/Delayed.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ExecutorService.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/Executors.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/FutureTask.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ScheduledExecutorService.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/Semaphore.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/SynchronousQueue.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/AbstractQueuedSynchronizer.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/LockSupport.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/ReentrantLock.java

 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/ReentrantReadWriteLock.java

 
 
 

 -
 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] Graduate Apache Harmony podling from the Incubator

[Vladimir Ivanov]

+1



On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

 We're trying something a little different.  I think Roy Fielding one
 said something along the lines of when a community gets organized
 enough to vote itself out of the Incubator, it's appropriate.

 So to bring the Harmony community and the Incubator community together
 for this important event in Harmony's life, I'm calling for a vote on
 graduating Harmony here on our own -dev list.  The objective is for all
 in both the Harmony community and the Incubator community that have an
 opinion to vote together, in the same place, and have it hosted by the
 Harmony podling.

 This is an unconventional way to do this, but I think that it's valid
 and could provide one example to the Incubator on how it can work going
 forward.

 So, without any further ado :

 [ ] +1 Graduate Apache Harmony from incubation, and let it petition the
 board for Top Level Project status

 [ ] 0 No opinion

 [ ] -1 No, don't graduate Harmony.  Here's why :


 This vote will end 72 hours from now + time of Apache mail outage.  It
 will therefore end on Monday, October 23, at 3:30 PM eastern, + delta
 for mail outage.

 Thanks

 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

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Tony Wu]

+1

On 10/22/06, Weldon Washburn [EMAIL PROTECTED] wrote:

+1



On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

 We're trying something a little different.  I think Roy Fielding one
 said something along the lines of when a community gets organized
 enough to vote itself out of the Incubator, it's appropriate.

 So to bring the Harmony community and the Incubator community together
 for this important event in Harmony's life, I'm calling for a vote on
 graduating Harmony here on our own -dev list.  The objective is for all
 in both the Harmony community and the Incubator community that have an
 opinion to vote together, in the same place, and have it hosted by the
 Harmony podling.

 This is an unconventional way to do this, but I think that it's valid
 and could provide one example to the Incubator on how it can work going
 forward.

 So, without any further ado :

 [ ] +1 Graduate Apache Harmony from incubation, and let it petition the
 board for Top Level Project status

 [ ] 0 No opinion

 [ ] -1 No, don't graduate Harmony.  Here's why :


 This vote will end 72 hours from now + time of Apache mail outage.  It
 will therefore end on Monday, October 23, at 3:30 PM eastern, + delta
 for mail outage.

 Thanks

 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





--
Tony Wu
China Software Development Lab, IBM

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Sian January]

+1

On 21/10/06, Weldon Washburn [EMAIL PROTECTED] wrote:


+1



On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

 We're trying something a little different.  I think Roy Fielding one
 said something along the lines of when a community gets organized
 enough to vote itself out of the Incubator, it's appropriate.

 So to bring the Harmony community and the Incubator community together
 for this important event in Harmony's life, I'm calling for a vote on
 graduating Harmony here on our own -dev list.  The objective is for all
 in both the Harmony community and the Incubator community that have an
 opinion to vote together, in the same place, and have it hosted by the
 Harmony podling.

 This is an unconventional way to do this, but I think that it's valid
 and could provide one example to the Incubator on how it can work going
 forward.

 So, without any further ado :

 [ ] +1 Graduate Apache Harmony from incubation, and let it petition the
 board for Top Level Project status

 [ ] 0 No opinion

 [ ] -1 No, don't graduate Harmony.  Here's why :


 This vote will end 72 hours from now + time of Apache mail outage.  It
 will therefore end on Monday, October 23, at 3:30 PM eastern, + delta
 for mail outage.

 Thanks

 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





--
Sian January

IBM Java Technology Centre, UK

Re: [build] ant help needed

[Matt Benson]

Actually it would be easy to inspect the unresolvable
reference name, and if it were in ${.*} format
(meaning it is an unexpanded property reference) issue
a warning... I'll think on that.  ;)

-Matt

--- Tim Ellison [EMAIL PROTECTED] wrote:

 On 20/10/06, Matt Benson [EMAIL PROTECTED]
 wrote:
  That's because you tried to use property expansion
  notation--${hy.required.metainf-files}--for a
  reference.  Try
 
  metainf refid=hy.required.metainf-files /
 
 When do we get support for the option?
ant --do-what-I-mean-not-what-I-say  :-)
 
 Thanks, will try again when my machine is
 serviceable.
 
 Tim
 
 -- 
 
 Tim Ellison ([EMAIL PROTECTED])
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

RE: [jira] Commented: (HARMONY-632) Patch to provide parsing of file_bands at end of Pack200 file.

[Nathan Beyer]

Alex,
I believe only committers can close an issue. Once an issue is
resolved, I usually leave a comment and ask the reporter to verify it
and then when that happens I close it. It's not uncommon that
verification just gets missed, so I just come back and close anything
that has been resolved for a month or longer.

-Nathan

-- Forwarded message --
From: Alex Blewitt (JIRA) [EMAIL PROTECTED]
Date: Oct 21, 2006 5:12 AM
Subject: [jira] Commented: (HARMONY-632) Patch to provide parsing of
file_bands at end of Pack200 file.
To: [EMAIL PROTECTED]


   [ 
http://issues.apache.org/jira/browse/HARMONY-632?page=comments#action_12444028
]

Alex Blewitt commented on HARMONY-632:
--

Sorry, what's the correct protocol for these situations? Do I need to
comment that all is OK and then close it, or can you only close it?


Patch to provide parsing of file_bands at end of Pack200 file.
--

Key: HARMONY-632
URL: http://issues.apache.org/jira/browse/HARMONY-632
Project: Harmony
 Issue Type: Improvement
 Components: Classlib
   Reporter: Alex Blewitt
Assigned To: Nathan Beyer
   Priority: Trivial
Attachments: segment.patch


This patch provides the unpacking of the file_bands at the end of a Pack200 
archive. With this, the implementation is now capable of reading a non-GZipped 
pack200 archive and being able to correctly extract the file names and bytes. 
Currently, the parsing does no processing in terms of being able to 
reconstitute those into files.
Owing to a Java limitation in byte array initialisation, the maximum size of a 
file must be 2Gb in this current implementation.


--
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

Re: [classlib][luni] signalis interruptus in hysock

[Weldon Washburn]

It seems JIRA is down for maintenance.  If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) { select...}
loop. And after every N loops, print a warning/diagnostic message.   The
value for N would have to be tuned.  I don't know what the best number would
be. Given that 1904 patch is not the final solution, at least a diagnostic
that hints at where the system hangs would be useful.  It might make sense
to even print a stack trace.   Also, I agree with Ivan below.  Signals bugs
are very hard to debug.  And diagnostics can help us all understand the
corner cases better.

On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:


On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


 Ivan Volosyuk wrote:
  Well, I think that the solution is what Geir suggests. One think which
  bothers me is following. EINTR can happen in different places and the
  situations can be quite rare in some circumstances. It can lead to
  hard to reproduce stability bugs (race conditions).

 Can you give an example?

Half a year ago, I was working on the problem. Socket operations get
sometimes interrupted. We have found out that it occurs sometime after
GC. It was not quite easy as the application was quite big and
situation - quite rare.

Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have rock
solid support of EINTR handling everywhere the select(), poll() calls
is used.

--
Ivan
Intel Enterprise Solutions Software Division


  We should find a
  way how to test the implementation.

 +1!

 :)

 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

Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Nathan Beyer]

I haven't had a chance to look at the issue (JIRAs down right now,
probably part of the infrastructure move), but have you tried
comparing the actual class files of the problematic class or classes.

I'd suggest compiling the files using ECJ, save them off, compile with
Sun/BEA/etc, save them off and then run javap from a single JDK on
each of the class files and compare them for differences.

-Nathan

On 10/21/06, Elena Semukhina [EMAIL PROTECTED] wrote:

Hi all,

after classlib build system has switched to use ECJ, one test in swing
module started to fail on drlvm (win/linux). Actually the failure is not
related to swing functionality. I've filed JIRA issue
https://issues.apache.org/jira/browse/HARMONY-1931 and attached a simple
test to reproduce the failure.

All interested parties are welcome to look at this issue!

--
Thanks,
Elena

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Rui Hu]

+1 from me

let's make things better


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


We're trying something a little different.  I think Roy Fielding one
said something along the lines of when a community gets organized
enough to vote itself out of the Incubator, it's appropriate.

So to bring the Harmony community and the Incubator community together
for this important event in Harmony's life, I'm calling for a vote on
graduating Harmony here on our own -dev list.  The objective is for all
in both the Harmony community and the Incubator community that have an
opinion to vote together, in the same place, and have it hosted by the
Harmony podling.

This is an unconventional way to do this, but I think that it's valid
and could provide one example to the Incubator on how it can work going
forward.

So, without any further ado :

[ ] +1 Graduate Apache Harmony from incubation, and let it petition the
board for Top Level Project status

[ ] 0 No opinion

[ ] -1 No, don't graduate Harmony.  Here's why :


This vote will end 72 hours from now + time of Apache mail outage.  It
will therefore end on Monday, October 23, at 3:30 PM eastern, + delta
for mail outage.

Thanks

geir


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





--
Robert Hu
China Software Development Lab, IBM

Re: [drlvm] Calling native methods from Java code: implementation details

[Pavel Afremov]

Hi.



On First question I think that alternative 1 is better. It's allow to avoid
creating of special or magic registration subsystem which  should
provide addresses for magic native call.



On the Second question I agree with Pavel P. Null should be OK.



On Third question, I think no additional actions is required. All dll's or
so's for  DRL VM must be in jre/bin  directory and classes jar's must be
jre/lib directory. Both should be loaded by as the others in these
directories now. It's the first part of  third question. The second part
or fourth question is How to understand that this class contains magic
native functions?. I prefer answer by extends a special empty interface.
It's can provide opportunity  writing libraries with fast native calls in
future. Also it's match with java security. DRL VM can control what
component can use Magic and what not via SecurityManager.



Mikhail could you summarize all issues which should be clarified and
possible solutions for these issues?



Thanks.

Pavel Afremov.


On 10/20/06, Pavel Pervov [EMAIL PROTECTED] wrote:


Prerequisite: each component carries its own helpers (which means no
allocation helper in VM Core, for example).

Yes, simple JIT will call helper as regular JNI method.

I missed several issues in my original message.

First: how to get address of helper?
Answer:
Two choices:
1) each component must provide static native long getHelperAddress(int)
in
its helper class. JIT will make a call to this function as regular JNICALL
(stdcall on Windows, cdecl on Linux). Function prototype can be typedef'ed
as typedef (JNICALL*)(JNIEnv*, jint). The issue I see here is naming:
each
component has its own helpers class name. So, the name for native method
to
call will be package name_class name_getHelperAddress.
2) add regular (OPEN) interface function to each component which will
provide such mapping (as it is now done by VM).

Second: what should be passed as JNIEnv to getHelperAddress?
Answer:
NULL. Component should not use JNIEnv pointer in this call.

Third: how to retrieve helpers class for a particular component?
Answer:
Two choices again:
1) component modifies boot class path on initialization and exports
component type.helpers_class system property. Then VM loads this class
and
JIT uses this class' name to retrieve fast path helpers.
2) component exports component type.helpers_jar system property on
initialization, then VM adds this JAR to boot class path, extracts the
manifest from it, retrieve Helpers-Class attribute from the manifest, and
exports it as component type.helpers_class. Then VM loads this class and
JIT uses this class' name to retrieve fast path helpers.
I, personally, prefer second choice here.

Anything else?..

Pavel.

On 10/20/06, Alex Astapchuk [EMAIL PROTECTED] wrote:

 Pavel Pervov :
  My alternative follows:
 
  1) Each component which exports magics, provides JAR file with class
  implementing these magics. Class name is described in (e.g.)
Main-Class
  attribute of JAR's manifest.
  2) The class contains java fast path for helper, and a pair of native
  methods: one for fast-slow path, and one for slow-slow path.
  3) Fast-slow path helper can have any (supported) calling convention.


  4) Slow-slow path helper will be called through JNI - it is regular
 native
  method.
 ...
  way and generate call to slow_alloc in annotated calling convention.
 If JIT
  does not support magics at all, it'll call jni_alloc in usual way - as
  regular call to native Java method.


 Helpers are neither called as JNI methods nor they are called through
 the JNI.

 Or do you propose to make a code for the helpers as the JNI methods?
 How would the 'jni_alloc(Address class, int size);' look like in the C
 code?



 --
 Thanks,
   Alex



 
  The example follows:
  --
  package org.apache.harmony.vm.helpers;
  // Annotations follow here, which describe which method is which
helper,
  // and which is fast-path, fast-slow path, slow-slow path
  class GCv6Helpers {
 // fast-path allocation here
 public static Address alloc(Address class, int size) {
 // ...
 }
 // annotation, describing calling convention for fast-slow path
 public static native Address slow_alloc(Address class, int size);
 public static native Address jni_alloc(Address class, int size);
  }
 
  Now, if JIT supports magics, it'll process GCv6Magics::alloc in a
 special
  way and generate call to slow_alloc in annotated calling convention.
If
 JIT
  does not support magics at all, it'll call jni_alloc in usual way - as
  regular call to native Java method.
 
  Yes, my idea suggests to change helper retrieval interface for JIT,
but
 we
  already started to make significant changes to architecture - let's
just
  make them more generic.
 
  Regards,
 Pavel.
 
  P.S. IMHO, this approach combines strong sides of Mikhail's and
Pavel's
  ideas, as it use standard mechanisms of resolution and search of
methods
 in
  loaded classes.
 

Re: [classlib][test] Configuration dependent test of InetAddress.getHostName

[Alexei Zakharov]

I think Harmony does the right thing as spec requires, the difference is
caused by underlying system call, so it should be acceptable, i.e., the
test needs to be rewritten or excluded.


+1 from me

Thanks,

2006/10/20, Paulex Yang [EMAIL PROTECTED]:

Denis Kishenko wrote:
 I have researched issue H-1664 and found one more difference with RI.
 I run simple test on Windows Server 2003 SP1

 === Test =
 import java.net.InetAddress;
 import java.net.UnknownHostException;

 public class Test {
public static void main(String[] args) throws UnknownHostException {
System.out.println(by name (127.0.0.1) -  +
 InetAddress.getByName(127.0.0.1).getHostName());
System.out.println(by name (localhost) -  +
 InetAddress.getByName(localhost).getHostName());
System.out.println(by address -  +
 InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
System.out.println(localhost -  + InetAddress.getLocalHost());
}

 }

 Windows Server 2003 SP1
 === RI ==
by name (127.0.0.1) - 127.0.0.1
by name (localhost) - localhost
by address - 127.0.0.1
localhost - nstdrlew21/10.125.122.60

 = Harmony ==
by name (127.0.0.1) - nstdrlew21.ins.intel.com
by name (localhost) - localhost
by address - nstdrlew21.ins.intel.com
localhost - nstdrlew21/10.125.122.60

 WinXP
 = Both ===
 by name (127.0.0.1) - localhost
 by name (localhost) - localhost
 by address - localhost
 localhost - pbwdmkishen/10.125.132.226


 Actually Harmony use native call of getnameinfo() to get host name
 (which is reasonable IMHO). MSDN says The getnameinfo function
 provides name resolution from an address to the host name.

 InetAddressTest.test_getHostName (see H-1664) failed on WinServer
 because InetAddress.getByName(127.0.0.1).getHostName() returned
 nstdrlew21.ins.intel.com while localhost expected. So this test
 looks like configuration dependent.

 I see three possible options
 1. Stay test as is. Just keep in mind that on specific configurations
 this one fails.
 2. Rewrite test to be configuration dependent. Test has to do the same
 native call.
 3. Exclude localhost checking from test_getHostName.
I think Harmony does the right thing as spec requires, the difference is
caused by underlying system call, so it should be acceptable, i.e., the
test needs to be rewritten or excluded.  But this issue worth a non-bug
difference together with getHostName()'s different behavior when
SecurityManager presents[1](thanks Alexei Fedotov helped to find this
link and commented to HARMONY-1664:))

Harmony-73 is another issue, which is actually caused by HARMONY-84 and
irrelevant with getHostName() method.

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

 What do you think about this situation?


--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

[DRLVM][MMTk] current status and plan

[Weldon Washburn]

Current status

  - Robin Garner's mmtk_20061016.zip snapshot of MMTk source now runs
  the simple user-level MarkSweep.java test on DLRVM svn HEAD of
  10/20/2006.  The mods to MMTk porting layer to support the above have
  been committed to DRLVM HEAD. The next steps for the MMTk/DRLVM port are as
  follows.  Comments, suggestions are welcome.   It would be much
  appreciated if Steve Blackburn and Robin Garner would reply to the questions
  below directed to the MMTk guys.

The following plan is roughly in the order this work should be done.

  - Currentlly MMTk/DRLVM runs as a user-level app.  That is, MMTk
  port allocates a 450MB array from DRLVM's underlying GC.  Currently
  only GCV4.0 supports 450MB arrays.  A vmmagic Address object is
  created that points to the base of the 450MB array.  MMTk is booted
  with the Address of the 450MB object.  A simple MMTK exerciser was
  written in Java/vmmagic.  It calls MMTk alloc() repeatedly.  When MMTk
  runs out of memory, it will GC its user-level heap (the 450MB array).
  The underlying GCV4 is oblivious to what MMTK is doing with this 450MB
  array.
  - Project 1
 - Move the existing MMTk port to GCV5.  We need to remove the
 dependency on GCV4.
  - MMTk SemiSpace, GenMS and CopyMS collectors actually worked before
  upgrading to latest the MMTk sources and current DRLVM svn HEAD.
  - Project 2
 - Get SemiSpace, GenMS and CopyMS collectors working again.  Basically
 this means running TestSemiSpace.java, TestGenMS.java and
 TestCopyMS.java exerciser programs and debugging the problems.  Known
 issues that need fixing:
- Java write barrier in Jitrino.JET needs to be debugged
- MMTk needs the two LSBs of one of the object header
byte.  This was somehow broken during the commit of
BBC.patch. It needs to be fixed.  There is email on this
topic in harmony-dev.
 - To reduce confusion, all of MMTk java source code needs to be
  jitted before any MMTk methods are called.
  - Project 3
 - Modify DLRVM classloader to force all MMTk classes to be
 loaded and all methods JITed before any classlib java code is executed.
 - The next step is to integrate MMTk in the early DRLVM boot
 process.  The goal is to make sure all code the JIT generates
 will allocate out of the MMTk heap.  This is a chicken and egg
 kind of problem since no JITed code can execute until DRLVM has
a GC that is
 ready to support object allocation.  Most likely we will use the
 MMTk notion of ImmortalSpace for early object allocation.  Objects
 in ImmortalSpace are never collected, never moved.  At this
 stage of MMTk/DRLVM porting, the cost of dead uncollected objects wasting
 ImmortalSpace memory is not a concern.
  - The existing MMTk/DRLVM porting layer is in rough shape and is
  incomplete.  Now would be a good time to take another pass at refining
  the porting layer.  Below are notes on fixing the porting layer which
  is located at:
  drlvm/trunk/vm/MMTki/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk
  - Project 4
 - Assert class
- This class currently causes a Null Pointer Exception to
force a stack trace in each and every method.  Unfortunately
this means MMTk always crashes even in situations where execution is
supposed to continue.  Some of the APIs supposed to print
the stack trace then continue execution.  This needs to be
fixed.
 - Barriers class
- performWriteInBarrier() – MMTk expects to perform both
the write of an object slot as well as the write barrier.
 The existing contract between Jitrino, VM and the GC
expects that the JIT will write on the object slot then
separately call the
write barrier api (I think).  In any case, if the JIT is
still writing on the object slot, it needs to be changed to
let the MMTk
inlined support function to do it.
- performWriteInBarrierAtomic() – this needs to be
implemented (its not really needed until much later when
multithread support
is turned on.)
- setArrayNoBarrier() – need to write some simple vmmagic
code that will set an element of an array of objects without
triggering a
write barrier.  This support is required by MMTk internal
functions to prevent endless write barrier recursion.
 - Collection Class
- triggerCollection() method needs to be connected to the
Java API that forces a GC (this is low priority)
- prepareMutator() method probably needs to be integrated
with back-branch polling mechanism.  Also need to confirm
the requirement that a thread suspend request does indeed
force the target
thread to be suspended at a GC safepoint.  (MMTk guys, can
you confirm this?)
- prepareCollector() method – Its not clear MMTk/DRLVM
needs to do anything. (MMTk folks please comment on 

Re: [drlvm][jit] Using Class.h in translator

[Pavel Pervov]

Maksim,

Am I right, that at the place you need to retrieve field from a class, you
have both field's name AND descriptor?

If so, you should move definion of FIeld*
class_lookup_field_recursive(Class*, const char*, const char*) from
vmcore/include/Class.h to include/jit_intf.h and change its prototype to
accept Class_Handle instead of Class* and return Field_Handle instead of
FIeld*. Also, please, change the implementation in C_Interface.cpp
accordingly.

Regards,
   Pavel.
On 10/21/06, Maksim Ananjev [EMAIL PROTECTED] wrote:


21.10.06, Mikhail Fursov[EMAIL PROTECTED] wrote:

 AFAIK the vm/vmcore/include/Class.h is vmcore internal header and was
never
 included in JIT.
 To use its functionality you should declare the method you need in
 vm/include/open/vm.h or in vm/include/open/*class*.h file

Thanks! The way you described works!

 What exact functionality do you need?

I need to get field_desc of exact class having only the string name of
this field. So I described special function in Class.h and defined it
in Class.cpp. This method was a bit less painful on last version of
Harmony build , but on actual version it caused severe сompilation
errors.

Such functionality I need in order to develop package of
multidimensional arrays according to JSR-83 and  have it optimized in
JIT-compiler. The idea is to eliminate
redundant boundchecks in a sort of way already implemented ABCD
algorithm eliminates redundant boundchecks in one-dimensional arrays.
(I wrote about this idea here some time ago)

--
Maksim

[build] Problem with fetch-depends part of build script

[Sian January]

Hello,

This morning I have been trying to build Harmony and I'm having a problem
with the fetch-depends part of the build script.  I am getting the following
output:


Buildfile: *C:\eclipse32harmony\eclipse\workspace\Harmony\build.xml

fetch-depends*:
*

-download*:

[*echo*] Checking depends/jars/yoko-m1/yoko.jar
*

-really-download*:

[*echo*] Fetching depends/jars/yoko-m1/yoko.jar

[*get*] Getting:
http://people.apache.org/maven-snapshot-repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M1-SNAPSHOT/yoko-spec-corba-1.0-incubating-M1-20060925.152805-4.jar

[*get*] To:
C:\eclipse32harmony\eclipse\workspace\Harmony\depends\jars\yoko-m1\yoko.jar

[*get*] .

[*get*] last modified = Thu Jan 01 01:00:00 GMT 1970 - using current time
instead
*

-remove-file-if-bad*:

BUILD FAILED
*

C:\eclipse32harmony\eclipse\workspace\Harmony\build.xml:275: The following
error occurred while executing this line:

C:\eclipse32harmony\eclipse\workspace\Harmony\make\depends.xml:158: The
following error occurred while executing this line:

C:\eclipse32harmony\eclipse\workspace\Harmony\make\depends.xml:248: ...
*

File depends/jars/yoko-m1/yoko.jar has incorrect md5 checksum. Expected:

87e62e170dd07cc9c31b9045395f3d10

found:

105a567dc9b27cbcaab4fe058021786e

Total time: 2 minutes 8 seconds

I have tried to run it a few times and also tried deleting the existing
jars.  Can anyone help with this problem?

Thanks,

Sian

--
Sian January

IBM Java Technology Centre, UK

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Pavel Afremov]

+1

Pavel Afremov.


On 10/21/06, Weldon Washburn [EMAIL PROTECTED] wrote:


+1



On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

 We're trying something a little different.  I think Roy Fielding one
 said something along the lines of when a community gets organized
 enough to vote itself out of the Incubator, it's appropriate.

 So to bring the Harmony community and the Incubator community together
 for this important event in Harmony's life, I'm calling for a vote on
 graduating Harmony here on our own -dev list.  The objective is for all
 in both the Harmony community and the Incubator community that have an
 opinion to vote together, in the same place, and have it hosted by the
 Harmony podling.

 This is an unconventional way to do this, but I think that it's valid
 and could provide one example to the Incubator on how it can work going
 forward.

 So, without any further ado :

 [ ] +1 Graduate Apache Harmony from incubation, and let it petition the
 board for Top Level Project status

 [ ] 0 No opinion

 [ ] -1 No, don't graduate Harmony.  Here's why :


 This vote will end 72 hours from now + time of Apache mail outage.  It
 will therefore end on Monday, October 23, at 3:30 PM eastern, + delta
 for mail outage.

 Thanks

 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

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Xiao-Feng Li]

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

We're trying something a little different.  I think Roy Fielding one
said something along the lines of when a community gets organized
enough to vote itself out of the Incubator, it's appropriate.

So to bring the Harmony community and the Incubator community together
for this important event in Harmony's life, I'm calling for a vote on
graduating Harmony here on our own -dev list.  The objective is for all
in both the Harmony community and the Incubator community that have an
opinion to vote together, in the same place, and have it hosted by the
Harmony podling.

This is an unconventional way to do this, but I think that it's valid
and could provide one example to the Incubator on how it can work going
forward.

So, without any further ado :

[ ] +1 Graduate Apache Harmony from incubation, and let it petition the
board for Top Level Project status


+1

Thanks,
xiaofeng

Re: [classlib][luni] java.io.File bug?

[Leo Li]

Have you tested it on windows, for example, signing in as admin, and the
file which is set read only is still writable?:)

It is always good to follow RI or else we might encounter odd problems in
real applications.

Furthermore, root is the concept of OS, so I do not think the role should
be treated specially in the layer of java. We can delegate it to OS service
naturally if possible. I guess RI uses another implementation, for example,
the system call which itself deals with the user account.


On 10/20/06, Spark Shen [EMAIL PROTECTED] wrote:


Tony Wu 写道:
 you mean it fails when f.setReadOnly();?
Hi Tony:

No, setReadOnly is used to change the access privilege. After this
change harmony and RI behaves differently.

Best regards

 On 10/20/06, Spark Shen [EMAIL PROTECTED] wrote:
 Hi All:

 When login as 'root' under Linux, the following test case fails on
 Harmony while passes on RI.
 public void test_canWrite() throws IOException{
 File f = File.createTempFile(test, null);
 f.setReadOnly();
 assertTrue(f.canWrite());
 f.deleteOnExit();
 }

 I think RI's behavior is more reasonable since the 'root' account does
 have read/write privilege for temp files. However, Harmony only treats
 'root' as ordinary other users.
 It seems that similar problem happens on java.io.File.canRead().

 As we all know, File class deals with many different file object on
many
 different file system, would any one test File behavior on other file
 systems.

 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]





--
Leo Li
China Software Development Lab, IBM

Re: [drlvm] Using JNI methods in VM's components.

[Pavel Pervov]

Mikhail,

can relative path be specified in -Dvm.gc_dll/-Dvm.em_dll? If so, the path
should be extended to represent full path.

Regards,

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


On 10/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote:


 This is the reason I've corrected the code. Doesn't it mean that is you
 specified something in -Dvm.em_dll on command line that
System.getProperty
 would return non null value, and then you shall use System.load instead
of
 System.loadLibrary? That is if you change gc to em in the code above.


Gregory, I have completely forgotten about System.load() and
System.loadLibrary() differences. So the problem is solved and I have even
tested the code  :)



--
Mikhail Fursov





--
Pavel Pervov,
Intel Enterprise Solutions Software Division

Re: [classlib][xnet] Problem connecting using SSLSocketImpl

[Alexander Kleymenov]

Hi Gerald,

Boris and I resolved the problem. This was an incorrect Certificate
Verify message sent to the server peer during mutual authentication.
Please try the attached patch and tell us how it works. If it is OK
for you I will attach it to the JIRA report you created (when the
server will work). Please, note – this patch should be applied on the
current JSSE source versions (i.e. without early applied patches).

Actually Harmony supports PKCS12 keystore format. But there is an
issue with using it. We now work on this problem.

Thanks for your collaboration in making Harmony's JSSE Provider more
stable and robust! We really appreciate you support!

Regards,
Alexander Kleymenov
Index: 
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/DigitalSignature.java
===
--- 
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/DigitalSignature.java
 (revision 466004)
+++ 
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/DigitalSignature.java
 (working copy)
@@ -71,6 +71,7 @@
 public DigitalSignature(int keyExchange) {
 try { 
 if (keyExchange == CipherSuite.KeyExchange_RSA_EXPORT ||
+keyExchange == CipherSuite.KeyExchange_RSA ||
 keyExchange == CipherSuite.KeyExchange_DHE_RSA ||
 keyExchange == CipherSuite.KeyExchange_DHE_RSA_EXPORT) {
 // SignatureAlgorithm is rsa
Index: 
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/ClientHandshakeImpl.java
===
--- 
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/ClientHandshakeImpl.java
  (revision 466004)
+++ 
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/ClientHandshakeImpl.java
  (working copy)
@@ -29,6 +29,7 @@
 import java.security.KeyPair;
 import java.security.KeyPairGenerator;
 import java.security.NoSuchAlgorithmException;
+import java.security.PrivateKey;
 import java.security.PrivilegedExceptionAction;
 import java.security.PublicKey;
 import java.security.cert.CertificateException;
@@ -366,6 +367,8 @@
  * client messages, computers masterSecret, sends ChangeCipherSpec
  */
 void processServerHelloDone() {
+PrivateKey clientKey = null;
+
 if (serverCert != null) {
 if (session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DH_anon
 || session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DH_anon_EXPORT) {
@@ -389,8 +392,10 @@
 .getTypesAsString(),
 certificateRequest.certificate_authorities, null);
 if (clientAlias != null) {
-certs = ((X509ExtendedKeyManager) parameters.getKeyManager())
-.getCertificateChain((clientAlias));
+X509ExtendedKeyManager km = (X509ExtendedKeyManager) parameters
+.getKeyManager();
+certs = km.getCertificateChain((clientAlias));
+clientKey = km.getPrivateKey(clientAlias);
 }
 session.localCertificates = certs;
 clientCert = new CertificateMessage(certs);
@@ -503,27 +508,29 @@
 
 computerMasterSecret();
 
-if (clientCert != null) {
-boolean[] keyUsage = clientCert.certs[0].getKeyUsage();
-if (keyUsage != null  keyUsage[0]) {
-// Certificate verify
-DigitalSignature ds = new DigitalSignature(
-session.cipherSuite.keyExchange);
-if (session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_RSA_EXPORT
-|| session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DHE_RSA
-|| session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DHE_RSA_EXPORT) {
-ds.setMD5(io_stream.getDigestMD5());
-ds.setSHA(io_stream.getDigestSHA());
-} else if (session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DHE_DSS
-|| session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DHE_DSS_EXPORT) {
-ds.setSHA(io_stream.getDigestSHA());
-// The Signature should be empty in case of anonimous 
signature algorithm:
-// } else if (session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DH_anon ||
-// session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DH_anon_EXPORT) {
-}
-certificateVerify = new CertificateVerify(ds.sign());
-send(certificateVerify);
+// send certificate verify for all certificates except those containing
+// fixed DH parameters
+if (clientCert != null  !clientKeyExchange.isEmpty()) {
+// Certificate verify
+DigitalSignature ds = new 

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Alexei Zakharov]

+1 from me. Our community seems to be very active and healthful.

Best regards,

2006/10/20, Geir Magnusson Jr. [EMAIL PROTECTED]:

We're trying something a little different.  I think Roy Fielding one
said something along the lines of when a community gets organized
enough to vote itself out of the Incubator, it's appropriate.

So to bring the Harmony community and the Incubator community together
for this important event in Harmony's life, I'm calling for a vote on
graduating Harmony here on our own -dev list.  The objective is for all
in both the Harmony community and the Incubator community that have an
opinion to vote together, in the same place, and have it hosted by the
Harmony podling.

This is an unconventional way to do this, but I think that it's valid
and could provide one example to the Incubator on how it can work going
forward.

So, without any further ado :

[ ] +1 Graduate Apache Harmony from incubation, and let it petition the
board for Top Level Project status

[ ] 0 No opinion

[ ] -1 No, don't graduate Harmony.  Here's why :


This vote will end 72 hours from now + time of Apache mail outage.  It
will therefore end on Monday, October 23, at 3:30 PM eastern, + delta
for mail outage.

Thanks

geir



--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

Re: [drlvm][classlib] thread library - let there be one!

[Angela Lin]

What is the goal here?

1. If the goal is to create a single thread library that can be used
by multiple VM and classlib implementations, then the unified thread
lib should contain everything needed to support a VM implementation.

2. If the goal is to simply define the interface between the classlib
and the VM, then the 3rd option may be acceptable. This option seems
to imply splitting up functionality that requires deep knowledge of
the threading implementation, which I don't like. Each VM
implementation would need to implement both the VM and classlib sides
of the API.

Regards,
Angela

On 10/19/06, Artem Aliev [EMAIL PROTECTED] wrote:

Angela, all,

I see you point and agree.
But if we move hythread lib to the VM we will require all VMs fully support it.
Is it necessary dependency?

So Here is the third way I see.
Leave the minimum implementation of hythread in the classlib, with the
set of functions any VM should provide for classlib.
  This will simplifies adopting classlib to new VM and allows to have
solid threading model.
So any VM could have its own super set of threading functions.

Note: Classlib uses only monitor, TLS, and thread_create() from hythread.

Thanks
Artem




On 10/18/06, Angela Lin [EMAIL PROTECTED] wrote:
 Artem et al,

 Sorry for jumping in late here.

 I maintain the J9VM thread lib.

 Option 1 worries me because it implies that the classlib could use a
 different threading model from the VM. This is bad because they both
 operate on the same threads.

 For example: Layer (2) of hythread might include internal thread state
 tracking, which is needed to support inspecting the thread state.
 Using layer (1) directly would bypass the thread state tracking.

 Angela


 On 10/16/06, Artem Aliev [EMAIL PROTECTED] wrote:
  Tim,
 
  Reading through discussion, I find two option for the second step.
  Let's discuss them.
 
  1.
   -  split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
   upper layer (hythead_xxx)
   -  migrate classlib code to the bottom layer (1) of hythread
  Then move the rest of hythread to VM.
 
  In this case we will move all VM releated functionality out of a classlib.
  The classlib will use tls, mutex and thread_create from *.h files.
  VM will be free to implement threading in any way.
 
  2. Move hythread out from the drlvm to a portlib.
  In this case  classlib will contains a lot of only VM releated code.
  So we will meet the same problems with an new VM.  But we will have
  common place for all synchronization primitives and could control
  them.
 
  Thanks
  Artem
 
 
 
 
 
  On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
  
  
   Tim Ellison wrote:
First step (moving out of luni) looks good to me.
   
I'd like some more discussion around the second step (picking up drlvm
version) before you do a wholesale replacement.
  
   Yes please.  Lets do small, reversible steps.
  
   geir
  
   
Regards,
Tim
   
Weldon Washburn wrote:
Artem,
Thanks.  I will take a look.
   
   
On 10/12/06, Artem Aliev [EMAIL PROTECTED] wrote:
Guys,
   
   
1.  Make classlib/modules/portlib directory (or portlib in the root?)
and move hyprt, hysig and hythread code into it. Update build to work
with new directory.
   
[Andrey]-  pull out hythread from classlib, make it a shared
component
The first step is done in JIRA HARMONY-1843.
   
I move common, pool, port, thread, sig from luni to new component
portlib.
The first idea was to move only port, thread, sig, but they depend on
common and pool libs. It looks natural to do not produce cyclic
dependencies among components, so I move these two also to portlib.
   
Unfortunately, this does not fully solve two stage luni building
process (build-native-core and build-native-secondary), but this is
another problem.
   
So If we are still committed on these reorganization, please review
and apply the patch.
   
A move_to_portlib.sh script create portlib directory structure and
move appropriate files from luni to portlib (by svn move).
A portlib_files.patch update build to works with new structure.
   
Thanks
Artem
   
   
   
   
On 9/29/06, Artem Aliev [EMAIL PROTECTED] wrote:
Guys,
   
Let me try to make this changes.
   
Here is my understanding of  the steps I need to do.
   
1.  Make classlib/modules/portlib directory (or portlib in the root?)
and move hyprt, hysig and hythread code into it. Update build to work
with new directory.
   
[Andrey]-  pull out hythread from classlib, make it a shared
component
2. Move DRLVM hythread to classlib and update drlvm build for it. So
both classlib and drlvm will work on the drlvm hythread.
   
-  split hythread, refine the bottom layer (thrdsup.h and mutex.h)
and
upper layer (hythead_xxx)
-  migrate classlib code to the bottom layer (1) of hythread
I do not think it is necessary 

Re: [drlvm][jit] Seems like too many classes loaded

[Mikhail Fursov]

Welcome Armand!
My comments are inlined.

On 10/23/06, Armand Navabi [EMAIL PROTECTED] wrote:


I am trying to become more familiar with the jit code.  I ran the
following to see what all was compiled when running Hello World.
java -Xtrace:compile Hello.  I was very surprised to see the number of
methods that seem to be loaded.  I think there are about 1079 methods
that get compiled for Hello World.



Yes you are right. To run Hello World  application  ~ 1000 methods are
compiled.
These methods are from threads, IO, classloading, security, utilities, VM
infrastructure classes.
1000 methods is not a big number: the optimizing compiler performance is
more than 1000/per second (my 2Ghz PC). The baseline  JET compiler is ten
times faster.


Does harmony just load all the classes in the classlib and compile every

method?  If not, then why would there be so many methods compiled for a
simple hello world program?



Not  Harmony does not load all the classes.

Right now I am trying to write a simple profiling tool that counts the

number of certain instructions in a program for a given input (i.e. I
want to run the program, and for every instruction that ends up running,
collect information).  So, since it seems that the jit not only compiles
every instruction in the program (not only the ones that end up
running), but also a bunch of other classes, I thought perhaps I would
be more interested in the interpreter.



Interpreter also executes a lot of startup methods before running main.
There is a solution how to compile only predefined set of methods by
separate JIT compiler.
See EM guide for details how to filter methods:
http://incubator.apache.org/harmony/subcomponents/drlvm/emguide.html
The filters will not work with interpreter.


Also, I am trying to become familiar with the jit and interpreter by

reading the DRL Developer's Guide.  Are there any other resources other
than the Developer's Guide and this mailing list?



Check these pages too:
http://incubator.apache.org/harmony/subcomponents/drlvm/index.html
http://wiki.apache.org/harmony/

or ask directly in the mailing list :)

--
Mikhail Fursov

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

[Mikhail Fursov]

Pavel, I see no attachment.. ?

On 10/23/06, Pavel Afremov [EMAIL PROTECTED] wrote:


Hi



I've developed two impossible tests, which shows fake circularity
errors. One test is more simple and use SecurityManager. The other is a bit
more complex and uses custom ClassLoader. You can find them in attachment.



Thanks.

Pavel Afremov


On 10/17/06, Pavel Pervov [EMAIL PROTECTED] wrote:

 The scenario I described earlier is impossible. Resolution of any class
 referenced in some other class is performed by class loader, which
 loaded
 that other class. So, no chance to load A and referencing class loader
 (UCL) with this UCL.

 Sorry for confusion.

 Regards,
Pavel.

 P.S. Still there are concerns why lazy resolution should be supported by

 JITs. But it is absolutely another story.

 On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
 
  IMO we shall be between BEA and SUN: to work if both RI work, to fail
 if
  both RI fail and discuss each test in details if only one RI passes.
 
  On 10/17/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
  
   On Friday 13 October 2006 08:04 Alexey Varlamov wrote:
I'm curious, if we enable controlled recursion in classloading -
will it resolve this kind of issues completely? I'm pretty sure it
would resolve at least some scenarios - like the one Pavel
 described
for gc.Finalizers or a case of classloading initiated within
SecurityManager.checkPermission() which we also faced not once.
Controlled recursion here means counting depth of recursion and
allowing at least 1 recursive iteration. I've seen some tricks in
URLClassLoader which assume such ability, but they do not work
 with
DRLVM.
  
   I think it is different. URLClassLoader is system class which is
 loaded
  by
   bootstrap, so no recursion happens for classes which it itself
 requires
  to
   be
   loaded when it is being compiled.
  
For the pure user code scenario Pavel suggested above, there may
 be
some nuances leading to truly endless recursion, but still we need
 to
look at particular test first.
  
   It is not endless but it is definitely more than 1 level deep. If
 user
   sets up
   his own class loaders, compiling them may trigger loading some of
 the
  user
   classes which are in turn loaded by class loaders set up by user.
 Shall
  we
   then throw NoClassDefFoundError: Class loading recursion limit
 reached.
   Please rewrite your code? :)
  
   --
   Gregory Shimansky, 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
 
 






--
Mikhail Fursov

Re: [drlvm] Calling native methods from Java code: implementation details

[Mikhail Fursov]

Pavel,
I've found only one problem in your design.
Why do we need 1) if every component must have 2)
E.g. why not to implement get_address(int) method in C language too? AFAIU
Pavel Afremov's design has no C-interface methods at all.

--
Mikhail Fursov

Re: [drlvm] Using JNI methods in VM's components.

[Pavel Pervov]

Mikhail,

What i've meant is that we should account for all interchangeable components
which can/want/should provide fast-path helpers.

Pavel.

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


Pavel, I'm sorry I do not understand what the replacement do you mean?
I said that only about a part of a component could be written in Java (e.g
.
EM, helpers), but not the whole component...

On 10/20/06, Pavel Pervov [EMAIL PROTECTED] wrote:

 What about TM replacement (although it is almost impossible at the
 moment)?



--
Mikhail Fursov





--
Pavel Pervov,
Intel Enterprise Solutions Software Division

Re: [general] Incubator graduation update

[Matt Benson]

--- Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
[SNIP]
 First, there are minor 'nits' here and there related
 to license and 
 license headers.  For example, we're missing the
 antlr license in our 
 NOTICE file.

wrt this particular nit, antlr 2.x.x versions are
public domain... text:

---

ANTLR 2 License

We reserve no legal rights to the ANTLR--it is fully
in the public domain. An individual or company may do
whatever they wish with source code distributed with
ANTLR or the code generated by ANTLR, including the
incorporation of ANTLR, or its output, into commerical
software.

We encourage users to develop software with ANTLR.
However, we do ask that credit is given to us for
developing ANTLR. By credit, we mean that if you use
ANTLR or incorporate any source code into one of your
programs (commercial product, research project, or
otherwise) that you acknowledge this fact somewhere in
the documentation, research report, etc... If you like
ANTLR and have developed a nice tool with the output,
please mention that you developed it using ANTLR. In
addition, we ask that the headers remain intact in our
source code. As long as these guidelines are kept, we
expect to continue enhancing this system and expect to
make other tools available as they are completed. 

---

so any form of acknowledgement is probably good enough
to satisfy Terence.

-Matt

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: svn commit: r466154 - in /incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent: ./ locks/

[Geir Magnusson Jr.]

that's not a bad idea...

Nathan Beyer wrote:

This can be controlled a bit more. An svn:externals link can point to
a specific revision, not just a SVN URL. This way the working copy
download has to be changed at the point of link.

-Nathan

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

Great - I wanted to make sure.  I was asking based on a cursory glance.

geir


Nathan Beyer wrote:
 They are in 'standard' and do use 'links' (svn:externals). Check out
 the full path of the original commit message. Using svn:externals just
 makes it seem like it's in 'extended', but that's just in your working
 copy.

 -Nathan

 On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 Thanks for bringing this up. I did a classlib update this morning, and
 saw these files change, and I was confused.

 Why do we have the files here anyway?  I thought we were going to keep
 in /standard and use links?

 geir

 Tim Ellison wrote:
  Mark,
 
  I suggest that this is rolled back since it is modifying the
 concurrency
  code in our 'standard' SVN area that we aim to keep in close sync 
with

  Doug's repository.
 
  Perhaps we can offer the patch to that community, and/or set up 
local

  compiler options to hide the warnings in this module.
 
  Regards,
  Tim
 
  [EMAIL PROTECTED] wrote:
  Author: hindessm
  Date: Fri Oct 20 08:47:50 2006
  New Revision: 466154
 
  URL: http://svn.apache.org/viewvc?view=revrev=466154
  Log:
  Applied two patches from [#HARMONY-1926] [build] A lot of never
 used
  and never read warning messages.
 
  Modified:
 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ArrayBlockingQueue.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ConcurrentHashMap.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/CountDownLatch.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/DelayQueue.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/Delayed.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ExecutorService.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/Executors.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/FutureTask.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/ScheduledExecutorService.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/Semaphore.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/SynchronousQueue.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/AbstractQueuedSynchronizer.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/LockSupport.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/ReentrantLock.java 



 
 
incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent/locks/ReentrantReadWriteLock.java 



 
 
 

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

Re: [general] Incubator graduation update

[robert burrell donkin]

On 10/23/06, Matt Benson [EMAIL PROTECTED] wrote:

--- Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
[SNIP]
 First, there are minor 'nits' here and there related
 to license and
 license headers.  For example, we're missing the
 antlr license in our
 NOTICE file.

wrt this particular nit, antlr 2.x.x versions are
public domain... text:

---

ANTLR 2 License

We reserve no legal rights to the ANTLR--it is fully
in the public domain. An individual or company may do
whatever they wish with source code distributed with
ANTLR or the code generated by ANTLR, including the
incorporation of ANTLR, or its output, into commerical
software.

We encourage users to develop software with ANTLR.
However, we do ask that credit is given to us for
developing ANTLR. By credit, we mean that if you use
ANTLR or incorporate any source code into one of your
programs (commercial product, research project, or
otherwise) that you acknowledge this fact somewhere in
the documentation, research report, etc... If you like
ANTLR and have developed a nice tool with the output,
please mention that you developed it using ANTLR. In
addition, we ask that the headers remain intact in our
source code. As long as these guidelines are kept, we
expect to continue enhancing this system and expect to
make other tools available as they are completed.

---

so any form of acknowledgement is probably good enough
to satisfy Terence.


the public domain has become difficult in recent times. in some
jurisdictions (in europe), i believe that an explicit license is
required. (yes, i know it's daft.) copyright may also now be primarily
criminal matter between the state and the copier. the opinions of the
author matter little. so, it's best to include the statement.

and a note to the notice file to acknowledge Terence :-)

- robert

Re: [general] Incubator graduation update

[Matt Benson]

--- robert burrell donkin
[EMAIL PROTECTED] wrote:

 On 10/23/06, Matt Benson [EMAIL PROTECTED]
 wrote:
  --- Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
  [SNIP]
  wrt this particular nit, antlr 2.x.x versions
 are
  public domain... 

 the public domain has become difficult in recent
 times. in some
 jurisdictions (in europe), i believe that an
 explicit license is
 required. (yes, i know it's daft.) copyright may
 also now be primarily
 criminal matter between the state and the copier.
 the opinions of the
 author matter little. so, it's best to include the
 statement.
 
 and a note to the notice file to acknowledge Terence
 :-)

FWIW, when ANTLR3 is fully baked, these issues will be
easier as it's under a sane and relatively
easy-to-interpret BSD license as compared to custom
OSS or PD license.  :)

-Matt

 
 - robert
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[DRLVM][MMTk] current status and plan

[Weldon Washburn]

-- Forwarded message --
From: Weldon Washburn [EMAIL PROTECTED]
Date: Oct 23, 2006 9:07 AM
Subject: [DRLVM][MMTk] current status and plan
To: harmony-dev@incubator.apache.org

Current status

  - Robin Garner's mmtk_20061016.zip snapshot of MMTk source now runs
  the simple user-level MarkSweep.java test on DLRVM svn HEAD of
  10/20/2006.  The mods to MMTk porting layer to support the above have
  been committed to DRLVM HEAD. The next steps for the MMTk/DRLVM port are as
  follows.   Comments, suggestions are welcome.   It would be much
  appreciated if Steve Blackburn and Robin Garner would reply to the questions
  below directed to the MMTk guys.

The following plan is roughly in the order this work should be done.

  - Currentlly MMTk/DRLVM runs as a user-level app.  That is, MMTk
  port allocates a 450MB array from DRLVM's underlying GC.  Currently
  only GCV4.0 supports 450MB arrays.  A vmmagic Address object is
  created that points to the base of the 450MB array.   MMTk is booted
  with the Address of the 450MB object.  A simple MMTK exerciser was
  written in Java/vmmagic.   It calls MMTk alloc() repeatedly.  When
  MMTk runs out of memory, it will GC its user-level heap (the
450MB array).
  The underlying GCV4 is oblivious to what MMTK is doing with this 450MB
  array.
  - Project 1
 - Move the existing MMTk port to GCV5.   We need to remove the
 dependency on GCV4.
  - MMTk SemiSpace, GenMS and CopyMS collectors actually worked before
  upgrading to latest the MMTk sources and current DRLVM svn HEAD.
  - Project 2
 - Get SemiSpace, GenMS and CopyMS collectors working again.   Basically
 this means running TestSemiSpace.java, TestGenMS.java and
 TestCopyMS.java exerciser programs and debugging the problems.  Known
 issues that need fixing:
- Java write barrier in Jitrino.JET needs to be debugged
- MMTk needs the two LSBs of one of the object header
byte.  This was somehow broken during the commit of
BBC.patch. It needs to be fixed.  There is email on this
topic in harmony-dev.
 - To reduce confusion, all of MMTk java source code needs to be
  jitted before any MMTk methods are called.
  - Project 3
 - Modify DLRVM classloader to force all MMTk classes to be
 loaded and all methods JITed before any classlib java code is executed.
 - The next step is to integrate MMTk in the early DRLVM boot
 process.  The goal is to make sure all code the JIT generates
 will allocate out of the MMTk heap.  This is a chicken and egg
 kind of problem since no JITed code can execute until DRLVM has
a GC that is
 ready to support object allocation.   Most likely we will use
 the MMTk notion of ImmortalSpace for early object allocation.
  Objects in ImmortalSpace are never collected, never moved.  At
 this stage of MMTk/DRLVM porting, the cost of dead uncollected objects
 wasting ImmortalSpace memory is not a concern.
  - The existing MMTk/DRLVM porting layer is in rough shape and is
  incomplete.  Now would be a good time to take another pass at refining
  the porting layer.  Below are notes on fixing the porting layer which
  is located at:
  drlvm/trunk/vm/MMTki/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk
  - Project 4
 - Assert class
- This class currently causes a Null Pointer Exception to
force a stack trace in each and every method.  Unfortunately
this means MMTk always crashes even in situations where execution is
supposed to continue.  Some of the APIs supposed to print
the stack trace then continue execution.   This needs to
be fixed.
 - Barriers class
- performWriteInBarrier() – MMTk expects to perform both
the write of an object slot as well as the write barrier.
 The existing contract between Jitrino, VM and the GC
expects that the JIT will write on the object slot then
separately call the
write barrier api (I think).  In any case, if the JIT is
still writing on the object slot, it needs to be changed to
let the MMTk
inlined support function to do it.
- performWriteInBarrierAtomic() – this needs to be
implemented (its not really needed until much later when
multithread support
is turned on.)
- setArrayNoBarrier() – need to write some simple vmmagic
code that will set an element of an array of objects without
triggering a
write barrier.   This support is required by MMTk internal
functions to prevent endless write barrier recursion.
 - Collection Class
- triggerCollection() method needs to be connected to the
Java API that forces a GC (this is low priority)
- prepareMutator() method probably needs to be integrated
with back-branch polling mechanism.  Also need to confirm
the requirement that a thread suspend request does indeed
force the target
thread to 

Re: [general] Incubator graduation update

[Geir Magnusson Jr.]

Lets stuff the whole thing in there...

robert burrell donkin wrote:

On 10/23/06, Matt Benson [EMAIL PROTECTED] wrote:

--- Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
[SNIP]
 First, there are minor 'nits' here and there related
 to license and
 license headers.  For example, we're missing the
 antlr license in our
 NOTICE file.

wrt this particular nit, antlr 2.x.x versions are
public domain... text:

---

ANTLR 2 License

We reserve no legal rights to the ANTLR--it is fully
in the public domain. An individual or company may do
whatever they wish with source code distributed with
ANTLR or the code generated by ANTLR, including the
incorporation of ANTLR, or its output, into commerical
software.

We encourage users to develop software with ANTLR.
However, we do ask that credit is given to us for
developing ANTLR. By credit, we mean that if you use
ANTLR or incorporate any source code into one of your
programs (commercial product, research project, or
otherwise) that you acknowledge this fact somewhere in
the documentation, research report, etc... If you like
ANTLR and have developed a nice tool with the output,
please mention that you developed it using ANTLR. In
addition, we ask that the headers remain intact in our
source code. As long as these guidelines are kept, we
expect to continue enhancing this system and expect to
make other tools available as they are completed.

---

so any form of acknowledgement is probably good enough
to satisfy Terence.


the public domain has become difficult in recent times. in some
jurisdictions (in europe), i believe that an explicit license is
required. (yes, i know it's daft.) copyright may also now be primarily
criminal matter between the state and the copier. the opinions of the
author matter little. so, it's best to include the statement.

and a note to the notice file to acknowledge Terence :-)

- robert

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

[Gregory Shimansky]

On Monday 23 October 2006 22:05 Mikhail Fursov wrote:
 Pavel, I see no attachment.. ?

I think Geir has commented on this once. Apache mail list filters some types 
of attachments away (IIRC to keep all intellectual property clean from code 
taken from unknown code sources). To make some files public to everyone 
create a JIRA and attach files to it.

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [drlvm] A list of drlvm enhancements and limitations

[Gregory Shimansky]

On Monday 23 October 2006 20:21 Weldon Washburn wrote:
 All,
 Just a few minutes ago I sent a mail titled, [DRLVM][MMTk] current status
 and plan.  It is way too long and detailed to include in this list of
 drlvm enhancements.  Below is a summary that hopefully is at the
 appropriate level of detail.  Please refer to the above email for more
 information.

 Summary of MMTk projects
 1)
 Move the exiting uswer-level MMTk port to GCV5
 2)
 Get MMTk SemiSpace, GenMS and CopyMS collector running again.  They were
 broken during migration to latest MMTk source and latest drlvm svn HEAD.
 3)
 Alter DRLVM classloader to force all MMTk classes to be loaded and all
 methods to be JITed before any java code is executed.  Integrate MMTk into
 an early stage of DRLVM boot.
 4)
 Fix up MMTk/VM porting layer which is located at:
 drlvm/trunk/vm/MMTki/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk
 5)
 Debug and verify JIT support for MMTk's Uninterruptible class.  Run simple
 multithread app and debug.

 On 10/17/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
  Hi Gregory,
 It is a good idea to put up a live list, thanks. Here are some
  suggestions on the contents for development items in the VM/JIT. A few
  may be almost done. We can fine tune...and add other work items as well
 
 
  - MMTk integration:
  Support for magic classes in Jitrino
  VM/JIT support for MMTk collectors including RSE and thread suspension
 
  ( Weldon, could you please add details?)

Weldon, can you make a subpage to Rana's list and link it to the MMTK 
integration item?

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [drlvm] Using JNI methods in VM's components.

[Gregory Shimansky]

On Monday 23 October 2006 14:15 Pavel Pervov wrote:
 Mikhail,

 can relative path be specified in -Dvm.gc_dll/-Dvm.em_dll? If so, the path
 should be extended to represent full path.

So it should be something like

class GCv5Magics {
    static {
        String gcPath = System.getProperty(vm.gc_dll);
        if (gcPath != null) {
try {
gcPath = (new File(gcPath)).getCanonicalName();
} catch (IOException e) {
System.err.println(Failed to find library specified in 
\vm.gc_dll\ property:  + e);
System.loadLibrary(gc);
return;
}
System.load(gcPath);
        }
        else {
            System.loadLibrary(gc);
        }
    }
}

 On 10/21/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
  On 10/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
   This is the reason I've corrected the code. Doesn't it mean that is you
   specified something in -Dvm.em_dll on command line that
 
  System.getProperty
 
   would return non null value, and then you shall use System.load instead
 
  of
 
   System.loadLibrary? That is if you change gc to em in the code above.
 
  Gregory, I have completely forgotten about System.load() and
  System.loadLibrary() differences. So the problem is solved and I have
  even tested the code  :)
 
 
 
  --
  Mikhail Fursov

-- 
Gregory Shimansky, Intel Middleware Products Division

RE: [classlib][test] Configuration dependent test of InetAddress.getHostName

[Fedotov, Alexei A]

Hello, All,

Paulex wrote,
 the test needs to be rewritten or excluded
+1, and the option to exclude the test is pretty understandable.

I wonder about the first option. Is there any way to check that symbolic
name corresponds to the local computer? I can imagine the following
condition to check this.

InetAddress.getByName(InetAddress.getByName(127.0.0.1).getHostName()).
isLoopbackAddress()

Thoughts?


With best regards,
Alexei Fedotov,
Intel Java  XML Engineering
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Monday, October 23, 2006 6:47 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][test] Configuration dependent test of
InetAddress.getHostName

 I think Harmony does the right thing as spec requires, the difference
is
 caused by underlying system call, so it should be acceptable, i.e.,
the
 test needs to be rewritten or excluded.

+1 from me

Thanks,

2006/10/20, Paulex Yang [EMAIL PROTECTED]:
 Denis Kishenko wrote:
  I have researched issue H-1664 and found one more difference with
RI.
  I run simple test on Windows Server 2003 SP1
 
  === Test =
  import java.net.InetAddress;
  import java.net.UnknownHostException;
 
  public class Test {
 public static void main(String[] args) throws
UnknownHostException {
 System.out.println(by name (127.0.0.1) -  +
  InetAddress.getByName(127.0.0.1).getHostName());
 System.out.println(by name (localhost) -  +
  InetAddress.getByName(localhost).getHostName());
 System.out.println(by address -  +
  InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
 System.out.println(localhost -  +
InetAddress.getLocalHost());
 }
 
  }
 
  Windows Server 2003 SP1
  === RI ==
 by name (127.0.0.1) - 127.0.0.1
 by name (localhost) - localhost
 by address - 127.0.0.1
 localhost - nstdrlew21/10.125.122.60
 
  = Harmony ==
 by name (127.0.0.1) - nstdrlew21.ins.intel.com
 by name (localhost) - localhost
 by address - nstdrlew21.ins.intel.com
 localhost - nstdrlew21/10.125.122.60
 
  WinXP
  = Both ===
  by name (127.0.0.1) - localhost
  by name (localhost) - localhost
  by address - localhost
  localhost - pbwdmkishen/10.125.132.226
 
 
  Actually Harmony use native call of getnameinfo() to get host name
  (which is reasonable IMHO). MSDN says The getnameinfo function
  provides name resolution from an address to the host name.
 
  InetAddressTest.test_getHostName (see H-1664) failed on WinServer
  because InetAddress.getByName(127.0.0.1).getHostName() returned
  nstdrlew21.ins.intel.com while localhost expected. So this test
  looks like configuration dependent.
 
  I see three possible options
  1. Stay test as is. Just keep in mind that on specific
configurations
  this one fails.
  2. Rewrite test to be configuration dependent. Test has to do the
same
  native call.
  3. Exclude localhost checking from test_getHostName.
 I think Harmony does the right thing as spec requires, the difference
is
 caused by underlying system call, so it should be acceptable, i.e.,
the
 test needs to be rewritten or excluded.  But this issue worth a
non-bug
 difference together with getHostName()'s different behavior when
 SecurityManager presents[1](thanks Alexei Fedotov helped to find this
 link and commented to HARMONY-1664:))

 Harmony-73 is another issue, which is actually caused by HARMONY-84
and
 irrelevant with getHostName() method.

 [1]
 http://mail-archives.apache.org/mod_mbox/incubator-harmony-
dev/200602.mbox/[EMAIL PROTECTED]
 
  What do you think about this situation?

--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Pavel Ozhdikhin]

+1 from me !

thanks,
Pavel


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


We're trying something a little different.  I think Roy Fielding one
said something along the lines of when a community gets organized
enough to vote itself out of the Incubator, it's appropriate.

So to bring the Harmony community and the Incubator community together
for this important event in Harmony's life, I'm calling for a vote on
graduating Harmony here on our own -dev list.  The objective is for all
in both the Harmony community and the Incubator community that have an
opinion to vote together, in the same place, and have it hosted by the
Harmony podling.

This is an unconventional way to do this, but I think that it's valid
and could provide one example to the Incubator on how it can work going
forward.

So, without any further ado :

[ ] +1 Graduate Apache Harmony from incubation, and let it petition the
board for Top Level Project status

[ ] 0 No opinion

[ ] -1 No, don't graduate Harmony.  Here's why :


This vote will end 72 hours from now + time of Apache mail outage.  It
will therefore end on Monday, October 23, at 3:30 PM eastern, + delta
for mail outage.

Thanks

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: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Gregory Shimansky]

On Sunday 22 October 2006 01:08 Nathan Beyer wrote:
 I haven't had a chance to look at the issue (JIRAs down right now,
 probably part of the infrastructure move), but have you tried
 comparing the actual class files of the problematic class or classes.

 I'd suggest compiling the files using ECJ, save them off, compile with
 Sun/BEA/etc, save them off and then run javap from a single JDK on
 each of the class files and compare them for differences.

Yes, it is quite interesting how different compilers produce different class 
attributes, it looks like this is the main problem with the code. ECJ insists 
on marking inner classes private. Elena was kind to send me another test 
which she wrote while JIRA was down and it shows even a bigger difference 
between the compilers - it produces different output on RI. In the 2nd test 
ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while Sun 
creates Test1931_2$1LocalClass. This gives different output from 
cc.getEnclosingClass and cc.isLocalClass where cc is the used inner class.

Nevertheless RI allows the access to the inner private class it seems. It 
doesn't throw the exception which drlvm does. The exception source is drlvm's 
kernel class ReflectExporter and the method in question is allowAccess which 
calls allowClassAccess at line 113. This check is the one and the only chance 
to return true in this case.

I've debugged the code with recently implemented debugging support of drlvm 
using eclipse (jdwp agent has to be build for this from HARMONY-1410, also  
kernel classes for drlvm aren't compiled with debug support, build script has 
to be hacked) but I just don't know all of the access checks specification 
statements to make a decision which one is not correct.

P.S. I used ecj 3.2 which we use for current classlib compilation.

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Matthias Wessendorf]

Yeah,

harmony is sorta fun. has more than 640 subscribers on the dev list!
that's a lot for a podling.

That is double of that what we have at myfaces!

so let's move forward here!
-M

On 10/20/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote:

+1

As far as I understand the main goal of incubation is creation of
healthy community. It means that all these non-binding +1 votes do bind
us to this project. :-)

With best regards,
Alexei Fedotov,
Intel Java  XML Engineering

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Matthias Wessendorf
Sent: Saturday, October 21, 2006 1:47 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [vote] Graduate Apache Harmony podling from the Incubator

Since I am not a committer or ppmc of this podling, my vote is
non-binding.

+1

hope to get the Trinidad Podling build done by Harmony soon!
;)

-Matthias

On 10/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
 +1 from me!

 On 10/21/06, Alex Blewitt [EMAIL PROTECTED] wrote:
 
  On 20/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
   [ ] +1 Graduate Apache Harmony from incubation, and let it
petition
the
   board for Top Level Project status
 
  +1 from me too.
 
  Alex.
 
 
-
  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




--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

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




--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Davanum Srinivas]

Hi Folks,

Sorry for the delay.

[ +1] Graduate Apache Harmony from incubation, and let it petition the
board for Top Level Project status

-- dims

--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)

Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Nathan Beyer]

By inner class you mean an automatic/local class in this case; a
class declared inside a method. It would seem appropriate that a local
class is declared private. Only the method that contains the class
declaration can see it.

Do you disagree with what ECJ is generating?

-Nathan

On 10/23/06, Gregory Shimansky [EMAIL PROTECTED] wrote:

On Sunday 22 October 2006 01:08 Nathan Beyer wrote:
 I haven't had a chance to look at the issue (JIRAs down right now,
 probably part of the infrastructure move), but have you tried
 comparing the actual class files of the problematic class or classes.

 I'd suggest compiling the files using ECJ, save them off, compile with
 Sun/BEA/etc, save them off and then run javap from a single JDK on
 each of the class files and compare them for differences.

Yes, it is quite interesting how different compilers produce different class
attributes, it looks like this is the main problem with the code. ECJ insists
on marking inner classes private. Elena was kind to send me another test
which she wrote while JIRA was down and it shows even a bigger difference
between the compilers - it produces different output on RI. In the 2nd test
ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while Sun
creates Test1931_2$1LocalClass. This gives different output from
cc.getEnclosingClass and cc.isLocalClass where cc is the used inner class.

Nevertheless RI allows the access to the inner private class it seems. It
doesn't throw the exception which drlvm does. The exception source is drlvm's
kernel class ReflectExporter and the method in question is allowAccess which
calls allowClassAccess at line 113. This check is the one and the only chance
to return true in this case.

I've debugged the code with recently implemented debugging support of drlvm
using eclipse (jdwp agent has to be build for this from HARMONY-1410, also
kernel classes for drlvm aren't compiled with debug support, build script has
to be hacked) but I just don't know all of the access checks specification
statements to make a decision which one is not correct.

P.S. I used ecj 3.2 which we use for current classlib compilation.

--
Gregory Shimansky, Intel Middleware Products Division

Re: Harmony passes 94% on derby tests.

[Tony Wu]

congratulations!

On 10/23/06, Leo Li [EMAIL PROTECTED] wrote:

467 Tests Run
94% Pass (443 tests passed)
 6% Fail (24 tests failed)
5 Suites skipped

The main progress focuses here:
1. Harmony classlib fails to load class when user-defined security policy
exists. It is due to the sequence of library loading of VM, which has been
resolved now.
2. A new workround for derby tests which allow useprocess to run test or
else several testcases might fail due to derby lack these tests when
useprocess = false.
3. Derby source code uses the version and the name of java vm to decide what
to do, while current IBM VM has the version of 1.4.2 and the name of j9,
which has different output on the screen from that of standard RI 1.5. At
the same time Derby test compares the output of the iteractive test scripts
to that of expected. I have made some slight modification in its source
code, but I have not throughly change this odd behavior, ...,too much:(

Besides, some testcase fails even on RI. I exclude
a derbynetclientmats test suit since it will hang both RI and Harmony.
Currently all the failure is irrelevant to Harmony. Hope I can find
something in the left.

I have updated the wiki of derby on Hamony:
http://wiki.apache.org/harmony/Apache_Derby.

--
Leo Li
China Software Development Lab, IBM





--
Tony Wu
China Software Development Lab, IBM

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Pavel Pervov]

+1 certainly.

Pavel Pervov,
Enterprise Solutions Software Division.

On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

We're trying something a little different.  I think Roy Fielding one
said something along the lines of when a community gets organized
enough to vote itself out of the Incubator, it's appropriate.

So to bring the Harmony community and the Incubator community together
for this important event in Harmony's life, I'm calling for a vote on
graduating Harmony here on our own -dev list.  The objective is for all
in both the Harmony community and the Incubator community that have an
opinion to vote together, in the same place, and have it hosted by the
Harmony podling.

This is an unconventional way to do this, but I think that it's valid
and could provide one example to the Incubator on how it can work going
forward.

So, without any further ado :

[ ] +1 Graduate Apache Harmony from incubation, and let it petition the
board for Top Level Project status

[ ] 0 No opinion

[ ] -1 No, don't graduate Harmony.  Here's why :


This vote will end 72 hours from now + time of Apache mail outage.  It
will therefore end on Monday, October 23, at 3:30 PM eastern, + delta
for mail outage.

Thanks

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: Harmony passes 94% on derby tests.

[Spark Shen]

Leo Li 写道:

467 Tests Run
94% Pass (443 tests passed)
6% Fail (24 tests failed)
5 Suites skipped

The main progress focuses here:
1. Harmony classlib fails to load class when user-defined security policy
exists. It is due to the sequence of library loading of VM, which has 
been

resolved now.
2. A new workround for derby tests which allow useprocess to run test or
else several testcases might fail due to derby lack these tests when
useprocess = false.
3. Derby source code uses the version and the name of java vm to 
decide what
to do, while current IBM VM has the version of 1.4.2 and the name of 
j9,

which has different output on the screen from that of standard RI 1.5. At
the same time Derby test compares the output of the iteractive test 
scripts

to that of expected. I have made some slight modification in its source
code, but I have not throughly change this odd behavior, ...,too much:(

Besides, some testcase fails even on RI. I exclude
a derbynetclientmats test suit since it will hang both RI and Harmony.
Currently all the failure is irrelevant to Harmony. Hope I can find
something in the left.

I have updated the wiki of derby on Hamony:
http://wiki.apache.org/harmony/Apache_Derby.


Hi Leo:
It's really great!

After reading through your post and several other disscussions on the 
mailing list, I have a feeling that most of the failure are caused by 
the of the test suite itself. Correct me if I am wrong.

Can we improve the test suites themself to lift up the test rate on harmony?

Best regards

--
Spark Shen
China Software Development Lab, IBM

Re: [classlib][test] Configuration dependent test of InetAddress.getHostName

[Andrew Zhang]

On 10/20/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote:


Denis,

Can we consider a patch from
http://issues.apache.org/jira/browse/HARMONY-73 as a fourth option?

Simply speaking, the patch adds a conditional operator which forces API
to returning localhost in this case.



No. I think Harmony does the right thing. We can't force harmony to return
localhost, which should depend on host file.

The evil is the test. I think we'd better revise the test.

Paulex,

This is your patch. What do you think?

With best regards,
Alexei Fedotov,
Intel Java  XML Engineering

-Original Message-
From: Denis Kishenko [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 3:44 PM
To: harmony-dev@incubator.apache.org
Subject: [classlib][test] Configuration dependent test of
InetAddress.getHostName

I have researched issue H-1664 and found one more difference with RI.
I run simple test on Windows Server 2003 SP1

=== Test =
import java.net.InetAddress;
import java.net.UnknownHostException;

public class Test {
public static void main(String[] args) throws UnknownHostException
{
System.out.println(by name (127.0.0.1) -  +
InetAddress.getByName(127.0.0.1).getHostName());
System.out.println(by name (localhost) -  +
InetAddress.getByName(localhost).getHostName());
System.out.println(by address -  +
InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
System.out.println(localhost -  +
InetAddress.getLocalHost());
}

}

Windows Server 2003 SP1
=== RI ==
by name (127.0.0.1) - 127.0.0.1
by name (localhost) - localhost
by address - 127.0.0.1
localhost - nstdrlew21/10.125.122.60

= Harmony ==
by name (127.0.0.1) - nstdrlew21.ins.intel.com
by name (localhost) - localhost
by address - nstdrlew21.ins.intel.com
localhost - nstdrlew21/10.125.122.60

WinXP
= Both ===
by name (127.0.0.1) - localhost
by name (localhost) - localhost
by address - localhost
localhost - pbwdmkishen/10.125.132.226


Actually Harmony use native call of getnameinfo() to get host name
(which is reasonable IMHO). MSDN says The getnameinfo function
provides name resolution from an address to the host name.

InetAddressTest.test_getHostName (see H-1664) failed on WinServer
because InetAddress.getByName(127.0.0.1).getHostName() returned
nstdrlew21.ins.intel.com while localhost expected. So this test
looks like configuration dependent.

I see three possible options
1. Stay test as is. Just keep in mind that on specific configurations
this one fails.
2. Rewrite test to be configuration dependent. Test has to do the same
native call.
3. Exclude localhost checking from test_getHostName.

What do you think about this situation?

--
Denis M. Kishenko
Enterprise Solutions Software 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]





--
Best regards,
Andrew Zhang

Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Evgueni Brevnov]

I think we have several different items/questions to discuss:

1) Is it legal to generate private modifier to a local class?
The Java Language Specification, Third Edition part 14.3 states
snip
It is a compile-time error if a local class declaration contains any
one of the following access modifiers: public, protected, private, or
static.
/snip
So it seems a compiler isn't allowed to put private modifier. Thoughts?

2) getEnclosingClass and isLocalClass doesn't give correct result when
compiled with ECJ. It seems to be a seperate problem but this can
affect the algorithm which determines member accessibility. Seems this
should be resolved first.

3) Elena and I looked at the algorithm which determines member
accessibility and found a problem in it. To resolve the problem we
need to fix getEnclosingClass. So I propose to concentrate on this
method for now.

Evgueni

On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote:

By inner class you mean an automatic/local class in this case; a
class declared inside a method. It would seem appropriate that a local
class is declared private. Only the method that contains the class
declaration can see it.

Do you disagree with what ECJ is generating?

-Nathan

On 10/23/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
 On Sunday 22 October 2006 01:08 Nathan Beyer wrote:
  I haven't had a chance to look at the issue (JIRAs down right now,
  probably part of the infrastructure move), but have you tried
  comparing the actual class files of the problematic class or classes.
 
  I'd suggest compiling the files using ECJ, save them off, compile with
  Sun/BEA/etc, save them off and then run javap from a single JDK on
  each of the class files and compare them for differences.

 Yes, it is quite interesting how different compilers produce different class
 attributes, it looks like this is the main problem with the code. ECJ insists
 on marking inner classes private. Elena was kind to send me another test
 which she wrote while JIRA was down and it shows even a bigger difference
 between the compilers - it produces different output on RI. In the 2nd test
 ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while Sun
 creates Test1931_2$1LocalClass. This gives different output from
 cc.getEnclosingClass and cc.isLocalClass where cc is the used inner class.

 Nevertheless RI allows the access to the inner private class it seems. It
 doesn't throw the exception which drlvm does. The exception source is drlvm's
 kernel class ReflectExporter and the method in question is allowAccess which
 calls allowClassAccess at line 113. This check is the one and the only chance
 to return true in this case.

 I've debugged the code with recently implemented debugging support of drlvm
 using eclipse (jdwp agent has to be build for this from HARMONY-1410, also
 kernel classes for drlvm aren't compiled with debug support, build script has
 to be hacked) but I just don't know all of the access checks specification
 statements to make a decision which one is not correct.

 P.S. I used ecj 3.2 which we use for current classlib compilation.

 --
 Gregory Shimansky, Intel Middleware Products Division

Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Nathan Beyer]

On 10/23/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:

I think we have several different items/questions to discuss:

1) Is it legal to generate private modifier to a local class?
The Java Language Specification, Third Edition part 14.3 states
snip
It is a compile-time error if a local class declaration contains any
one of the following access modifiers: public, protected, private, or
static.
/snip
So it seems a compiler isn't allowed to put private modifier. Thoughts?


This is the part I was commenting, so I put my thoughts here. This is
from the language specification and only applies to Java syntax and
yes, that's an error and it makes sense. But from the class file
(bytecode) perspective, a local class must be defined in its own file
and this class is not accessible by any other class in the package
(not default or package-private scope), so I would think that it
should be marked private.

My reasoning would be that the language spec is saying a class
modifier is illegal for a local class because within the scope of a
method there is no concept or more or less accessible than the method.
Thus, if we promoted this concept to an inner class, it would be
conceptually the same as a private inner class because it would be off
limits from other classes in the same package.

I think what the language specification is say here is much like the
scope identifiers of methods on an interface. If the interface is
public, all methods are public, even if they aren't declared public.



2) getEnclosingClass and isLocalClass doesn't give correct result when
compiled with ECJ. It seems to be a seperate problem but this can
affect the algorithm which determines member accessibility. Seems this
should be resolved first.

3) Elena and I looked at the algorithm which determines member
accessibility and found a problem in it. To resolve the problem we
need to fix getEnclosingClass. So I propose to concentrate on this
method for now.

Evgueni

On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote:
 By inner class you mean an automatic/local class in this case; a
 class declared inside a method. It would seem appropriate that a local
 class is declared private. Only the method that contains the class
 declaration can see it.

 Do you disagree with what ECJ is generating?

 -Nathan

 On 10/23/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
  On Sunday 22 October 2006 01:08 Nathan Beyer wrote:
   I haven't had a chance to look at the issue (JIRAs down right now,
   probably part of the infrastructure move), but have you tried
   comparing the actual class files of the problematic class or classes.
  
   I'd suggest compiling the files using ECJ, save them off, compile with
   Sun/BEA/etc, save them off and then run javap from a single JDK on
   each of the class files and compare them for differences.
 
  Yes, it is quite interesting how different compilers produce different class
  attributes, it looks like this is the main problem with the code. ECJ 
insists
  on marking inner classes private. Elena was kind to send me another test
  which she wrote while JIRA was down and it shows even a bigger difference
  between the compilers - it produces different output on RI. In the 2nd test
  ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while Sun
  creates Test1931_2$1LocalClass. This gives different output from
  cc.getEnclosingClass and cc.isLocalClass where cc is the used inner class.
 
  Nevertheless RI allows the access to the inner private class it seems. It
  doesn't throw the exception which drlvm does. The exception source is 
drlvm's
  kernel class ReflectExporter and the method in question is allowAccess which
  calls allowClassAccess at line 113. This check is the one and the only 
chance
  to return true in this case.
 
  I've debugged the code with recently implemented debugging support of drlvm
  using eclipse (jdwp agent has to be build for this from HARMONY-1410, also
  kernel classes for drlvm aren't compiled with debug support, build script 
has
  to be hacked) but I just don't know all of the access checks specification
  statements to make a decision which one is not correct.
 
  P.S. I used ecj 3.2 which we use for current classlib compilation.
 
  --
  Gregory Shimansky, Intel Middleware Products Division
 

Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Elena Semukhina]

On 10/24/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:


I think we have several different items/questions to discuss:

1) Is it legal to generate private modifier to a local class?
The Java Language Specification, Third Edition part 14.3 states
snip
It is a compile-time error if a local class declaration contains any
one of the following access modifiers: public, protected, private, or
static.
/snip
So it seems a compiler isn't allowed to put private modifier. Thoughts?



The spec says about class declaration but not compiled class modifiers.
Sun's compiler provides the public modifier for a local class while ECJ
sets it to private, which seems more appropriate.

2) getEnclosingClass and isLocalClass doesn't give correct result when

compiled with ECJ. It seems to be a seperate problem but this can
affect the algorithm which determines member accessibility. Seems this
should be resolved first.

3) Elena and I looked at the algorithm which determines member
accessibility and found a problem in it. To resolve the problem we
need to fix getEnclosingClass. So I propose to concentrate on this
method for now.

Evgueni

On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote:
 By inner class you mean an automatic/local class in this case; a
 class declared inside a method. It would seem appropriate that a local
 class is declared private. Only the method that contains the class
 declaration can see it.

 Do you disagree with what ECJ is generating?

 -Nathan

 On 10/23/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
  On Sunday 22 October 2006 01:08 Nathan Beyer wrote:
   I haven't had a chance to look at the issue (JIRAs down right now,
   probably part of the infrastructure move), but have you tried
   comparing the actual class files of the problematic class or
classes.
  
   I'd suggest compiling the files using ECJ, save them off, compile
with
   Sun/BEA/etc, save them off and then run javap from a single JDK on
   each of the class files and compare them for differences.
 
  Yes, it is quite interesting how different compilers produce different
class
  attributes, it looks like this is the main problem with the code. ECJ
insists
  on marking inner classes private. Elena was kind to send me another
test
  which she wrote while JIRA was down and it shows even a bigger
difference
  between the compilers - it produces different output on RI. In the 2nd
test
  ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while
Sun
  creates Test1931_2$1LocalClass. This gives different output from
  cc.getEnclosingClass and cc.isLocalClass where cc is the used inner
class.
 
  Nevertheless RI allows the access to the inner private class it seems.
It
  doesn't throw the exception which drlvm does. The exception source is
drlvm's
  kernel class ReflectExporter and the method in question is allowAccess
which
  calls allowClassAccess at line 113. This check is the one and the only
chance
  to return true in this case.
 
  I've debugged the code with recently implemented debugging support of
drlvm
  using eclipse (jdwp agent has to be build for this from HARMONY-1410,
also
  kernel classes for drlvm aren't compiled with debug support, build
script has
  to be hacked) but I just don't know all of the access checks
specification
  statements to make a decision which one is not correct.
 
  P.S. I used ecj 3.2 which we use for current classlib compilation.
 
  --
  Gregory Shimansky, Intel Middleware Products Division
 






--
Thanks,
Elena