I bought it because I thought it would be very easy to deploy java code to it. I found out the opposite... it was hard to deploy java code to it. j2me is a tricky beast in my eyes... especially when there are multiple flavors of the release multiplied by the multiple flavors of the device.
I also bought it because I got duped because of the marketing hype at Java One. The people at JavaOne were essentially the guinea pigs for this product.
I learned a lesson... and next time, I will not spend my money so easily like I did then.
The keyboard is something I don't want to type on all day, so word processing, note taking and coding is out. I was misled by the java support... I was disappointed (it's a real big pain in the ass to get java code running on this thing). The processor is not fast enough for games... so gaming is out. The only thing I could use it for was packet sniffing... which is not illegal. And even that didn't work too well. I want my $350 back.
I was at Java One in 2002 and got sucked into buying one of these things. I haven't used it since. I did some wardriving with its wireless card and Kismet, but found that the wireless card was unstable... and I would have to reboot Kismet every 5 minutes. Thus, the wardriving option was out. After that, I never found a good use for it. I would prefer a full fledged laptop compared to something marginally functional as this.
StringBuffer.toString() has an issue where a StringBuffer is used to build out a new string. This new StringBuffer is the default 16 byte StringBuffer. When large StringBuffer's are.toString()'d, zillions of StringBuffer's are created in the process because of this ultra small 16 byte issue.
I think Generics is going to be a really nice long awaited feature. I am wondering if this type of change is going to require a modification to the bytecode specification. If that is the case, then new code bytecodes will not work with older bytecodes. Does anyone think that Sun can pull this feature off without a change to the bytecode spec? Would this be major compiler change?
Another Query Language
on
Java Data Objects
·
· Score: 1, Informative
I am concerned about learning another query language. Each has its limitations and that is why I was slow to adopt EJB-QL. EJB-QL is odd to learn and still not as feature rich as pure SQL. Now there's JDO-QL... yet another query language to learn.
I found that in my previous projects, it is not that bad to embed SQL into DAO objects. You have complete power and control that way. You don't have to learn another QL, and you have the benefits of SQL.
Slashdot Mirror
I bought it because I thought it would be very easy to deploy java code to it. I found out the opposite... it was hard to deploy java code to it. j2me is a tricky beast in my eyes... especially when there are multiple flavors of the release multiplied by the multiple flavors of the device. I also bought it because I got duped because of the marketing hype at Java One. The people at JavaOne were essentially the guinea pigs for this product. I learned a lesson... and next time, I will not spend my money so easily like I did then.
The keyboard is something I don't want to type on all day, so word processing, note taking and coding is out. I was misled by the java support... I was disappointed (it's a real big pain in the ass to get java code running on this thing). The processor is not fast enough for games... so gaming is out. The only thing I could use it for was packet sniffing ... which is not illegal. And even that didn't work too well. I want my $350 back.
I was at Java One in 2002 and got sucked into buying one of these things. I haven't used it since. I did some wardriving with its wireless card and Kismet, but found that the wireless card was unstable... and I would have to reboot Kismet every 5 minutes. Thus, the wardriving option was out. After that, I never found a good use for it. I would prefer a full fledged laptop compared to something marginally functional as this.
StringBuffer.toString() has an issue where a StringBuffer is used to build out a new string. This new StringBuffer is the default 16 byte StringBuffer. When large StringBuffer's are .toString()'d, zillions of StringBuffer's are created in the process because of this ultra small 16 byte issue.
I think Generics is going to be a really nice long awaited feature. I am wondering if this type of change is going to require a modification to the bytecode specification. If that is the case, then new code bytecodes will not work with older bytecodes. Does anyone think that Sun can pull this feature off without a change to the bytecode spec? Would this be major compiler change?
I am concerned about learning another query language. Each has its limitations and that is why I was slow to adopt EJB-QL. EJB-QL is odd to learn and still not as feature rich as pure SQL. Now there's JDO-QL... yet another query language to learn. I found that in my previous projects, it is not that bad to embed SQL into DAO objects. You have complete power and control that way. You don't have to learn another QL, and you have the benefits of SQL.