• Post Reply Bookmark Topic Watch Topic
  • New Topic

java.util.Collections  RSS feed

 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Trying to get a multi-threaded program concepted that opens as much as half the open file handles the underlying os will allow.

This pretty much limits us to use of Collections to run efficiently. Today in test run I drilled down to

fetter is just some name I came up with that is not likely to be in computer science lingo.

I eagerly dove into Collections.java to find SynchronizedMap, and those of you with Phd's may laugh at me now, My Day In Shame has come, once again.

Most of these collections are interfaces, which cannot be instantiated.

Trying to figure out how to do this is really slow-going and prone to extensive re-writes over previously written code that was used as instructed from documentation.

I need the collection to be *very* robust; I do not mind coding 1,000 lines to get the whole of the object right there where I can see it in my source files.

suggestons ?
 
Purushoth Thambu
Ranch Hand
Posts: 425
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You haven't explained what you are looking for apart from robust collection.
- What is collections used for in your code (What objects are stored)
- Which collection you app is using currently
- What problem are you facing

By the way if you are looking for collections source code you can find them in src.zip file in the jdk home directory.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you show us what it is you're doing at WordCount.java line 521? And maybe some additional lines around that area, for context.

[Nicholas]: I do not mind coding 1,000 lines to get the whole of the object right there where I can see it in my source files.

Ummm... OK. That seems a bit suspicious to me, as I strongly favor keeping classes small and simple wherever possible, and making a class longer is not in general any guarantee of robustness. Often it can lead to the opposite effect.

Also, I would note that it's pretty rare in my experience that the alleged "thread safety" you get from Collections.synchronizedXXX(), or from Vector and Hashmap, is good enough to actually make your code thread-safe. Typiclly there are places where you need to prevent other threads from cutting in in between two different synchoronized method invocations - this means you need additional synchronization outside the methods themselves. And if you're going to do that, why bother using synchronizedXXX() at all? It just confuses the issue by putting some synchronization inside the XXX class, while other synchonization is in the clas that uses the XXX. Feh. Just put it all in the class that uses it. Many, many bugs have been committed by people relying on the false promise of "thread safety" from synchronizedXXX() etc.
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Purushothaman Thambu:
You haven't explained what you are looking for apart from robust collection.
- What is collections used for in your code (What objects are stored)
- Which collection you app is using currently
- What problem are you facing

By the way if you are looking for collections source code you can find them in src.zip file in the jdk home directory.


what you are looking for -> this reveals a weakness in my thinking, most of the machines I get to use are older and clumsy. I hear horror stories. (few, but Collections.java suggests this fear is not totally unfounded.) I am still strengthening my coding skills. The exact failure was isolated by me last night: The cast to java.util.TreeMap as suggested in Collections.java threw a cast exception,... I took out the cast and the compiler seemed even more verbose about my (coding skills)

I then just took out the entire synchronized collection stuff and made a conventional constructor call - it worked, I drillled down to my next layer.

The TreeMap had actually added a few words from Alice in Wonderland and blew out on a key compare (Class Cast Exception) I then recoded and turned the machine off, I can bring a stack-trace.

- What is collections used for in your code (What objects are stored)

Words and word freqs from sample documents, I directly adapted code from David Eck's online tutorial WordCount

More than one doc will be examined, and techniques from A.I. will look for harmonics the human eye cannot detect.

- Which collection you app is using currently

I am tryng different Collections, evolving my thinking along code development as cut-and-try is powerful bench-prototyping tool; well proven in practical engineering.

- What problem are you facing

The coding challenge is to automate keyword searches in multiple documents, I decided on my own to build dictionaries from samples dropped in another folder besides where the inspected documents go.

Much of the challenge is as discussed by the next poster.
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
Can you show us what it is you're doing at WordCount.java line 521?

classes small and simple wherever possible, and making a class longer is not in general any guarantee of robustness
(snipped)......


That's been my experience, (in coding generally) and why I posted to expert fora, solution n to 0'th problem n tends to recast the problem in different shades - wanted to avoid losing traction, the beginner approach.
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
Can you show us what it is you're doing at WordCount.java line 521? And maybe some additional lines around that area, for context.
Ummm... OK. That seems a bit suspicious to me, as I strongly favor keeping classes small and simple wherever possible, and making a class longer is not in general any guarantee of robustness. Often it can lead to the opposite effect.

Also, I would note that it's pretty rare in my experience that the alleged "thread safety" you get from Collections.synchronizedXXX(), or from Vector and Hashmap, is good enough to actually make your code thread-safe. Typiclly there are places where you need to prevent other threads from cutting in in between two different synchoronized method invocations - this means you need additional synchronization outside the methods themselves. And if you're going to do that, why bother using synchronizedXXX() at all? It just confuses the issue by putting some synchronization inside the XXX class, while other synchonization is in the clas that uses the XXX. Feh. Just put it all in the class that uses it. Many, many bugs have been committed by people relying on the false promise of "thread safety" from synchronizedXXX() etc.

I sat down to do as asked, and inadvertantly fixed the program. The original question was fixed by:

The outut:

Had parsed:
*****The Project Gutenberg Etext of Alice In Wonderland*****
doing a word count.
I think because this is a Phd grade fourae, I will explain my original basis.

I met a Masters in EE candidate recently, who would not think of going online except slipping under protocols to show up on a server from a Baltic state, we had *very* productive discussion of exactly the issuses I find salient.

I cannot do much about that type of (...???...) who may in fact already be on the inside.

I can, with great effort, de-alias the stochastic failures of authorized users from screwdriver and siphon-hose attacks of wannabes.

This requires adroit quick stepping - see my mission statement for a verbose discussion of this issue:Mission Statement
That is what I meant by robust. I cannot "just confuse the issue" by working beyond my skill level with tools I did not write.

BTW: the zipped sources show up as 33.6 kb in WinZip; I concur than classes that are small and simple wherever possible, and making a class longer is not in general any guarantee of robustness.
So far, they shrink dramaticlly when I figure out how to do what it is I am trying to do.

Did you know that Boost is an alias for Booze ?
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!