Unsynchronized classes

[GoogleCodeExporter]

Many parts of the CN1 API still uses Vector, Hashtable, and StringBuffer rather 
than ArrayList, Vector, and StringBuilder.  In most cases this is unnecessary 
as far as thread-safety goes and it imposes an unnecessary performance hit.  
Further, now that iOS8 will require us to throttle thread wake calls, there is 
an added cost to using monitors when they are not necessary.  I propose that we 
change most or all of these instances with their unsynchronized equivalents.

Further, there are many stream readers and writer whose methods are 
synchronized, and we use them because they are all we have - but in most cases 
we don't need thread-safety in those cases either.  I propose adding a set of 
unsynchronized equivalents to Codename One and then update other parts of the 
API to use these new classes instead of the old synchronized ones.  

What do you think?

Original issue reported on code.google.com by steve.ha...@codenameone.com on 28 Jan 2015 at 10:58

[GoogleCodeExporter]

Note:  I'm still doing some experimentation to see if eliminating synchronized 
sections has any effect on the wake limit.  Issue 1304 only includes a few 
hundred calls to notify() or notifyAll() and still causes it to trip over the 
150/sec limit.  So there are thread wakeups coming en masse from an alternate 
source.

Original comment by steve.ha...@codenameone.com on 28 Jan 2015 at 11:16

[GoogleCodeExporter]

Original comment by steve.ha...@codenameone.com on 30 Jan 2015 at 7:56

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Since the NewVM is concurrent, this may become a non-issue.  The iOS limit 
looks like it was a red herring now.  Closing.

Original comment by st...@weblite.ca on 4 Feb 2015 at 5:02

• Changed state: WontFix