@# Quotes DB     useful, funny, interesting





Google
 
Web www.quotesdb.info
Undernet  |  EFnet  |  Quakenet  |  Freenode  |  Dalnet  |  Ircnet  |  Galaxynet
Page: 1 2 3 4



Comments:

<0> test case is here http://javafaq.mine.nu/lookup?4&wb=true
<1> calchas: It's nothing to do with your tablemodel.
<1> An empty JTable does the same thing.
<1> A JButton doesn't.
<1> Maybe the tablemodel should specify the preferred size somehow (I don't know, I don't use JTable).
<0> I figered it wasn't the model
<0> I think swing just ****s at the prefered height
<0> was thinking along those lines, but it's a hell of a work round
<0> I mak have just found another solution that works for me
<0> brb with answer
<0> mak = may
<1> I'd probably just use a different layout. *resists temptation to plug own layout*
<0> layout doesn't fix it as the error seems to be wrong preffered size
<0> any layout that respects that will look wrong :(
<0> I think I can ditch the scroll pane
<2> calchas: Check out the JTable example I made on javafaq



<2> I think it has a ScrollPane
<2> but I am putting everything on BorderLayout
<0> will do once out of this line of code, ta
<0> I think that is the solution I'm following :)
<0> bingo
<0> I stopped using the scroll pane, and put the header and the body in a border layout
<0> thanks for the hints etc
<0> I'll look at faq in case I have more to learn
<0> I can re post the test case if anyone wants to see
<0> thunder do you have the link
<2> calchas: I didn't look for it.. but I can find it again.. hang on
<3> care shti-e un site symbian
<0> vladim|r no nonsense please
<0> it's ok, I have a solution that sounds the same
<2> http://javafaq.mine.nu/lookup?102
<0> vladim|r no pvt msg
<0> vladim|r please read topic
<4> Hi
<4> How would I remove an Object in java?
<0> also ask asl in here and you'll be banned
<4> the Object cl*** doesn't define a remove method
<0> this is not a pervert chan nor a teen pick up chan
<0> BlueLeaf you don't, stop using it (remove all references) and the garbage collector removes it
<4> I see
<1> pvt=pervert, right? ;)
<0> see garbage collection in the tutorial or in thinking in java
<0> private
<1> BlueLeaf: Garbage collection can be thought of how it sounds, imagine a little cleaner going around looking for stuff you're not using anymore, and removing them.
<0> it asked my asl :)
<1> s/cleaner/maid/ if you don't speak English English.
<4> thank you
<4> interesting
<4> you can force object finalization and garbage collection using the appropriate method in the System cl*** => that's nice
<0> no you can't
<0> you can suggest that it happens
<0> you can force the gc into a collection cycle, but whether it collects something or not is up to it
<0> if you have a lot of spare heap, it often decides to not waste time grabbing stuff
<4> I see
<1> BlueLeaf: Until you have a problem... gah.
<1> BlueLeaf: Until you have a problem don't bother about what memory you're using, and when you do have a problem use a profiler such as jmp.
<4> I'll take that advice :)
<5> Hello
<5> Does it make sense that an object placed in a servlet session would exist between different sessions
<5> I create a java.util.Stack and place it in a user's session ...when the user logs out and another user logs in..the damn thing still exists
<5> when the user logs out..their session is removed
<5> why might this happen..its driving me crazy
<5> any ideas?
<1> Smithers: You're probably storing it in a static variable.
<5> i'm not
<5> it doesn't make any sense...it is surviving even when i restart tomcat
<6> Smithers: test against another app server
<6> and perovide a real test case
<5> yeah i reckon i'm at fault
<5> i didn't know setting the session to null wasn't enough
<5> far as i can see you also need to set each item stored in the session to null too
<6> Smithers: what do you think does setting a pointer to null achieve?
<5> well i know it doesn't garbage collect immediatly
<5> i just wasn't aware that items in the session survive even if the session is destroyed
<5> or so it seems
<6> what does setting a pointer to null do to an object the pointer points to in java?
<6> the session does not get destroyed by ***igning null to a pointer.



