Dalibor Topic wrote: > On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote: >> Mikhail Loenko wrote: >>> The problem is Base64 functionality is unavailable through the >>> standard API, so people have a choice either use unportable sun.*, >>> o.a.h.*, etc or create the coder from scratch >> Understood, I think people are 'driven' to using the non-API types >> though necessity rather than doing so by mistake. > > Hardly. Many replacements for Base64 exists, for example GNU Classpath > recommends using Apache Commons Codec for projects compatible with the > Apache license. > > Amateur developers use non-standard classes because they are too lazy > to think for themselves, and accordingly copy broken code around projects. > Alas, a language designed to appeal to the masses naturally attracts a > lot of people who'd have trouble producing portable code in any programming > language. :)
I was being charitable. For sure many such usages can be easily avoided, but in other cases no so easily; like CharToByteConverter would require duplicating a wad of data, and I don't know of any third-party impl. of Unsafe. We should appeal to app developers to change implementation dependent code (even provide a recipe book of recommended solutions), but be pragmatic about the need to run the current version. In many cases it may be beyond the apps immediate sphere of influence (i.e. dependent libraries). If everyone responded as quickly and effectively as Martin we would have no worries. > On a side note, I seem to recall reading on Sun's javac engineer's blog > that javac won't allow access to sun internal classes sooner or later, > so idiot-proofing class libraries may not be very useful, anyway, > as people will have to rewrite such code, or preferrably, throw it away. It will be interesting to see what havoc is unleashed by attempts to reduce the visibility of sun internal packages by the compiler and at runtime. Regards, Tim -- 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]
