Keep in mind that there are 3 sets of sources for npt, share/npt, solaris/npt and windows/npt it is quite platform specific, using iconv libraries on solaris/linux, and multi/wide byte strangeness on windows.
So it wasn't just the functionality that drove it into it's own library, the implementation of how you have to deal with utf8 in a native world made it ugly, and isolating it was the only way to put lipstick on this pig. You need to look at all the code before you start doing cut&paste on the source. -kto On Apr 6, 2014, at 11:16 AM, Staffan Larsen wrote: > It makes sense to have this code separated out. But I’m not sure it makes > sense to compile it into a separate library. We could just as well compile in > the necessary source files where needed. And if there are unused functions, I > think they could be removed to decrease the maintenance burden. > > /Staffan > > On 4 apr 2014, at 18:28, Dmitry Samersoff <dmitry.samers...@oracle.com> wrote: > >> Hi Everybody, >> >> We have an libnpt.so[1] in JDK. This library contains bunch of UTF >> related functions. On a brief investigation it looks like most of these >> functions are not used. Six functions below called one time each from >> share/back/* and hprof_init.c [2] >> >> Should I file a CR to have it cleaned up - remove npt library as a >> separate entity and move few utf functions that really used to place >> where it actually called. >> >> >> [1] Library sources location >> >> src/share/npt >> src/solaris/npt >> src/windows/npt >> >> [2] Library usage >> >> src/share/back/transport.c: >> >> utf8FromPlatform >> utf8ToPlatform >> >> src/share/back/inStream.c: >> >> utf8sToUtf8m >> utf8sToUtf8mLength >> >> src/share/back/outStream.c: >> >> utf8mToUtf8s >> utf8mToUtf8sLength >> >> >> src/share/demo/jvmti/hprof/hprof_init.c >> >> utf8ToPlatform >> >> >> -Dmitry >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. >