<5> as far as i am aware it allows it to be garbage collected if there are no more references to it
<6> Smithers: agreed. where is the connection to something like a session?
<6> what makes you think that you are the only one with a pointer to that object?
<5> hmmm...so your saying something else may refer to the session 'ey...the container perhaps?
<5> if so then how would one hope to solve such a problem
<6> Smithers: maybe you should take the programmatic approach?
<5> i.e. destroy the session..or is that a bad idea..is the norm to destroy its contents
<6> Smithers: define "destroying a session"
<6> setting a pointer to null? no, that is not destroying the session (per se).
<5> get rid of it so that when the person logs in again a new session is created
<6> Smithers: consider looking at the servlets api docs, esp. httpsession
<5> ok thanks
<7> final int i = 100; byte b = i; // this works
<7> but if i remove final, it doesnt
<7> can anyone pls explain me why?
<6> RodeOrm: can you explain "does not work"?
<7> Clackwell, yes, it gives "Type mismatch: cannot convert from int to byte"
<7> does not compile
<7> to be more precise :)
<6> looks like an undesirable side effects as it distracts the programmer and makes him waste time with asking petty questions instead of thinking about his lack of type casting.
<6> -s
<5> maybe because 100 can be represented by a byte and other values greater than 100 that may be placed into that integer such as 32,568 cannot
<7> ok, but the example with final does not need casting
<5> since your making it final it knows that that is the final value
<8> can tell someone how to download sources with cvs?
<7> well try to replace int with long - it will not compile (even if you add "l" to 100)
<7> why does it work for int and not for "wider" types?
<5> it was just a theory..maybe wrong...but you could test it by trying to ***ign 254 and then 256....if 254 works but not 256 then there may be some creedence to what i'm saying
<7> Smithers, a byte is 8 bits, i.e. 127 is the maximum :P
<7> but there is creedence to what ur saying, yes
<7> though i still dont get it why i has to be final for the code to compile
<6> RodeOrm: it doesn't have to be.
<6> you are still wasting your time with a side effect.
<6> use type casting, move on
<6> hallo cal, thunder, dave, talios, everyone
<7> Clackwell, i am trying to understand it
<9> 'lo
<7> i can easily cast it
<2> Hey Clackwell :-)
<7> but thats not why i asked the question
<6> RodeOrm: don't, even if it is not a side effect.
<6> there are more relevant problems to think about.
<7> why do u think its irrelevant?
<7> isnt this channel called #java ?
<7> didnt i ask a java question?
<7> was it a stupid one?
<6> RodeOrm: i am not saying that it is an offtopic question. but what do you think have you possibly tapped into? a hardly known functionality of java that revolutionises how we develop software with java?
<6> or is it perhaps rather small thing, which, since it is only relevant for final stuff, is rarely of any use in the first place?
<6> which seems more likely?
<7> i am just trying to understand the difference
<7> if its irrelevant for you - just dont bother answering
<6> if on the other hand your problems should not be more important than finding an answer to the question of why type casting can be omitted in case of final variables, well...then i envy you. :)
<5> i think the answer is that you can't ***ign values greater then 127 to a byte...so if you don't make it final...there is potential for error
<5> and so the compiler won't allow it to compile
<6> Smithers: there is one theory to test.
<7> Smithers, this sounds like a good explanation
<6> RodeOrm: "A.java:10: possible loss of precision
<6> " is what my javac tells me.
<6> RodeOrm: it seems your javac is outdated and that you have in fact fiddled with an issue of a compiler implementation issue, a side effect, an uncovered area of the java language spec, etc. all of which have been fixed by now.
<6> or maybe you are using the latest and greatest and the issue got added at some point, because i am using...e:\projects>javac -J-version
<6> java version "1.5.0_03"
<7> i have installed 1.5 today
<6> RodeOrm: 1.5 != 1.5, and the time at which you installed it is more or less irrelevant.
<7> agree about the time :)
<1> 1.5!=1.5?
<6> RodeOrm: and here it is: it compiles with the "final" when the value is less than 128.
<7> Clackwell, yep, i've already discovered that
<1> Clackwell: Note that javac -J-version tells you what JVM you are using, not what comnpiler you are using.
<6> so Smithers nailed it it seems.
<7> i just wanted to know why
<1> Clackwell: javac -version does what you want for JDKs >=1.5.
<6> ricky_clarks: in my case the global jre == jdk
<1> Clackwell: Good.


Name:

Comments:

Please enter the result of the sum 63 + 46 (to avoid spam):






Return to #java
or
Go to some related logs:

appendtext richedit
#teens
avidemux remove adverts
#mirc
#mirc
#AllNiteCafe
blonda_rea
#linux
what do people think of the nz accent
#MissKitten



Home  |  disclaimer  |  contact  |  submit quotes