Skip to Main Content
Forums

Java APIs

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Generic solution

843793Jun 27 2002 — edited Jul 29 2002
If I template a class it will replace the interface of that class such that I dont have to cast what goes in and out of the class anymore because the new class will accept the true object type in the raw. This is not the same as wrapping the class because a wrapped class just has its casts on the inside. Generics MUST eliminate all typecasting.

Collections will have to be written from the bottom up as template classes which will have to be essentially abstract because they can not be compiled without knowing what types of objects to use.

This should speed up code and make it more safe by removing all of the typecasting.

But my question is now what is the contract or relationship between my templated class and the class it was templated from? The template class of course will never exist as a .class file.

Technically wouldnt a generic generation tool be more appropriate? Like we have the IDL tool? Make generic classes a .gen file and make them require processing through another tool that will simply generate java source code in a consistent fashion. Since this is all compile time, this would be a perfect solution especially since the debugger would be able to step through the source and the class cleanly.

I think this has to be better and the least invasive of the options. letting people create and manage their own generic classes and also sun can supply generic collections too.

advantages.

1. no javac changes.
2. no JVM changes.
3. no changes to appearance of source code for developers who review code they didnt write.
4. The generic class is there and ready to generate new .java files at your discretion.
5. Completely optional. a user does not even have to know they exist.

Anyone have a problem with this? Did I miss the point?

Comments

Yoda-Oracle

Hi,

Your Zone now has 16GB of RAM. Please let me know if that is sufficient

-Angelo

1336415

Thank you. Now memory limit is sufficient.

But CPU offloading still shows that while DAX doing its work - CPU core busy too.

With new memory limit vector_in_range() takes 0,8 seconds to complete. Let's run it in cycle on the same thread id with "yes > /dev/null" (using pbind). Again, we see that yes shares CPU time with dax-in-range:

   PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWP  

19860 dglushe* 99 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0  30 34K   0 yes/1

19868 dglushe* 99 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0  30 34K   0 yes/1

19864 dglushe* 99 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0  30 34K   0 yes/1

19866 dglushe* 99 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0  30 34K   0 yes/1

19857 dglushe* 99 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0  30 34K   0 yes/1

19862 dglushe* 99 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0  30 34K   0 yes/1

19870 dglushe* 99 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0  30 34K   0 yes/1

19880 dglushe* 50  15 0.1 0.0 0.0 0.0 0.0  35   1  23 .1M 0 dax-in-range/1

19850 dglushe*  34 0.3 0.0 0.0 0.0 0.0 0.0  65 0  24 10K   0 yes/1

1336415
Answer

Oh, I see you shared dax.h. It seems that vector.so uses synchronous DAX calls, but dax.h states that there are asynchronous calls too:

/* 


    NAME: dax_post - family of functions that post asynchronous dax requests


    SYNOPSIS:


  */


..







dax_status_t dax_scan_range_post(dax_queue_t *queue, uint64_t flags,





    dax_vec_t *src, dax_vec_t *dst, dax_compare_t op, dax_int_t *lower,





    dax_int_t *upper, void *udata);


No more questions, thank you!

Marked as Answer by 1336415 · Sep 27 2020
1 - 3
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Aug 26 2002
Added on Jun 27 2002
#generics
31 comments
285 views