[classlib][portlib] Should lock386.c be in the thread library?

2010-07-06 Thread Oliver Deakin
Hi all, Currently it appears that on Windows the files under modules\portlib\src\main\native\common\windows are built into hycommon.lib, but as far as I can see they are only used by modules\portlib\src\main\native\thread\windows\thrdsup.c. I think it makes sense to move these files from

Re: svn commit: r960424 - /harmony/enhanced/java/trunk/classlib/modules/luni/src/main/java/java/io/File.java

2010-07-06 Thread Mark Hindess
Regis, This breaks the build for the IBM VME (from developerWorks). Since they don't have a sun.misc.Unsafe, so the AtomicInteger can't be resolved. Any ideas how to fix this? Also, the luni.jar manifest says: java.util.concurrent;resolution:=optional, I wonder when it becomes

Re: svn commit: r960424 - /harmony/enhanced/java/trunk/classlib/modules/luni/src/main/java/java/io/File.java

2010-07-06 Thread Jesse Wilson
On Sun, Jul 4, 2010 at 8:05 PM, regi...@apache.org wrote: File.counter could be accessed by multiple threads, so use AtomicInteger to make sure each thread using different int value to create temp file. Is this a sufficient fix for the problem? The file system may be shared by multiple

Re: svn commit: r960424 - /harmony/enhanced/java/trunk/classlib/modules/luni/src/main/java/java/io/File.java

2010-07-06 Thread Tim Ellison
On 06/Jul/2010 14:56, Mark Hindess wrote: Regis, This breaks the build for the IBM VME (from developerWorks). Since they don't have a sun.misc.Unsafe, so the AtomicInteger can't be resolved. Any ideas how to fix this? Also, the luni.jar manifest says:

Re: svn commit: r960424 - /harmony/enhanced/java/trunk/classlib/modules/luni/src/main/java/java/io/File.java

2010-07-06 Thread Mark Hindess
In message 4c333db6.1000...@gmail.com, Tim Ellison writes: On 06/Jul/2010 14:56, Mark Hindess wrote: Regis, This breaks the build for the IBM VME (from developerWorks). Since they don't have a sun.misc.Unsafe, so the AtomicInteger can't be resolved. Any ideas how to fix this?

Re: About JDB's expression calculation

2010-07-06 Thread Regis
On 2010-07-05 21:28, Daniel Gong wrote: Back to this question, I still do not find a proper solution. I think expressions like object.method() can only be evaluated at the debuggee side, because the debugger does not have enough information to evaluate it. Then, if this kind of expression can

Re: svn commit: r960424 - /harmony/enhanced/java/trunk/classlib/modules/luni/src/main/java/java/io/File.java

2010-07-06 Thread Regis
On 2010-07-06 21:56, Mark Hindess wrote: Regis, This breaks the build for the IBM VME (from developerWorks). Since they don't have a sun.misc.Unsafe, so the AtomicInteger can't be resolved. Any ideas how to fix this? Also, the luni.jar manifest says:

Re: svn commit: r960424 - /harmony/enhanced/java/trunk/classlib/modules/luni/src/main/java/java/io/File.java

2010-07-06 Thread Regis
On 2010-07-06 22:49, Jesse Wilson wrote: On Sun, Jul 4, 2010 at 8:05 PM,regi...@apache.org wrote: File.counter could be accessed by multiple threads, so use AtomicInteger to make sure each thread using different int value to create temp file. Is this a sufficient fix for the problem? The