> -----Original Message-----
> From: Tim Ellison [mailto:[EMAIL PROTECTED]
> 
> Nathan Beyer wrote:
> > I've been working with the java.util.concurrent code to see what we'd
> need
> > to have in place to get this code to be a part of Harmony.
> >
> >
> >
> > System.nanoTime() - A number of the classes rely on the new nanoTime
> method.
> > I'm assuming this would just be marked as a native method like
> > currentTimeMillis in luni-kernel, which would leave it up to the VMs
> > implement. I can easily stub out the Java code. Anyone interested in
> getting
> > our VMs to implement this method? I'm guessing that if IBM donates an
> > updated VME for 1.5 usage, this would also be provided.maybe?
> 
> It's in the Harmony port library as:
>   U_64 VMCALL hytime_hires_clock (struct HyPortLibrary *portLibrary)
> 
> [1]
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc
> /vm_doc/html/hytime_8c.html?view=co


Does this mean we can stub out the luni-kernel System and just get the VMs
to implement it in their kernel classes using this method?

> 
> 
> > Annotations - There are a few places where the @SuppressWarnings
> annotation
> > is used. Building the annotations themselves is trivial, but we'll
> actually
> > need to be using Java 5 class files to properly compile annotation class
> > files. These can be commented out until the 5 class file support is
> enabled.
> 
> Sounds like all Harmony-oriented VMs are happy for us to move to the 1.5
> compiler, even if getting the runtime annotation info may not be there
> yet.
> 
> > PriorityQueue - There's at least one dependency on this class. I think
> > someone is already working on this one though.
> >
> >
> >
> > VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a
> > VM-specific API for atomic gets and sets. This API will need to be
> defined
> > and then implemented by the various VMs. Many of the lock APIs also make
> use
> > of this API.
> 
> Do these have to be VM-specific?
> 
> > Arrays.copyOf() - Several classes utilize a set of Arrays.copyOf()
> methods,
> > which are new in Java SE 6 [1]. We'd either have to rework these
> > implementations to use System.arraycopy or just implement the new
> methods.
> >
> >
> >
> > AbstractMap.SimpleEntry<K,V> - The ConcurrentHashMap uses this class as
> a
> > base class for Map.Entry objects. This is a new public class, which is
> also
> > part of Java SE 6 [2]. Either this code can be reworked to just
> implement
> > the Map.Entry interface, or the SimpleEntry class can be built out,
> which
> > should be trivial.
> 
> Strange that there are 6.0 dependencies.  Is there a j.u.concurrent
> maintenance stream we can track rather than the dev stream?
> 
> Regards,
> Tim
> 
> 
> > Thoughts, comments, questions?
> >
> >
> >
> > [1] http://java.sun.com/javase/6/docs/api/java/util/Arrays.html
> >
> > [2]
> >
> http://java.sun.com/javase/6/docs/api/java/util/AbstractMap.SimpleEntry.ht
> ml
> >
> >
> 
> --
> 
> Tim Ellison ([EMAIL PROTECTED])
> IBM Java technology centre, UK.
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to