aspose file tools*
The moose likes Java in General and the fly likes Modifiying collection elements Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Modifiying collection elements" Watch "Modifiying collection elements" New topic
Author

Modifiying collection elements

Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
When originally concepting my main class, I wrote data items to a file as a means of passing collections of data between one operation and another operation. Repeatedly, I have failed to workaround or fix this problem. The disk heads are too slow for passing several thousand data items around, and here, in my attempt to get the data passed as a collection, I run again into the same problem:

The code in the get operations demands an object. Objects are, generally, unmodifiable. (in this case, the Integer class) I will gladly write a class, which can be placed in the Map, TreeMap, ArrayList or other Collection, if that will solve the "Objects are unmodifiable" paradigm. The design thusfar has placed instances in a Hashtable (because I can understand it's operation)

Generally, the design will create a Vector of objects - do some work on the objects - then pass the results to the next phase of the main() method. In main, I stay on top of things and the word control comes to mind as a descriptive for what main (in my program) is and does. For the view, I have decided on a Graphics of some kind, what Graphics exactly will be used I am concepting right now. Modeling classes are written with enough depth that I can effectively continue work on the core of my program, which will likely effect a tensor class ~ which work is beyond my skills and I would really like to get this earlier design hole (that I patched by using files to transfer datasets as they are developed from one building phase to the next) fixed.

I want to note for posters from the get-go that I have worked through the "pass by value" question many times, and "new" -ing again and again several thuosand times strikes me as likely to ball up the machine. The original data   is   read-only, then after that one op() produces a feed to the next op() there being five or ten operations anticipated. We then generate a report (by File) and abandon the interim data in RAM.

Suggestions needed.


"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18717
    
  40

Don't worry about creating new Integer objects just to fetch the values from the map. The autoboxing mechanism should cache it for you, in the range that you are using (0 to 20). And even if it didn't the garbage collector should keep up.

I suggest you first get your program to compile, and working. Then you can look at techniques for mitigating object creations.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
I'm having a hard time understanding what the question here is. The code you've provided doesn't compile, for several different reasons - none of which seem to have anything to do with object mutability. Nor do I see you attempting to do anything that has much to do with object mutability - other than putting objects into a TreeMap, which is of course modifiable. But I don't understand the "here, I give up" comment on the get() method, which appears to have nothing to do with mutability.

I really think it would help clarify matters if you showed code that can actually compile. Or if you can't get it to compile, ask about the compilation errors. And if it has problems at runtime, are they the problems you're asking about, or something unrelated? Right now there seems to be a big gap between what the code is doing (or trying to do) and what you're asking about, and I'm not sure where to begin.

But ignoring the code...

[NJ]: Objects are, generally, unmodifiable. (in this case, the Integer class)

Well, the Integer class is unmodifiable. Plenty of other classes are not unmodifiable. It's certainly not true in general.

[NJ]: I will gladly write a class, which can be placed in the Map, TreeMap, ArrayList or other Collection, if that will solve the "Objects are unmodifiable" paradigm.

It's pretty easy to write a modifiable class. Give it some non-final instance fields and give it some setter methods, e.g.

Now I have no idea how close that is to what you need, because I really don't understand what you're trying to do, but that's a mutable class. Objects of class Foo can be modified.

Does that help any?


"I'm not back." - Bill Harding, Twister
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
Originally posted by Henry Wong:
Don't worry about creating new Integer objects just to fetch the values from the map. The autoboxing mechanism should cache it for you, in the range that you are using (0 to 20). And even if it didn't the garbage collector should keep up.

I grossly oversimplified the code, what I did was while trying to write the actual implementation of code I would be using in the finished work, I gave up in desperation. A simple glance at the code likely reveals several areas that will draw fire.

As for G.C., I have begun to accept that if I, ahem, scope-out .... by which I mean to say do some work in a function call or following the pattern:

which can be dug out of by issuing returns, it will not leave any object references as the call-chain is dug out of during the unwinding phase, thereby making the object available to gc. In general, a complex object is paired up with a thread and that "thread of execution" does some work. The result of that work is passed to the next operation. Consider the idea of a Christmas Shopper: There would be goals, prices, cards, many values can be discovered and it is difficult for me to give concise, definitive sets of qualities and characteristics that I will discover as needing to be implemented. Generally, I have firmly decided that I will be forced to use ai to get the program to run in an effective manner.

This design decision is consequent to the theory of constraints that I have evolved after earlier work here at jr with you folks.

I have come to accept the efficacy of Java G.C. after trying out some apps which heavily load the G.C. - it is acceptable for program design goals (plus it already works ! )

[Henry:] I suggest you first get your program to compile, and working.
I did, it did. I am coming back for more. The code posted was intended to isolate the question, and may not be effective. The program compiles and runs, the badly coded sample may not.

[Henry:] Then you can look at techniques for mitigating object creations.So far, I have decided to do everything within a { }, and do not leave any "route of escape" nor thread crossings or that sort of thing. Some complexities may develop after I get a base harness working better and some resonable testing done on it.

Here, remaining from the last round of discussions:

which is lines 336-340, largely unchanged from previous discussions back in Nov-Dec - this code being a direct solution to the challenge described in the post title.

Bascially, no progress on that challenge as of posting today.

It may be that reducing the impact of object creations may be managable by the technique I describe, my question is how to pass a collection, en masse, to the next phase of the program without invoking a file object.
[ July 01, 2007: Message edited by: Nicholas Jordan ]
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
[JY:]I'm having a hard time understanding what the question here is.
Very simple, not our usual go-round: Pass a Collection of objects from one phase of the program to the next. All other issues - if any, in the post - may be addressed separately. Will gladly repost if needed.

[JY:]The code you've provided doesn't compile, for several different reasons - none of which seem to have anything to do with object mutability.
That was my first attempt, earlier work was criticised for violation OO principles and I was not prepare to hold my ground effectively. I have made some progress, my original design remains effective for my purposes. None of the defects in the code have anything to do with passing a Collection (I think) To restrain the discussion, I suggest we isolate issues narrowly involving passing a Collection around to the exclusion of other issues. They were put in the post in an attempt to thwart design blunders.


[JY:]Nor do I see you attempting to do anything that has much to do with object mutability - other than putting objects into a TreeMap, which is of course modifiable.
It should be, based on my progress so far, that the elements of the TreeMap may be modified, but one may not add/remove. There is discussion of Iterators here, and it may be relevant. The general case, the purpose of the post is iterator.getNext() / modifiy or work on that data item / put it back in the map.

When done with op-(n) on Collection-(n), pass it along.

That is the intended question of the post....

[JY:]I really think it would help clarify matters if you showed code that can actually compile. Or if you can't get it to compile, ask about the compilation errors. And if it has problems at runtime, are they the problems you're asking about, or something unrelated? Right now there seems to be a big gap between what the code is doing (or trying to do) and what you're asking about, and I'm not sure where to begin.

I tried that earler, but got bombarded for writing thousand-line classes.

[JY:]Now I have no idea how close that is to what you need, because I really don't understand what you're trying to do, but that's a mutable class. Objects of class Foo can be modified.

I will read the code momentarily, question is - passing the Collection - as a whole - to next phase in sequence of phases. [and have that op have some effect on the dataset without having "pass by value" semantics leave one's efforts ineffective]


[JY:]Does that help any?
It provides me the opportunity to discard some issues that are not relevant. Your recent work suggests I more narrowly constrain my questions.

Am I getting bettterrrrrrrrrr..?




[ several attempts to get this up right, sorry ]

[ Message edit by Nick,... Jim, what the problem in posing the question is is the classic case of the beginner finding out about pass by value, if the collection is passed by value, then I have not modified the elements of the collection. (hence, seeming mis-statement "Objects are, generally, unmodifiable") Your code Jim is classic OO get/set. My question involves passing a Collection around, without invoking a File object. My placeholder effort:Vector v = new Vector(stopWords);]
[ July 01, 2007: Message edited by: Nicholas Jordan ]
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[NJ]: Very simple, not our usual go-round: Pass a Collection of objects from one phase of the program to the next.

Well, you just... pass it. As a parameter. Like you would for any other method. Here's an example:

Calling processA(list) passes the list to processA(). Calling processB(list) passes the list to processB(). Calling processC(list) passes the list to processC() - even from within processB(). There's nothing special going on here - you pass a collection around like any other object.

[NJ]: I tried that earler, but got bombarded for writing thousand-line classes.

Yes, the goal would be to write a class that (a) is short, (b) compiles, and (c) demonstrates the problem you're talking about. It's probably easier to just write short, working classes from scratch. Don't try to extract them from your existing code (not for a simple discussion like this), just make something fresh. It should have fewer connections to unrelated side issues. And it may, you know, compile.

[NJ]: Am I getting bettterrrrrrrrrr..?

I think so. It's still a bit hard to tell.
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
[JY]: Very simple, not our usual go-round: Pass a Collection of objects from one phase of the program to the next. (....) Well, you just... pass it. As a parameter. Like you would for any other method. ... There's nothing special going on here - you pass a collection around like any other object.

So it actually passes the object, not a copy. Great !

[JY]:Yes, the goal would be to write a class that (a) is short, (b) compiles, and (c) demonstrates the problem you're talking about. It's probably easier to just write short, working classes from scratch. Don't try to extract them from your existing code (not for a simple discussion like this), just make something fresh. It should have fewer connections to unrelated side issues.

That was (exactly) what the sample code was supposed to be. Got frustrated at the point marked int i = tm.get(walker);// here, I give up


[JY:]And it may, you know, compile.

I was trying to get the actual code straightened out, in anticipation of someone asking to look at what I was actually trying to do. Getting errors:


Has to do with packaging and directory structure. Will have to be straightened out as some point and needs to be straightened out now. Where do I post or should I just read "The Complete JAVA 2 Certification Study Guide" (SYBEX) The directory is already at 299 KB (306,741 bytes) trying to get going on this packaging and naming convention.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[NJ]; So it actually passes the object, not a copy.

I don't know what that means to you, so I can't really agree or disagree. I would say it passes a copy of a reference - it passes a reference by value. Consider:

Here it doesn't matter that we assign new values to a and b inside the trySwap() method - that has no effect on a and b in the main() method. The a and b in trySwap() are just copies of the references a and b in the main() method. In this respect, Java is behaving just like pass-by-value.

But here:

Here we are able to affect the data inside the two StringBuffers, in a way that's still visible after the method completes. That's because while a and b are copies, they're copies of references. And we can use the references to access methods, which affect the actual object on the heap. In this respect, Java is behaving like pass-by value. Except that the it only works when using methods, not when we try to assign a value with = (as in trySwap()). And if StringBuffer had not provided us with specific methods that allow us to change the data, we would not have been able to change it. That's the difference between passing by reference (which JAva does not support), and passing a reference (which Java does support, except for primitive types).

If your concept of "it actually passes the object" explains both of the above behaviors, then good. If not, I recommend studying the code some more, or asking related questions. I hope that helps...
[ July 02, 2007: Message edited by: Jim Yingst ]
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
Originally posted by Jim Yingst:
[JY]: I don't know what that means to you, so I can't really agree or disagree.



I took out of the quote all but what does essentially isolate the core of my question, and yes - your working of the issue is extremely effective in that I can now sleep knowing I can get at an accomplished methodology, refined by the class of work I have seen at javaranch. I do not think it productive to examine"If your concept of "it actually passes the object" explains both of the above behaviors", because I think we will do our classic cat chasing the tail routine and I am prepared to eat a little humble pie to get my GUI implemented so I can get up Alpha Release 0.4

It's when (my eye easily spotted the work in your code) you do thea.setLength(0);a.append(b);b.setLength(0);b.append(t); That you have done a classic swap operation, in effect modifiying the strings (! bear with me, I will explain momentarily)


At public void modifiy victor the Vector, I once again gave up - there are so many ways to do things and so often a great deal of work only results in lost months and all-night-hair-pullers where the eager and intent try to re-invent the wheel. I enjoy that methodology, but right now I need to let the established practices be some candlelight for a blind watchmaker. In general, the elements of the collection which is passed will be a complex object (class in Java Terminology) and here for the moment is that complex object:


That class, though not yet blocked out correctly, will be one of a potentially large number of instances - and I intend to pass the entire group, much as your sample code shows, along a sequence of operations.

I have a copy of Mastering Regular Expressions by O'Reilly and intend to walk through wordlists, taking each word and searching an entire file, buffer or any other thing one can see or point at during the routine use of the computer and search for something like "Buy cheap cheats now, enter the dungeon of no reprieve, oh hapless sucker ...." and so on, it all gets a little heavy unless I do things correctly. The absurdity of the purported keyphrase reflects my opinion of what we are trying to dig out of the machine, but there are hundreds of potential keyphrases - just examine any email inbox and pick out the,.... ahem,.... promotional materials.

  • Separate yourself from other clowns 21 Jul 2007 21K
  • Three Steps to the Software You Need at the... 21 Jul 2007 4K
  • Three Steps to the Software You Need at the... 21 Jul 2007 4K
  • Why pre-installed to your computer software... 20 Jul 2007 4K
  • Beware of fake pills 17 Jul 2007 21K
  • cheap oem soft shipping //orldwide 17 Jul 2007 3K
  • OEM Software - cheap software directly from... 16 Jul 2007 4K
  • Beware of fake pills 09 Jul 2007 21K
  • Beware of fake pills 02 Jul 2007 21K
  • Three Steps to the Software You Need at the... 06 Jul 2007 4K
  • Three Steps to the Software You Need at the... 01 Jul 2007 4K


  • I notice David J. Eck was able to put up applets that do a lot - (work/time) - and have previously been hung up on time-critical response to a degree that may hamper getting production-grade Alpha 0.4 implmentation out the door and in the hands of field techs unless I can get some steers (!) on classical contemporary practice.

    That may involve addional discussion, I will be available Sunday to continue.

    [JY:] I hope that helps...Thanks, Jim - your actually a great help. If you can consider getting the first 'clean' build of my GUI because of the confidence provided by your assistance to be valuable (I sure did ) then your comments helped.

    [ Message edit: the following code compiled and returned "true5"]

    [HW:]I suggest you first get your program to compile, and working.
    Yes, I recognize the need. If one can ask the question - one can answer the question. I think I have answered my own question by writing some code that will compile, but I wanted to let this happen under watchful eyes: It is critical to program top-down concepting that I get this right and I welcome any comments you may have on the code that did compile.
    [ July 22, 2007: Message edited by: Nicholas Jordan ]
    Nicholas Jordan
    Ranch Hand

    Joined: Sep 17, 2006
    Posts: 1282
    [JY: ]If your concept of "it actually passes the object" explains both of the above behaviors,...[/CODE]

    Well then your first example would have used the assignment operator to set a + b reversed using trySwap, thus the StringBuffers would have in fact swapped - be though it may the references would be what was actually swapped.

    I wrote this thinking about what you were saying and made a local String variable, which I then used to assign the String returned from BufferedReader.readline() to a memeber variable so that I was not escaping references that could propogate to other Threads.

    [code]
    // FileConsumer extends LineNumberReader
    public boolean readLine(boolean clearBufferFirst) throws IOException
    {
    if(clearBufferFirst && this.clearBuffer());
    this.nextLine = super.readLine();//
    return (this.nextLine != null)?true:false;//
    }
    [/code]
     
    Consider Paul's rocket mass heater.
     
    subject: Modifiying collection elements