comp.lang.java.programmer http://groups-beta.google.com/group/comp.lang.java.programmer [EMAIL PROTECTED]
Today's topics: * execution speed java vs. C - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/e8713e999b13b7d1 * Java History - 3 messages, 3 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/5712674adb50bd0e * Problem wtih Java ThreadGroup.activeCount method - 5 messages, 3 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/80c6f5e77859ec02 * Tomcat admin web app? - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/cff3ddac8a2f143a * LDAP character encoding - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/2cd78003c51f2560 * Try these security pack from the M$ Corporation - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/fbc55b253e8bbc86 * "static" prefix - to parallel "this" prefix - 4 messages, 2 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/f5dde10882ac2157 * jfreechart: displaying values in pie chart as percentages - 2 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/5306e441484b2d4c * BigDecimal: Sun? IBM? - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/d8e6c9d469d029de * Servlet Context Problem - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/7f6783392a37b4c4 * I/O Deadlock. - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/b85e662ab698cca4 * plugin & packages - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/5f8770143f9f32c9 * Where do they go? - 2 messages, 2 authors http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/13296f4262fb9757 * Javamail with TNEF parts - 1 messages, 1 author http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/ac08c28db6c8d339 ============================================================================== TOPIC: execution speed java vs. C http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/e8713e999b13b7d1 ============================================================================== == 1 of 1 == Date: Fri, Dec 10 2004 12:39 am From: "Skip" > Skip wrote: > > after enableding the -server in java commandline 5.9s (you need the > java SDK > > for that) > > Do you happen to know whether the java that's shipped with OS X > (10.3.6) comes with the SDK? Java claims to know about the "-server" > option, but when I run the matrix multiply with it there is virtually > no improvement in runtime. If you can compile anything (with javac), you have the SDK. the JRE can only *run* apps. Sometimes the -server option has no effect, sometimes it's even slower than the client. Depends on the algorithm, the VM, the JIT, even the RAM (if you are short -server takes more ram). In this case however -server should give you a nice performance boost, if not, it's probably ignored or not supported. I was running WinXP 1.5.0 SDK ============================================================================== TOPIC: Java History http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/5712674adb50bd0e ============================================================================== == 1 of 3 == Date: Thurs, Dec 9 2004 3:39 pm From: [EMAIL PROTECTED] Being new to Java, I am trying to get a little history. Currently everything is referenced as some type of J2 (J2SE, J2EE, J2ME). I am wondering when/if there was ever a J1SE, J1EE, etc ... What does the 2 stand for? Was there some type of major revision? Thanks. == 2 of 3 == Date: Thurs, Dec 9 2004 4:52 pm From: Chris Smith <[EMAIL PROTECTED]> wrote: > Being new to Java, I am trying to get a little history. > > Currently everything is referenced as some type of J2 (J2SE, J2EE, > J2ME). > > I am wondering when/if there was ever a J1SE, J1EE, etc ... Not exactly. First there was Java 1.0.2 (the first public release). Then there were several 1.1 releases. Then there was 1.2. At the time of Java 1.2, a lot of changes got made. Though there were actually no changes at all to the language specification, the main changes were: a vastly expanded standard API, at least several times as expansive as the 1.1 versions and including Swing and Java2D for the first time and a completely revamped security model; a completely re- implemented virtual machine, incorporating the then-new Hotspot technology to do adaptive JIT compiling of code; and some great leaps forward in the ease of use of the development tools (including the new classloading scheme that distinguishes between the boot classloader and the system classloader). There were other changes as well. Primarily because of Hotspot, and partially because of Swing, Sun felt that they had turned a corner, if you will, and that all the prior critiques of Java, which were mostly aimed at performance, no longer applied. Hence, they felt the need for a new name, and they called the release version 1.2 of the "Java 2" platform. History has proven them right in that time efficiency is nowhere near the concern for Java that it was; but I'm not sure how much good that marketing decision of "Java 2" actually did. -- www.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation == 3 of 3 == Date: Thurs, Dec 9 2004 4:08 pm From: Kieron Briggs [EMAIL PROTECTED] wrote: > Being new to Java, I am trying to get a little history. > > Currently everything is referenced as some type of J2 (J2SE, J2EE, > J2ME). > > I am wondering when/if there was ever a J1SE, J1EE, etc ... > > What does the 2 stand for? Was there some type of major revision? The numbering system of Java has been.... erratic. From memory (and I'm sure others will correct me here...) In the beginning there was Java, which was also called Java 1.0. Then there were some improvements to the standard API, and Java 1.1 was born. Then there were some more improvements to the standard API and Java 1.2 was born. But for some reason (I think it had to do with the bad press Java 1.0 had received for being slow), they decided to also call this Java 2. And to complicate matters more, there was the Standard Edition (which had all the standard APIs) and the Enterprise Edition (which had some extra APIs like mail and so on). Then there were some more changes to both the standard APIs and the enterprise APIs, and Java 1.3 was born. However, this was still called Java 2, not 3. Go figure. Ditto for Java 1.4. Now we are just arriving at Java 1.5. This is the first version to introduce really major language changes (generics etc) as well as API improvements. I think they're trying to get people to call this Java 5.0... ;-) If you think this is confusing, you're right... Kieron ============================================================================== TOPIC: Problem wtih Java ThreadGroup.activeCount method http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/80c6f5e77859ec02 ============================================================================== == 1 of 5 == Date: Thurs, Dec 9 2004 3:41 pm From: "nimph" I had to do the same thing in a project I recently worked on.... Exactly! I have no idea why though... Maybe the Thread objects' destroy() method was not called yet, making the contained thread remain active. Or, maybe it's something to do with garbage collection????? Just guessing... Anyone else? == 2 of 5 == Date: Thurs, Dec 9 2004 3:55 pm From: "avinashrk" Yes that is what my initial hunch was... But then I read somewhere that activeCount returns the count of the threads which are active .i.e NOT DEAD..and a thread is dead when it exits its run method...A thread object might be lying in memory to be garbage collected but the active status of the thread is only dependent on its exiting the run method because a thread can never be resurrected... so what I mean is if a thread is not garbage collected as soon as it exits its run method its ok but it surely does mean by definition that the thread is dead and shouldn't the activeCount go down then? Thanks Avinash == 3 of 5 == Date: Thurs, Dec 9 2004 4:02 pm From: "nimph" The javadoc says that the return is an estimate of the number of active threads in this thread group and in any other thread group that has this thread group as an ancestor... Did any of your code create any threads that would have that threadGroup as it's ancestor? ???? == 4 of 5 == Date: Thurs, Dec 9 2004 4:19 pm From: "avinashrk" Ok here is what my code (incomplete..only parts of logic using threadGroup) looked like Class Server{ protected ThreadGroup threadGroup; /** Creates a new instance of Server */ public Server(String serviceName) { this.serviceName = serviceName; this.threadGroup = new ThreadGroup(serviceName); } public void run(){ newSocket.runner = new Thread( threadGroup, newSocket); newSocket.runner.start(); } } class PhredServer extends Server{ //This class used the ThreadGroup.activeCount } So with this framework I was having 3 PhredServers running but each PhredServer was running in a separate JVM..i mean I started 3 PhredServers by calling java PhredServer 3 times...So I can see that the serviceName is same in each of them but still since they are in different JVMs I think the ThreadGroups are distinct objects and therefore should have their own independent counts..right? i mean if there are two threads in each of these Servers then each of them should have count 2 and not 2*3=6? Other than that there were no other threads which had this group as an ancestor ...So what do you think? Avinash == 5 of 5 == Date: Thurs, Dec 9 2004 5:38 pm From: Esmond Pitt ThreadGroup.activeCount() works for me, see following. JDK 1.3. As soon as a thread exits its run() method the activeCount goes down. Joining and GC have no effect on it. public class ThreadGroupTest extends Thread { ThreadGroup group; int timeout; /** Creates new ThreadGroupTest */ ThreadGroupTest(ThreadGroup group,int timeout) { super(group,"timeout="+timeout); this.group = group; this.timeout = timeout; } public void run() { System.out.println(this+": running"); try { sleep(timeout); } catch (InterruptedException exc) { } System.out.println(this+": exiting - activeCount="+group.activeCount()); } /** * @param args the command line arguments */ public static void main (String args[]) throws Exception { ThreadGroup group = new ThreadGroup("Telekinesis"); Thread[] threads = new Thread[5]; for (int i = 0; i < threads.length; i++) { threads[i] = new ThreadGroupTest(group, (i+1)*1000); threads[i].start(); } System.out.println("main after all starts: activeCount="+group.activeCount()); for (int i = 0; i < threads.length; i++) { threads[i].join(); System.out.println("main after joining "+i+": activeCount="+group.activeCount()); } System.out.println("main after all joins: activeCount="+group.activeCount()); threads = null; System.gc(); System.out.println("main after GC: activeCount="+group.activeCount()); } } ============================================================================== TOPIC: Tomcat admin web app? http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/cff3ddac8a2f143a ============================================================================== == 1 of 1 == Date: Thurs, Dec 9 2004 4:55 pm From: Chris Smith coder <[EMAIL PROTECTED]> wrote: > When i click on the tomcat administration link at the default tomcat > page, i get: > "Tomcat's administration web application is no longer installed by > default. Download and install the "admin" package to use it." > > I have tried and tried,but didnt find a download site for "admin > package" There are admin packages for 5.5.4 and 5.5.5-alpha at http://jakarta.apache.org/site/binindex.cgi right next to the main downloads. -- www.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation ============================================================================== TOPIC: LDAP character encoding http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/2cd78003c51f2560 ============================================================================== == 1 of 1 == Date: Thurs, Dec 9 2004 5:01 pm From: Chris Smith smirks <[EMAIL PROTECTED]> wrote: > I believe the problem has to do with character encoding, but I don't > know how to proceed from here. I have tried various character sets when > converting 'value' to a byte array above, but to no avail. Well, the code you posted only showed you using the default system encoding. That's almost certain to be wrong. I don't know where a lot of this is coming from, so can you post a complete example instead of one or two lines of code? If you don't believe that the Apache Commons project is part of the issue, you could remove it, too. -- www.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation ============================================================================== TOPIC: Try these security pack from the M$ Corporation http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/fbc55b253e8bbc86 ============================================================================== == 1 of 1 == Date: Thurs, Dec 9 2004 4:01 pm From: "Tom Beckner" Cancelled because of virus: I-Worm.Swen ============================================================================== TOPIC: "static" prefix - to parallel "this" prefix http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/f5dde10882ac2157 ============================================================================== == 1 of 4 == Date: Thurs, Dec 9 2004 11:54 pm From: Tim Tyler Darryl L. Pierce <[EMAIL PROTECTED]> wrote or quoted: > Tim Tyler wrote: > > >>>Within the definition of a class you shouldn't need to spell out > >>>the name of the class - you /should/ just be able to say "this class". > >> > >>You don't *have* to mention the class *except* to clarify the context, > >>just as you do when you use the "this" keyword. > > > > Constructors are the most common mention of class names in the same > > class. They replicate the name of the class at several places > > within the class. The only alternative is not to use constructors > > - and then you lose out on the inherited constructor from > > Object - and implicit calls to super(). > > So? What does that have to do with the topic of using the classname to > specify context? It has to do with this - which was the context until this message, where it was snipped out. ``Most of the uses of the classname are redundant. To see that, change the name of the class. All the uses of the classname (within the body of the class) that have to change with it are redundant.'' > >>>>BTW, the above scenario doesn't happen in Eclipse: you refactor and > >>>>rename the class and all of those references are updated. *AND* the > >>>>references in *other* classes are updated too. Which brings up an > >>>>interesting question: how will you refer to static methods/variables in > >>>>*other* classes? Are we going to keep the ClassName.staticField pattern? > >>>>If so, then we now have *two* ways of doing the *exact same thing* which > >>>>to my mind makes the static keyword even *less* attractive. > >>> > >>>Actually there would be three ways: > >>> > >>>"ClassName.var" > >>>"var" > >> > >> > ....or... > >> > "static.var". > >> > > >> > They don't say quite the same thing as each other - though they > >> > would all refer to the same static variable. > >> > >>And how does the above tell you *which* other class you're referring to? > > > > It doesn't. I never said it did. > > Then why did you write it in reply to my question? I didn't. I wrote it in reply to: ``If so, then we now have *two* ways of doing the *exact same thing* which to my mind makes the static keyword even *less* attractive.'' The answer to your question seemed so self-evident I treated it as rhetorical. > I asked a specific question: how will you specify the context for a > static variable or field in a *different* class from the one referring > to it? Exactly the same as before. The proposal has nothing whatsoever to do with that. > > I was just pointing out that the > > claim that there were *two* ways of doing things was incorrect: > > A claim *I* never made. I said that you use the classname to specify > context in an ambiguous piece of code. I never said there were only two > ways to resolving this. There are at least two ways - with or without my proposal. Observing that there are at least two ways would have been irrelevant to the proposal. > > Actually two ways is the current situation - so your argument boils down > > to an assertion that the current situation is undesirable ;-) > > No, it doesn't. [...] I /thought/ you were just arguing that having two ways of specifying a static member was undesirable. > >>I asked above "how will you refer to static methods/variables in *OTHER* > >>(new emphasis) classes?" > > > > The same as normal. The proposal has nothing to do with that. > > The proposal, then, is unnecessary. Why do we need a *special* keyword > to state what is *already* possible and clearly stated with the existing > language specification? Becasue it can clarifies which variable is being referred to when the reference is in the same class. > >>In this scenario "static" brings nothing new to the table [...] > > > > It deals with the situation where you are distingishing instance > > variables, local variables and static variables in the *same* class. > > Something that is *already* done by using the name of the class. As I > said, "static" brings nothing _new_ to the table. This has already been discussed twice. Using the name of the class in the same class causes refactoring pain, and leads to reduced readability when the class name is long. > > The proposal was never supposed to improve the situation with other > > classes. > > > > It is analogous to "this" in that respect. > > Except that "this" has a specific purpose that is not available > otherwise. [...] Not "except" - because that's a different respect. > >>and you will *still* have to type the classname to provide > >>context to the compiler. So, in deference to your claiming it's > >>redundant data, it's actually quite necessary [...] > > > > You should not have to spell out the class name repeatedly in > > the class. Doing so is redundant - and it's a maintenance screw-up - > > since you open up the possibility of the names getting out of step. You > > /should/ be able to say something which says "this class". > > You're repeating yourself without supporting your statement. The fact > is, you *don't* _have_ to "spell out the class name" at > *all*....provided you give your static field or method a name *different > from* an instance field/method and a parameter name. [...] The whole idea of using lint tools in this context is that you add the "this.", "static." (if available) identifiers at *every* single location they are used - so you can identify static and instance variables immediately by looking at them. You do not only add them in *some* places - that would not produce the same result. You add them *everywhere* - and use the lint tool to automatically check that they are used in all the correct places. > If you want to use the same name for a static field as a passed > parameter, then you have to accept that you'll need to specify the > context for the static field by using the classname to specify context. I don't have to accept it passively. I can request improvements, that would eliminate this need. > Changing the language spec to add a new keyword is rather daft since > it doesn't prevent the underlying problem, which is the poor choice of > variable names. IMO, the underlying problem is the existence of a static context - as opposed to class members and methods. This fudge is being requested because static methods were always a crude and primitive hack. > > In a sensible language, you'd just use the class object: "class" - > > but of course in Java, this doesn't work. > > The programming language will never be able to stop programmers from > making poor choices. Maybe not - but IMO, this thread isn't about doing that. -- __________ |im |yler http://timtyler.org/ [EMAIL PROTECTED] Remove lock to reply. == 2 of 4 == Date: Thurs, Dec 9 2004 4:19 pm From: Tim Tyler Darryl L. Pierce <[EMAIL PROTECTED]> wrote or quoted: > Tim Tyler wrote: > > Smalltalk has an altogether more sensible approach: "static" methods are > > ordinary instance methods of the object representing the class. > > And that makes no sense since static methods in Java are *not a part of > any object*. [...] To argue that Smalltalk's approach is not better you would have to point out some advantage to Java's approach. Saying Java does things differently is not a counter-argument - when the /way/ in which it does things differently is the very thing that is under criticism. > The fact that you put the word static into quotes should > have been a signal to you that something was amiss in your statement; I put the word in quotes because Smalltalk doesn't call analogous methods "static". AFAICS, there was nothing amiss in my statement. > i.e., that Smalltalk has something that's not static from Java's point > of view doesn't mean the Smalltalk solution is what would work for Java. I said "Smalltalk has an altogether more sensible approach". I don't pretend this approach could be grafted back on to Java - especially not at this late date. However: offering "static" methods - and failing to offer "class" methods or class inheritance originally was almost certainly a bad design decision - since static methods can't be overriden, add complexity to the language, and lead to practical problems such as the "Inherited Java Singleton Problem". While I don't know the details, I /expect/ it was originally done either for the sake of security - or under time pressure. -- __________ |im |yler http://timtyler.org/ [EMAIL PROTECTED] Remove lock to reply. == 3 of 4 == Date: Thurs, Dec 9 2004 4:40 pm From: "Darryl L. Pierce" Tim Tyler wrote: >>>>>Within the definition of a class you shouldn't need to spell out >>>>>the name of the class - you /should/ just be able to say "this class". >>>> >>>>You don't *have* to mention the class *except* to clarify the context, >>>>just as you do when you use the "this" keyword. >>> >>>Constructors are the most common mention of class names in the same >>>class. They replicate the name of the class at several places >>>within the class. The only alternative is not to use constructors >>>- and then you lose out on the inherited constructor from >>>Object - and implicit calls to super(). >> >>So? What does that have to do with the topic of using the classname to >>specify context? > > It has to do with this - which was the context until this message, > where it was snipped out. > > ``Most of the uses of the classname are redundant. To see that, change > the name of the class. All the uses of the classname (within the > body of the class) that have to change with it are redundant.'' Sorry, I still disagree. Re-using the classname for specific purposes isn't redundant. *Having* to state something that's obvious from context is redundant. For example, if you *had* to specify the classname for context whenever you use a static method would be redundant. If you only do it to resolve an ambiguity then it's not redundant by any definition of the word. >>>>>>BTW, the above scenario doesn't happen in Eclipse: you refactor and >>>>>>rename the class and all of those references are updated. *AND* the >>>>>>references in *other* classes are updated too. Which brings up an >>>>>>interesting question: how will you refer to static methods/variables in >>>>>>*other* classes? Are we going to keep the ClassName.staticField pattern? >>>>>>If so, then we now have *two* ways of doing the *exact same thing* which >>>>>>to my mind makes the static keyword even *less* attractive. >>>>> >>>>>Actually there would be three ways: >>>>> >>>>>"ClassName.var" >>>>>"var" >>>> >>>>>....or... >>>>>"static.var". >>>>> >>>>>They don't say quite the same thing as each other - though they >>>>>would all refer to the same static variable. >>>> >>>>And how does the above tell you *which* other class you're referring to? >>> >>>It doesn't. I never said it did. >> >>Then why did you write it in reply to my question? > > I didn't. I wrote it in reply to: > > ``If so, then we now have *two* ways of doing the *exact same thing* which > to my mind makes the static keyword even *less* attractive.'' The above sentence is quite obviously talking about the proposed solution in addition to the currently existing solution. > The answer to your question seemed so self-evident I treated it as > rhetorical. > >>I asked a specific question: how will you specify the context for a >>static variable or field in a *different* class from the one referring >>to it? > > Exactly the same as before. The proposal has nothing whatsoever to do > with that. The proposed solution is *unnecessary*. It doesn't clarify anything, it doesn't do anything but use a different word to achieve an end that is *already achievable* with the current language specification. There has not been presented a compelling reason for why we should have another way to do something we can already do now. >>>I was just pointing out that the >>>claim that there were *two* ways of doing things was incorrect: >> >>A claim *I* never made. I said that you use the classname to specify >>context in an ambiguous piece of code. I never said there were only two >>ways to resolving this. > > There are at least two ways - with or without my proposal. Observing > that there are at least two ways would have been irrelevant to the > proposal. Huh? >>>Actually two ways is the current situation - so your argument boils down >>>to an assertion that the current situation is undesirable ;-) >> >>No, it doesn't. [...] > > I /thought/ you were just arguing that having two ways of specifying > a static member was undesirable. I *am* arguing that, and have been since joining this thread. What part of my position isn't clear enough for you? The keyword you're proposing is unnecessary. We can already do what you want by using the classname to specify context when necessary. The described "static" keyword doest' do anything that the classname usage can't already do. And we would still need to use the classname when resolving the static reference from a different class, so if we had your proposal we would end up with two ways of achieving one single end built into the language specification. *THAT* is redundant. >>>>I asked above "how will you refer to static methods/variables in *OTHER* >>>>(new emphasis) classes?" >>> >>>The same as normal. The proposal has nothing to do with that. >> >>The proposal, then, is unnecessary. Why do we need a *special* keyword >>to state what is *already* possible and clearly stated with the existing >>language specification? > > Becasue it can clarifies which variable is being referred to > when the reference is in the same class. We can *already* do that by using the classname. We don't *need* yet *another* way to do that. >>>>In this scenario "static" brings nothing new to the table [...] >>> >>>It deals with the situation where you are distingishing instance >>>variables, local variables and static variables in the *same* class. >> >>Something that is *already* done by using the name of the class. As I >>said, "static" brings nothing _new_ to the table. > > This has already been discussed twice. Using the name of the class > in the same class causes refactoring pain, No, it's not. Eclipse doesn't have a problem, and it's a single, simple search-and-replace operation for pretty much all editors. Perhaps you aren't using the right tool? > and leads to reduced > readability when the class name is long. That, sorry to say, is an opinion and not a fact. >>>The proposal was never supposed to improve the situation with other >>>classes. >>> >>>It is analogous to "this" in that respect. >> >>Except that "this" has a specific purpose that is not available >>otherwise. [...] > > Not "except" - because that's a different respect. The "this" keyword has a purpose that cannot be achieved by *any* other means. How else would you do this? public class Foo { private static Vector instances = new Vector(); public Foo() { instances.addElement(this); } } You *can't*. It's impossible without exposing the implementation details of the Foo class to the outside world. >>>>and you will *still* have to type the classname to provide >>>>context to the compiler. So, in deference to your claiming it's >>>>redundant data, it's actually quite necessary [...] >>> >>>You should not have to spell out the class name repeatedly in >>>the class. Doing so is redundant - and it's a maintenance screw-up - >>>since you open up the possibility of the names getting out of step. You >>>/should/ be able to say something which says "this class". >> >>You're repeating yourself without supporting your statement. The fact >>is, you *don't* _have_ to "spell out the class name" at >>*all*....provided you give your static field or method a name *different >>from* an instance field/method and a parameter name. [...] > > The whole idea of using lint tools in this context is that you add > the "this.", "static." (if available) identifiers at *every* single > location they are used - so you can identify static and instance > variables immediately by looking at them. Sorry, mate, but *that* is redundancy. You're using a keyword where it's not necessary. > You do not only add them in > *some* places - that would not produce the same result. You add them > *everywhere* - and use the lint tool to automatically check that they are > used in all the correct places. You're adding it where it's unnecessary. You're now talking about altering the language to make it easier for a utility? That's daft. >>If you want to use the same name for a static field as a passed >>parameter, then you have to accept that you'll need to specify the >>context for the static field by using the classname to specify context. > > I don't have to accept it passively. I can request improvements, > that would eliminate this need. And I'm free to voice my opinion, and I think that this keyword proposal offers nothing of any value. >>Changing the language spec to add a new keyword is rather daft since >>it doesn't prevent the underlying problem, which is the poor choice of >>variable names. > > IMO, the underlying problem is the existence of a static context - > as opposed to class members and methods. This fudge is being > requested because static methods were always a crude and primitive hack. That's your opinion. Good luck with that. >>>In a sensible language, you'd just use the class object: "class" - >>>but of course in Java, this doesn't work. >> >>The programming language will never be able to stop programmers from >>making poor choices. > > Maybe not - but IMO, this thread isn't about doing that. And all I have read from you has been about trying to change the language to avoid a style problem. There wouldn't even be a *need* for the reference if it were clear to the compiler whether you were referring to a static variable or a method argument. If it were clear (by using a proper naming convention, for example) then you would *not* have to tell the compiler "this variable is the static one".... -- Darryl L. Pierce <[EMAIL PROTECTED]> Visit my webpage: <http://mcpierce.multiply.com> "By doubting we come to inquiry, through inquiry truth." - Peter Abelard == 4 of 4 == Date: Thurs, Dec 9 2004 5:02 pm From: "Darryl L. Pierce" Tim Tyler wrote: >>>Smalltalk has an altogether more sensible approach: "static" methods are >>>ordinary instance methods of the object representing the class. >> >>And that makes no sense since static methods in Java are *not a part of >>any object*. [...] > > To argue that Smalltalk's approach is not better you would have to point > out some advantage to Java's approach. Saying Java does things > differently is not a counter-argument - when the /way/ in which it does > things differently is the very thing that is under criticism. And saying that Smalltalk does it differently isn't a counter-argument either, nor does Smalltalk doing it a different way mean that Java's way is wrong. >>The fact that you put the word static into quotes should >>have been a signal to you that something was amiss in your statement; > > I put the word in quotes because Smalltalk doesn't call analogous > methods "static". > > AFAICS, there was nothing amiss in my statement. How is Smalltalk's way different from Java? And why do you think it's better? >>i.e., that Smalltalk has something that's not static from Java's point >>of view doesn't mean the Smalltalk solution is what would work for Java. > > I said "Smalltalk has an altogether more sensible approach". > > I don't pretend this approach could be grafted back on to Java - > especially not at this late date. > > However: offering "static" methods - and failing to offer "class" > methods or class inheritance originally was almost certainly a bad > design decision - since static methods can't be overriden, add > complexity to the language, and lead to practical problems such > as the "Inherited Java Singleton Problem". Static methods aren't about inheritence. Try to move past that. -- Darryl L. Pierce <[EMAIL PROTECTED]> Visit my webpage: <http://mcpierce.multiply.com> "By doubting we come to inquiry, through inquiry truth." - Peter Abelard ============================================================================== TOPIC: jfreechart: displaying values in pie chart as percentages http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/5306e441484b2d4c ============================================================================== == 1 of 2 == Date: Thurs, Dec 9 2004 4:20 pm From: "Marc Dugger" Using DefaultPieDataset, values are appearing as raw numbers by default. How can I configure chart to display values as a percentage (i.e. x%) of the total number of values? == 2 of 2 == Date: Thurs, Dec 9 2004 5:02 pm From: "Marc Dugger" Using DefaultPieDataset, values are appearing as raw numbers by default. How can I configure chart to display values as a percentage (i.e. x%) of the total number of values? ============================================================================== TOPIC: BigDecimal: Sun? IBM? http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/d8e6c9d469d029de ============================================================================== == 1 of 1 == Date: Thurs, Dec 9 2004 4:22 pm From: jddarcy wald <[EMAIL PROTECTED]|m.cit.kuleuven.ac.be> writes: >Hey group, >I'm considering using the java.math.BigDecimal class for a >simulation program I'm working on. Reading up on the subject, I've >come across a bunch of (seemingly outdated?) pages describing >alternative IBM implementations and specifications improving on >the functionality [1]. >Now, several questions pop up because basically I'm confused by >these different sources: >* what's the status of the Sun implementation of IBM's >specifications? There's definitely something going on [2], but it >isn't really clear to me if it's already implemented in J2SE 1.5.0 >or not. Sun, IBM, and a few others worked on JSR13 and JSR13 is part of jdk 5. The BigDecimal class now supports floating-point style operations; i.e. results can be rounded to a given precision. See http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigDecimal.html The new BigDecimal features are also described in the article "Fixed, Floating, and Exact Computation with Java's BigDecimal" from the July 2004 issue of DDJ. -jddarcy ============================================================================== TOPIC: Servlet Context Problem http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/7f6783392a37b4c4 ============================================================================== == 1 of 1 == Date: Thurs, Dec 9 2004 5:06 pm From: [EMAIL PROTECTED] Hi everybody, I am starter for the JSP/Servlet programming. I got a problem here. I have a several bean classes here. I want one of the bean classes detect the context from the root. Is there any way to achieve it? Thanks! Bighead ============================================================================== TOPIC: I/O Deadlock. http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/b85e662ab698cca4 ============================================================================== == 1 of 1 == Date: Thurs, Dec 9 2004 5:13 pm From: "Ken Adams" Basically I have a client/server system and I implement the following ocde to set up the streams on both the client and the server. I seem to have deadlock when program execution enters this area. How to I stop the deadlock between the client and server? Thanks Socket socket = new Socket(hostName, port); ObjectInputStrem inStream = new ObjectInputStream(new BufferedInputStream(socket.getInputStream())); ObjectOutputStream outStream = new ObjectOutputStream(new BufferedOutputStream(socket.getOutputStream())); ============================================================================== TOPIC: plugin & packages http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/5f8770143f9f32c9 ============================================================================== == 1 of 1 == Date: Thurs, Dec 9 2004 5:22 pm From: "VisionSet" "Chris Smith" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > VisionSet <[EMAIL PROTECTED]> wrote: > > It is a very simple demo app, I've got it working with the class files, and > > I'm happy with it. The directory is scanned for class files and a > > Class.forName gets the class, if it is not assignable to my Inteface it is > > rejected. There is only one simple class implementation required. If it > > were more elaborate I'd go for jars. > > Just please don't deploy this, then. > > Sounds like you're making things harder than you need to (for example, > you're loading the classes with Class.forName? Does that mean that > you're placing these plugin classes in the classpath?) while > simultaneously preventing people from using good programming techniques. how do you mean? Yes the plugins are on the classpath under a default package. I'm guessing you are suggesting to at least have some package structure The purpose is really to avoid having to teach the plugin writer any more than is strictly necessary to produce the plugin, since this is only a simple demo app. Java knwoledge isn't an aim rather the algorithm they write. I'd just like the writer of the plugin to just produce a classfile and pop it in the right place for it to be detected. Do you have an improvement without the need to jar the plugin? -- Mike W ============================================================================== TOPIC: Where do they go? http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/13296f4262fb9757 ============================================================================== == 1 of 2 == Date: Thurs, Dec 9 2004 3:48 pm From: Kieron Briggs Steve Horsley wrote: > Java has a thingy called a garbage collector. It goes round retrieving > the memory from objects that have been forgotten by the program, meaning > objects that can no longer be reached by any active thread. > You can forget an object just by overwriting all references to it, or > letting them go out of scope (like when a method returns). For the visually minded, here's a parable I use when explaining garbage collection to people: Picture a big empty room with a big furnace/incinerator type thing at one end. Hanging form the roof are a number of ropes, called Threads. Attached to the various threads are little sparkly Objects, and those Objects can have other Object attached to them in turn by little rods called References. This creates a (hopefully) beautiful structure of Objects all attaches (either directly or indirectly) to a Thread. You can even have Objects which link to more than one Thread. When an Object isn't needed any more, the Reference to it disappears. If that leaves the Object (or a whole collection of Objects) unattached to any Thread, it will fall down onto the floor and shatter. This gradually builds up a layer of broken objects lying around the floor. In a language like C, eventually the floor would become so full that there was no room for more Objects, and Bad Things would happen. But in Java, we have a Garbage Collector. This is a little dude in overalls that climbs down a special Staff Only Thread, sweeps up all the broken Objects on the floor, and shovels them into the incinerator. You never know exactly when he's going to come along, but he's always there keeping an eye on the mess on the floor to make sure that it doesn't fill up too much... Kieron == 2 of 2 == Date: Thurs, Dec 9 2004 5:43 pm From: "2471" Thanks to everyone for all the help ============================================================================== TOPIC: Javamail with TNEF parts http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/ac08c28db6c8d339 ============================================================================== == 1 of 1 == Date: Thurs, Dec 9 2004 5:55 pm From: "Ann" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hello all, > > I am trying to use the Javamail API to extract messages from an > Exchange server using the IMAP protocol. Everything so far has worked > fine as long as the Multipart messages don't contain a TNEF part. I > have found JTNEF to parse these parts and extract the attachments but > the problem is when using Javamail I don't see the TNEF part: > > Message message = folder.getMessage(1); > assertEquals("checking number of parts", 2, > ((Multipart)message.getContent()).getCount()); > > For instance, the above test fails saying it expected 2 parts but found > 1. I'm sure I am getting the correct message and that there is a TNEF > part because: > > message.writeTo(System.out) > > shows it. Printing out the content of the part I can actually get at > prints the body of the email but this is all I can get. Any > suggestions on what I am missing here? > > Thanks for your time! I have little experience with TNEF but seem to recall something about there being a single TNEF attachment, and that the other attachments are inside the TNEF attachment. ============================================================================== You received this message because you are subscribed to the Google Groups "comp.lang.java.programmer" group. To post to this group, send email to [EMAIL PROTECTED] or visit http://groups-beta.google.com/group/comp.lang.java.programmer To unsubscribe from this group, send email to [EMAIL PROTECTED] To change the way you get mail from this group, visit: http://groups-beta.google.com/group/comp.lang.java.programmer/subscribe To report abuse, send email explaining the problem to [EMAIL PROTECTED] ============================================================================== Google Groups: http://groups-beta.google.com
