Junilu Lacar wrote:Looks like a good start. I can see this having a following. Are you going to add the various social network buttons to allow sharing? You'll need to do a lot of incremental refinements if/as this site takes off.
Kathleen Angeles wrote:check samsung website. they have from galaxy mini to the glorious galaxy note.
Martin Vajsar wrote:I still strongly prefer ArrayList over Vector.
Firstly, Collections.synchronizedList(new ArrayList()); does not look like an unreasonable amount of effort to me.
Secondly, when someone spots this construction, it is immediately clear the ArrayList is intentionally synchronized and is therefore going to be used by multiple threads. If I used a Vector instead, the developer to come after me might not know for sure whether I had a bout of nostalgia, or I really use Vector just to get synchronized access.
For me, Vector equals legacy code.
Jon Skeet wrote:
Vector synchronizes on each individual operation. That's almost never what you want to do.
Generally you want to synchronize a whole sequence of operations. Synchronizing individual operations is both less safe (if you iterate over a Vector, for instance, you still need to take out a lock to avoid anyone else changing the collection at the same time) but also slower (why take out a lock repeatedly when once will be enough)?
Of course, it also has the overhead of locking even when you don't need to.
Basically, it's a very flawed approach to synchronization in most situations. As MrSpandex pointed out, you can decorate a collection using the calls such as Collections.synchronizedList - the fact that Vector combines both the "resized array" collection implementation with the "synchronize every operation" bit is another example of poor design; the decoration approach gives cleaner separation of concerns.
As for a Stack equivalent - I'd look at Deque/ArrayDeque to start with.
Derik Davenport wrote:
And why can't you package them inside the Jar? Is it due to licensing restrictions?
That sounds promising. How would I go about doing that exactly? Sorry if that sounds extremely noobish. I focused more on the details of how Java worked and less on the details of distribution until just recently.
As I understand it, a Jar file is just a zip file with some extra bits (like a manifest file). These extra bits are used to tell the JVM which class to open up to find Main (among other things). So I would probably have to make up the manifest manually. Then I would need some kind of "archival tool" to create the Java ARchive. Is that all there is to it?
Derik Davenport wrote: I can't distribute the JAR by itself, I will be missing the swing and JNA libraries that the application depends on (but which are not part of the JVM).
Darryl Burke wrote:Rishi and chaitanya, both of you might do well to read the API for Class#getConstructors()
Returns an array containing Constructor objects reflecting all the public constructors of the class represented by this Class object.