comp.lang.java.programmer
http://groups-beta.google.com/group/comp.lang.java.programmer
[EMAIL PROTECTED]

Today's topics:

* writing and reading objects - 4 messages, 3 authors
  
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/42024eb362a85850
* Java SSH / Telnet client Source - 3 messages, 2 authors
  
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/9783da10290de218
* Java trick - 13 messages, 4 authors
  
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/bfd25be52dc6a3ad
* Pausing a Swing Worker Thread? - 1 messages, 1 author
  
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/d5da19ea5521b080
* Hello, googs, congratulations! - 1 messages, 1 author
  
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/79188f21565e7f7
* How to incremet IndetAddress / IP numbers - 1 messages, 1 author
  
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/94897e32234ceaaf
* Noobie looking for relevant Java knowledge - 1 messages, 1 author
  
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/289f1f05fa606891
* Memory leakage problem with a database application - 1 messages, 1 author
  
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/cd24fb0a93e5b285
* struts & restarting Tomcat - 1 messages, 1 author
  
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/5bee53f53da7265c
* xerces and xalan - 2 messages, 2 authors
  
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/6f2ec969c996f8b1
* what u program? - 1 messages, 1 author
  
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/ee20f99e67fd5410
  
==========================================================================
TOPIC: writing and reading objects
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/42024eb362a85850
==========================================================================

== 1 of 4 ==
Date:   Sat,   Sep 18 2004 8:07 am
From: Paul Lutus <[EMAIL PROTECTED]> 

Madhur Ahuja wrote:

> Hello
> 
> I have been given the task of doing simple file handling in java.
> i.e. I want to write set of records to a file and read them.
> The problem is that writeObject function produces inconsistent
> results when we write a series of records in one session and when
> we write same number of records by running the program again and again
> i.e. appending.

I recommend that you solve this and a dozen other problems by writing and
reading text, not objects. This suggestion may seen orthogonal to the
immediate problem you face, but in fact it *is* the problem you face.

Data records that are expected to have a lifetime longer than 15 minutes
should be written out in a way that they can be read successfully by a
different program running on a different platform. This ironically makes it
easier to read them with the originating program also.

And finally, if you write using a plain-text format, appending records to an
existing database is made much easier.

-- 
Paul Lutus
http://www.arachnoid.com




== 2 of 4 ==
Date:   Sat,   Sep 18 2004 11:31 am
From: Michael Borgwardt <[EMAIL PROTECTED]> 

Madhur Ahuja wrote:
> I have been given the task of doing simple file handling in java.
> i.e. I want to write set of records to a file and read them.
> The problem is that writeObject function produces inconsistent
> results when we write a series of records in one session and when
> we write same number of records by running the program again and again
> i.e. appending.
> The file size differs in above 2 cases.
> 
> Thus reading the records produces this exception:
> StreamCorruptedException
> 
> This exception occurs only when we read from the file in which data
> has been appended.
> The exception doesnt occurs if we write to file only once and then read.

That's because ObjectOutputStream doesn't just "write objects", it first
writes a header, and ObjectInputStream doesn't like encountering that
header in the middle of its input.

In think Paul is overstating the case, but you should be aware that
you will run into problems reading the serialized data when you
change the definitions of the classes you've serialized.

Anyway, in order to get this appending to work, you'd have to use
separate ObjectInputStreams for each "segment" (i.e. each part of
the file that was written by a separate ObjectOutputStream).
This can be done be prepending each of these segments with an
integer containing the number of "records" to read, or by ending
each segment with a special object that tells you that you now
have to use a new ObjectInputStream.



== 3 of 4 ==
Date:   Sat,   Sep 18 2004 12:41 pm
From: "Madhur Ahuja" <[EMAIL PROTECTED]> 

Andrew Thompson <[EMAIL PROTECTED]> wrote:
> On Sat, 18 Sep 2004 16:59:44 +0530, Madhur Ahuja wrote:
>
>> The code that am using is:
>
> No it is *not* the code you are using!
>
> The code you provided does not compile.
>
> But before you post your *actual* code, I suggest you
> join all the try's in a single block and..
>
>> ////////////////////////////
>> import java.io.*;
>> public class serial6
> ...
>> catch( IOException e)
>>        {
>
> e.printStackTrace();
>
>>        }
>
> Exceptions (at least the stack traces) are your friend..
> <http://www.physci.org/codes/javafaq.jsp#exact>
>
> HTH


OK, I'll post the complete code. I trimmed the code for you
so that you may be able to easily grasp what is done in the code.
Here are the 2 files : serial6.java(writer) and serial4.java(reader)
///////////////////serial6.java///////////////
import java.io.*;

public class serial6
 {
    FileOutputStream fos = null;
    FileInputStream fis = null;
    ObjectOutputStream oos = null;
   File ff;
  public serial6()
   {
     try
      {
      MyClass1 obj1 = new MyClass1("sasas",12);
      MyClass1 obj2 = new MyClass1("d",12);
     try
     {
      ff=new File("serial133.txt");
      if(ff.isFile())
      {
       System.out.println("exists");
      }
      else
      {
       System.out.println("not exists");
      }

      fis = new FileInputStream("serial133.txt");
      fis.close();
      fos = new FileOutputStream("serial133.txt",true);
       System.out.println("not exists");



     }
     catch(FileNotFoundException e)
     {
      fos = new FileOutputStream("serial133.txt");

     }



     oos = new ObjectOutputStream(fos);
      oos.writeObject(obj1);
     //  oos.writeObject(obj1);



      } catch( IOException e)
       {
       }

       try
        {
          oos.close();
        } catch(IOException e) {

        }
   }

  public serial6(int i)
   {
     try
      {

  FileOutputStream fos1 = new FileOutputStream("serial33.txt",true);
      } catch(IOException e) {
      }
   }
  public static void main(String args[])


     serial6 sr = new serial6(1);
      int ch =1;

     // while(true)
       {
         switch(ch)
          {
            case 1:
             serial6 sr1 = new serial6();

          }
       }
   }
 }

//  import java.io.*;

class MyClass1 extends Object implements Serializable
{

 String name;
 int roll;
 MyClass1(String a,int b)
 {
  this.name=a;
  this.roll=b;

 }
}
/////////////serial4.java///////////////////////
import java.io.*;

public class serial4
 {
   public static void main(String args[])
    {
      FileInputStream fis = null;
      ObjectInputStream ois = null;
      MyClass1 obj2 =null;
      try


          fis = new FileInputStream("serial233.txt");
         ois = new ObjectInputStream(new BufferedInputStream(fis));


           obj2 = (MyClass1)ois.readObject();

           System.out.println(obj2.toString());

           obj2 = (MyClass1)ois.readObject();

           System.out.println(obj2.toString());


       } catch(ClassNotFoundException e) {
         e.printStackTrace(System.err);
         System.exit(1);

       } catch(EOFException e) {

        System.out.println("Eof reached");
         System.exit(1);
       } catch(IOException e) {
        e.printStackTrace(System.err);
         System.exit(1);
       }

       try
        {
          ois.close();
          fis.close();

        }catch(IOException e) {
         e.printStackTrace(System.err);
         System.exit(1);
        }
    }
 }



--
Madhur Ahuja [madhur<underscore>ahuja<at>yahoo<dot>com]

Homepage & other stuff
http://madhur.netfirms.com









== 4 of 4 ==
Date:   Sat,   Sep 18 2004 12:46 pm
From: "Madhur Ahuja" <[EMAIL PROTECTED]> 

Michael Borgwardt <[EMAIL PROTECTED]> wrote:
> Madhur Ahuja wrote:
>> I have been given the task of doing simple file handling in java.
>> i.e. I want to write set of records to a file and read them.
>> The problem is that writeObject function produces inconsistent
>> results when we write a series of records in one session and when
>> we write same number of records by running the program again and
>> again i.e. appending.
>> The file size differs in above 2 cases.
>>
>> Thus reading the records produces this exception:
>> StreamCorruptedException
>>
>> This exception occurs only when we read from the file in which data
>> has been appended.
>> The exception doesnt occurs if we write to file only once and then
>> read.
>
> That's because ObjectOutputStream doesn't just "write objects", it
> first writes a header, and ObjectInputStream doesn't like
> encountering that header in the middle of its input.

Thanks, I didn't knew this.

> In think Paul is overstating the case, but you should be aware that
> you will run into problems reading the serialized data when you
> change the definitions of the classes you've serialized.
>
> Anyway, in order to get this appending to work, you'd have to use
> separate ObjectInputStreams for each "segment" (i.e. each part of
> the file that was written by a separate ObjectOutputStream).
> This can be done be prepending each of these segments with an
> integer containing the number of "records" to read, or by ending
> each segment with a special object that tells you that you now
> have to use a new ObjectInputStream.

Thanks for the suggestions. The first method(integers) looks nice.
But I am not able to understand second method. What could be that
special object , could it be for example an object with all zero fields.
So that when I read that object , and start a new ObjectInputStream whenever
I encounter object with null values.

I'll keep u updated about the improvement.


--
Madhur Ahuja [madhur<underscore>ahuja<at>yahoo<dot>com]

Homepage & other stuff
http://madhur.netfirms.com










==========================================================================
TOPIC: Java SSH / Telnet client Source
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/9783da10290de218
==========================================================================

== 1 of 3 ==
Date:   Sat,   Sep 18 2004 8:17 am
From: [EMAIL PROTECTED] (Ted) 

Hi all,

I am trying to create a ssh/telnet client as a Java application.
I am new to network programming but I have gathered some tutorials
which have helped me get a grip with it.
My question is, does anybody know where I might find some tutorials or
code that might melp me in learning to create such an application?

Any help at all would be much aprechiated.

Kind Regards,
Ted



== 2 of 3 ==
Date:   Sat,   Sep 18 2004 8:55 am
From: Sudsy <[EMAIL PROTECTED]> 

Ted wrote:
> Hi all,
> 
> I am trying to create a ssh/telnet client as a Java application.
<snip>

Why? People have already travelled this road. Try this link:
<http://javassl.org>




== 3 of 3 ==
Date:   Sat,   Sep 18 2004 12:58 pm
From: Sudsy <[EMAIL PROTECTED]> 

Sudsy wrote:
> Ted wrote:
<snip>
> Why? People have already travelled this road. Try this link:
> <http://javassl.org>

Oops! That should (of course) read:
<http://javassh.org>





==========================================================================
TOPIC: Java trick
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/bfd25be52dc6a3ad
==========================================================================

== 1 of 13 ==
Date:   Sat,   Sep 18 2004 8:27 am
From: Joona I Palaste <[EMAIL PROTECTED]> 

Babu Kalakrishnan <[EMAIL PROTECTED]> scribbled the following:
> Tor Iver Wilhelmsen wrote:
>> "Adam" <[EMAIL PROTECTED]> writes:
>> 
>>>This will compile and run correctly,
>>>even though foo() is not static.
>> 
>> IIRC, it's because the member method foo() is "synthesized" into the C
>> method
>> 
>> CSomeClass_foo(CsomeClass* this) {
>> 
>> }
>> 
>> and your code doesn't use "this" for anything.
>> 
>> Methods in Java are "real" member methods.
>> 
>> To the OP: Whether you get the static member's value or a
>> NullPointerException depends on which runtime you use: There was a
>> change-note for one version (I seem to recall) that spoke of a change
>> regarding whether your code should give a NPE at runtime or not.

> I'm curious about this too. I thought the compiler was the one which 
> would automatically convert the instance based reference to a class 
> reference. In which case how would the runtime know about the instance 
> at all ? (to check for null)

Isn't the implementation even *required* by the JLS to ignore the value
of the reference (null, same class object, subclass object...)
completely and only use its type? In which case whatever gives a
NullPointerException when calling a static method through null doesn't
deserve to call itself Java.

-- 
/-- Joona Palaste ([EMAIL PROTECTED]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Ice cream sales somehow cause drownings: both happen in summer."
   - Antti Voipio & Arto Wikla



== 2 of 13 ==
Date:   Sat,   Sep 18 2004 8:32 am
From: "Thomas G. Marshall" <[EMAIL PROTECTED]> 

Lee Fesperman coughed up:
> Thomas G. Marshall wrote:
>>
>> Michael Borgwardt coughed up:
>>> Thomas G. Marshall wrote:
>>>> The reason it works is that a variable to a class object of any
>>>> value can still yield access to a static.
>>>
>>> Actually, there is no object involved at any point. The *compiler*
>>
>> [snip]
>>
>> You're right.  What I really should have said was a "variable of
>> reference of any value", not object.
>>
>> Basically, given the declaration & definition:
>>
>>         {Type} {Variable Name} = {reference};
>>
>> *Regardless* of the value of {reference},
>>
>>     {reference}.{static id}
>>
>> yields the same thing as
>>
>>     {Type}.{static id}
>
> It's simply a reference, you don't need a variable at all. It is any
> expression producing a reference. It could be a method returning a
> reference or even:
>
>   ((Type) null).{static id}
>
> The static can be a field or a method.


Your example is good, and it's one I've used before, except that your
explanation is missing how the thing is declared, which is why it isn't
about the reference.

The variable is declared with a type somewhere, or passed in as a formal
parameter of some type, etc.  It is that type that determines the static
used, not the actual polymorphised object underneath.

As Michael Borgwardt perfectly pointed out, it is not the reference (object)
per se:

        Michael Borgwardt:
        "ClassA reference = new SubClassOfClassA();
        System.out.println(reference.staticVariable);

        is equivalent to

        System.out.println(ClassA.staticVariable);

        NOT to

        System.out.println(SubClassOfClassA.staticVariable);"

Because as he puts it, it's the compiler that did the work.


-- 
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides





== 3 of 13 ==
Date:   Sat,   Sep 18 2004 8:45 am
From: "Thomas G. Marshall" <[EMAIL PROTECTED]> 

Joona I Palaste coughed up:
> Babu Kalakrishnan <[EMAIL PROTECTED]> scribbled the following:
>> Tor Iver Wilhelmsen wrote:
>>> "Adam" <[EMAIL PROTECTED]> writes:
>>>
>>>> This will compile and run correctly,
>>>> even though foo() is not static.
>>>
>>> IIRC, it's because the member method foo() is "synthesized" into
>>> the C method
>>>
>>> CSomeClass_foo(CsomeClass* this) {
>>>
>>> }
>>>
>>> and your code doesn't use "this" for anything.
>>>
>>> Methods in Java are "real" member methods.
>>>
>>> To the OP: Whether you get the static member's value or a
>>> NullPointerException depends on which runtime you use: There was a
>>> change-note for one version (I seem to recall) that spoke of a
>>> change regarding whether your code should give a NPE at runtime or
>>> not.
>
>> I'm curious about this too. I thought the compiler was the one which
>> would automatically convert the instance based reference to a class
>> reference. In which case how would the runtime know about the
>> instance at all ? (to check for null)
>
> Isn't the implementation even *required* by the JLS to ignore the
> value of the reference (null, same class object, subclass object...)
> completely and only use its type?

I thought so.

But a source of arguments seem to arise (that I've seen) as to what "type"
really means when you are referring to polymorphized types.  I'm accepting
of either way:

In this:

        Super sub = new Sub();

Is the terminology we use for the "type" of the reference held in sub
referring to "Super" or "Sub"?  The rule as you (and others) have stated it
says that the reference object just doesn't matter and that the static
belongs to Super.  Which is what is meant by the reference's type in that
case.

But arguments seem to spring up when people use the term Type to mean the
type of the polymorphized object.  Beats me.  {shrug with palms up}  I
personally accept both ways.


> In which case whatever gives a
> NullPointerException when calling a static method through null doesn't
> deserve to call itself Java.

-- 
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides





== 4 of 13 ==
Date:   Sat,   Sep 18 2004 8:48 am
From: Joona I Palaste <[EMAIL PROTECTED]> 

Thomas G. Marshall <[EMAIL PROTECTED]> scribbled the following:
> Joona I Palaste coughed up:
>> Babu Kalakrishnan <[EMAIL PROTECTED]> scribbled the following:
>>> I'm curious about this too. I thought the compiler was the one which
>>> would automatically convert the instance based reference to a class
>>> reference. In which case how would the runtime know about the
>>> instance at all ? (to check for null)
>>
>> Isn't the implementation even *required* by the JLS to ignore the
>> value of the reference (null, same class object, subclass object...)
>> completely and only use its type?

> I thought so.

> But a source of arguments seem to arise (that I've seen) as to what "type"
> really means when you are referring to polymorphized types.  I'm accepting
> of either way:

> In this:

>         Super sub = new Sub();

> Is the terminology we use for the "type" of the reference held in sub
> referring to "Super" or "Sub"?  The rule as you (and others) have stated it
> says that the reference object just doesn't matter and that the static
> belongs to Super.  Which is what is meant by the reference's type in that
> case.

> But arguments seem to spring up when people use the term Type to mean the
> type of the polymorphized object.  Beats me.  {shrug with palms up}  I
> personally accept both ways.

Because of this I have a Java-specific terminology that makes things
clear. The fundamental rule is:
Objects have class. References have type.
In the above, the type of sub is Super. The class of the object that sub
refers to is Sub.
Types and classes have an "is-assignable-to" relationship. A class
is-assignable-to a type that is the type of the same class, a type of
any of its superclasses, or a type of any interface it implements.

-- 
/-- Joona Palaste ([EMAIL PROTECTED]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Hasta la Vista, Abie!"
   - Bart Simpson



== 5 of 13 ==
Date:   Sat,   Sep 18 2004 8:52 am
From: "Thomas G. Marshall" <[EMAIL PROTECTED]> 

Joona I Palaste coughed up:
> Thomas G. Marshall
> <[EMAIL PROTECTED]> scribbled the
> following:
>> Joona I Palaste coughed up:
>>> Babu Kalakrishnan <[EMAIL PROTECTED]> scribbled the following:
>>>> I'm curious about this too. I thought the compiler was the one
>>>> which would automatically convert the instance based reference to
>>>> a class reference. In which case how would the runtime know about
>>>> the instance at all ? (to check for null)
>>>
>>> Isn't the implementation even *required* by the JLS to ignore the
>>> value of the reference (null, same class object, subclass object...)
>>> completely and only use its type?
>
>> I thought so.
>
>> But a source of arguments seem to arise (that I've seen) as to what
>> "type" really means when you are referring to polymorphized types.
>> I'm accepting of either way:
>
>> In this:
>
>>         Super sub = new Sub();
>
>> Is the terminology we use for the "type" of the reference held in sub
>> referring to "Super" or "Sub"?  The rule as you (and others) have
>> stated it says that the reference object just doesn't matter and
>> that the static belongs to Super.  Which is what is meant by the
>> reference's type in that case.
>
>> But arguments seem to spring up when people use the term Type to
>> mean the type of the polymorphized object.  Beats me.  {shrug with
>> palms up}  I personally accept both ways.
>
> Because of this I have a Java-specific terminology that makes things
> clear. The fundamental rule is:
> Objects have class. References have type.
> In the above, the type of sub is Super. The class of the object that
> sub
> refers to is Sub.
> Types and classes have an "is-assignable-to" relationship. A class
> is-assignable-to a type that is the type of the same class, a type of
> any of its superclasses, or a type of any interface it implements.

Why is that Java-specific?

For yucks, I posted my terminology question on c.o, to see how badly the
purists yell at me :)

-- 
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides





== 6 of 13 ==
Date:   Sat,   Sep 18 2004 8:55 am
From: Joona I Palaste <[EMAIL PROTECTED]> 

Thomas G. Marshall <[EMAIL PROTECTED]> scribbled the following:
> Joona I Palaste coughed up:
>> Thomas G. Marshall
>> <[EMAIL PROTECTED]> scribbled the
>> following:
>>> Joona I Palaste coughed up:
>>>> Babu Kalakrishnan <[EMAIL PROTECTED]> scribbled the following:
>>>>> I'm curious about this too. I thought the compiler was the one
>>>>> which would automatically convert the instance based reference to
>>>>> a class reference. In which case how would the runtime know about
>>>>> the instance at all ? (to check for null)
>>>>
>>>> Isn't the implementation even *required* by the JLS to ignore the
>>>> value of the reference (null, same class object, subclass object...)
>>>> completely and only use its type?
>>
>>> I thought so.
>>
>>> But a source of arguments seem to arise (that I've seen) as to what
>>> "type" really means when you are referring to polymorphized types.
>>> I'm accepting of either way:
>>
>>> In this:
>>
>>>         Super sub = new Sub();
>>
>>> Is the terminology we use for the "type" of the reference held in sub
>>> referring to "Super" or "Sub"?  The rule as you (and others) have
>>> stated it says that the reference object just doesn't matter and
>>> that the static belongs to Super.  Which is what is meant by the
>>> reference's type in that case.
>>
>>> But arguments seem to spring up when people use the term Type to
>>> mean the type of the polymorphized object.  Beats me.  {shrug with
>>> palms up}  I personally accept both ways.
>>
>> Because of this I have a Java-specific terminology that makes things
>> clear. The fundamental rule is:
>> Objects have class. References have type.
>> In the above, the type of sub is Super. The class of the object that
>> sub
>> refers to is Sub.
>> Types and classes have an "is-assignable-to" relationship. A class
>> is-assignable-to a type that is the type of the same class, a type of
>> any of its superclasses, or a type of any interface it implements.

> Why is that Java-specific?

It's not, actually. It's specific to any language with the same
polymorphic type system as Java. But I couldn't come up with any others
having the exact same system.

-- 
/-- Joona Palaste ([EMAIL PROTECTED]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Last year he disrespected me - and then he showed lack of respect."
   - Anthony Mason



== 7 of 13 ==
Date:   Sat,   Sep 18 2004 12:01 pm
From: "Gary Labowitz" <[EMAIL PROTECTED]> 

"Thomas G. Marshall" <[EMAIL PROTECTED]>
wrote in message news:[EMAIL PROTECTED]
> Michael Borgwardt coughed up:
> > Thomas G. Marshall wrote:
> >> The reason it works is that a variable to a class object of any
> >> value can still yield access to a static.
> >
> > Actually, there is no object involved at any point. The *compiler*
>
> {shrug} The *compiler* does everything.
>
>
> > directly inserts a reference to the class for which the variable is
> > declared, so
> > it might work differently than expected if inheritance is involved.
> >
> > ClassA reference = new SubClassOfClassA();
> > System.out.println(reference.staticVariable);
> >
> > is equivalent to
> >
> > System.out.println(ClassA.staticVariable);
> >
> > NOT to
> >
> > System.out.println(SubClassOfClassA.staticVariable);
>
>
> You're right.  What I really should have said was a "variable of reference
> of any value", not object.
>
> Basically, given the declaration & definition:
>
>         {Type} {Variable Name} = {reference};
>
> *Regardless* of the value of {reference},
>
>     {reference}.{static id}
>
> yields the same thing as
>
>     {Type}.{static id}
>
> Which is something I've always thought sloppy about Java.

I sorta object to your using {Type}. etc. The way I teach it would seem to
eliminate the confusion: Ahem....

     Data is referred to based on the class of the reference variable.
     Methods are referred to based on the class of the object.

This means that if a reference variable is declared as class Dummy, then
regardless of whether it addresses an actual object or not (i.e. is Null)
any data referred to with that reference will be located with reference to
the Class, in this case Dummy. So whether it is null, addresses a valid
Dummy object, or a derived class of Dummy it will refer to the static data
in Dummy, because it is a Dummy reference.

Methods work differently, using dynamic dispatch to find the code to be
executed -- based on the object that is being referred to. So if the
reference variable contains null you get a null pointer exception. If the
reference variable refers to an existing object, that object's loaded
methods are searched, proceeding up the inheritance chain if necessary to
find the code to execute. Hence, polymorphism. Even if the reference is
declared as a Base class, it still uses the object's methods.

[This phrasing eliminates my having to go into static/dynamic resolution of
identifiers by the compile process. They are, after all, beginners.]

Make corrections as appropriate.....
-- 
Gary





== 8 of 13 ==
Date:   Sat,   Sep 18 2004 12:02 pm
From: "Gary Labowitz" <[EMAIL PROTECTED]> 

"Michael Borgwardt" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Thomas G. Marshall wrote:
> > Basically, given the declaration & definition:
> >
> >         {Type} {Variable Name} = {reference};
> >
> > *Regardless* of the value of {reference},
> >
> >     {reference}.{static id}
> >
> > yields the same thing as
> >
> >     {Type}.{static id}
> >
> > Which is something I've always thought sloppy about Java.
>
> I (and most knowledgeable people I know) think that static members
> should be accessible only through the class name, not through
> a reference.

Yes, yes, yes, and yes. Please cast my vote for this restriction at the next
committee meeting.
-- 
Gary





== 9 of 13 ==
Date:   Sat,   Sep 18 2004 12:11 pm
From: "Gary Labowitz" <[EMAIL PROTECTED]> 

"Gary Labowitz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Thomas G. Marshall"
<[EMAIL PROTECTED]>
> wrote in message news:[EMAIL PROTECTED]
> > Michael Borgwardt coughed up:
> > > Thomas G. Marshall wrote:
> > >> The reason it works is that a variable to a class object of any
> > >> value can still yield access to a static.
> > >
> > > Actually, there is no object involved at any point. The *compiler*
> >
> > {shrug} The *compiler* does everything.
> >
> >
> > > directly inserts a reference to the class for which the variable is
> > > declared, so
> > > it might work differently than expected if inheritance is involved.
> > >
> > > ClassA reference = new SubClassOfClassA();
> > > System.out.println(reference.staticVariable);
> > >
> > > is equivalent to
> > >
> > > System.out.println(ClassA.staticVariable);
> > >
> > > NOT to
> > >
> > > System.out.println(SubClassOfClassA.staticVariable);
> >
> >
> > You're right.  What I really should have said was a "variable of
reference
> > of any value", not object.
> >
> > Basically, given the declaration & definition:
> >
> >         {Type} {Variable Name} = {reference};
> >
> > *Regardless* of the value of {reference},
> >
> >     {reference}.{static id}
> >
> > yields the same thing as
> >
> >     {Type}.{static id}
> >
> > Which is something I've always thought sloppy about Java.
>
> I sorta object to your using {Type}. etc. The way I teach it would seem to
> eliminate the confusion: Ahem....
>
>      Data is referred to based on the class of the reference variable.
>      Methods are referred to based on the class of the object.
>
> This means that if a reference variable is declared as class Dummy, then
> regardless of whether it addresses an actual object or not (i.e. is Null)
> any data referred to with that reference will be located with reference to
> the Class, in this case Dummy. So whether it is null, addresses a valid
> Dummy object, or a derived class of Dummy it will refer to the static data
> in Dummy, because it is a Dummy reference.
>
> Methods work differently, using dynamic dispatch to find the code to be
> executed -- based on the object that is being referred to. So if the

First correction: after "referred to." insert "except if the method is
static." etc.

> reference variable contains null you get a null pointer exception. If the
> reference variable refers to an existing object, that object's loaded
> methods are searched, proceeding up the inheritance chain if necessary to
> find the code to execute. Hence, polymorphism. Even if the reference is
> declared as a Base class, it still uses the object's methods.
>
> [This phrasing eliminates my having to go into static/dynamic resolution
of
> identifiers by the compile process. They are, after all, beginners.]
>
> Make corrections as appropriate.....
> -- 
> Gary
>
>





== 10 of 13 ==
Date:   Sat,   Sep 18 2004 12:28 pm
From: Joona I Palaste <[EMAIL PROTECTED]> 

Gary Labowitz <[EMAIL PROTECTED]> scribbled the following:
> "Michael Borgwardt" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> I (and most knowledgeable people I know) think that static members
>> should be accessible only through the class name, not through
>> a reference.

> Yes, yes, yes, and yes. Please cast my vote for this restriction at the next
> committee meeting.

Mine, too. Cast one for my sister and brother and my parents too. (They
don't know enough about programming to care. My sister's boyfriend
does.)

-- 
/-- Joona Palaste ([EMAIL PROTECTED]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
   - Andy Capp



== 11 of 13 ==
Date:   Sat,   Sep 18 2004 12:34 pm
From: "Thomas G. Marshall" <[EMAIL PROTECTED]> 

Gary Labowitz coughed up:
> "Thomas G. Marshall"
> <[EMAIL PROTECTED]> wrote in
> message news:[EMAIL PROTECTED]
>> Michael Borgwardt coughed up:
>>> Thomas G. Marshall wrote:
>>>> The reason it works is that a variable to a class object of any
>>>> value can still yield access to a static.
>>>
>>> Actually, there is no object involved at any point. The *compiler*
>>
>> {shrug} The *compiler* does everything.
>>
>>
>>> directly inserts a reference to the class for which the variable is
>>> declared, so
>>> it might work differently than expected if inheritance is involved.
>>>
>>> ClassA reference = new SubClassOfClassA();
>>> System.out.println(reference.staticVariable);
>>>
>>> is equivalent to
>>>
>>> System.out.println(ClassA.staticVariable);
>>>
>>> NOT to
>>>
>>> System.out.println(SubClassOfClassA.staticVariable);
>>
>>
>> You're right.  What I really should have said was a "variable of
>> reference of any value", not object.
>>
>> Basically, given the declaration & definition:
>>
>>         {Type} {Variable Name} = {reference};
>>
>> *Regardless* of the value of {reference},
>>
>>     {reference}.{static id}
>>
>> yields the same thing as
>>
>>     {Type}.{static id}
>>
>> Which is something I've always thought sloppy about Java.
>
> I sorta object to your using {Type}. etc. The way I teach it would
> seem to eliminate the confusion: Ahem....
>
>      Data is referred to based on the class of the reference variable.
>      Methods are referred to based on the class of the object.

No, you're wrong, and you've made it even more confusing.

1. Static data OR METHODS are referred to based upon the /declaration/ of
the Class (of the reference variable for example).

2. Non static data are ALSO referred to based upon the declaration of the
Class.

3. Non static methods are referred to based upon the type of the
polymorphized object underneath.

This is the run result:

        $ run experiments.simple.StaticPolyAccess
        Top static string
        Top static method
        Top non static string
        Bottom nonstatic method

And this is the source:

<SOURCE>
package experiments.simple;

class Top
{
    static String staticstring = "Top static string";
    static void staticmethod() {System.out.println("Top static method");}
    String nonstaticstring = "Top non static string";
    void nonstaticmethod() {System.out.println("Top nonstatic method");}
}

class Bottom extends Top
{
    static String staticstring = "Bottom static string";
    static void staticmethod() {System.out.println("Bottom static method");}
    String nonstaticstring = "Bottom non static string";
    void nonstaticmethod() {System.out.println("Bottom nonstatic method");}
}

public class StaticPolyAccess
{
    public static void main(String[] args)
    {
        Top bottom = new Bottom();
        System.out.println(bottom.staticstring);
        bottom.staticmethod();
        System.out.println(bottom.nonstaticstring);
        bottom.nonstaticmethod();
    }
}
</SOURCE>


...[rip]...

> Make corrections as appropriate.....

Done. :)

-- 
Framsticks.  3D Artificial Life evolution.  You can see the creatures
that evolve and how they interact, hunt, swim, etc. (Unaffiliated with
me). http://www.frams.alife.pl/





== 12 of 13 ==
Date:   Sat,   Sep 18 2004 12:35 pm
From: "Thomas G. Marshall" <[EMAIL PROTECTED]> 

Joona I Palaste coughed up:
> Gary Labowitz <[EMAIL PROTECTED]> scribbled the following:
>> "Michael Borgwardt" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> I (and most knowledgeable people I know) think that static members
>>> should be accessible only through the class name, not through
>>> a reference.
>
>> Yes, yes, yes, and yes. Please cast my vote for this restriction at
>> the next committee meeting.
>
> Mine, too. Cast one for my sister and brother and my parents too.
> (They don't know enough about programming to care. My sister's
> boyfriend does.)

I'm fairly certain that my two golden retreivers agree with us as well.
Heck, I'll go ask...

-- 
Framsticks.  3D Artificial Life evolution.  You can see the creatures
that evolve and how they interact, hunt, swim, etc. (Unaffiliated with
me). http://www.frams.alife.pl/





== 13 of 13 ==
Date:   Sat,   Sep 18 2004 1:07 pm
From: Lee Fesperman <[EMAIL PROTECTED]> 

Thomas G. Marshall wrote:
> 
> Lee Fesperman coughed up:
> > Thomas G. Marshall wrote:
> >>
> >> Michael Borgwardt coughed up:
> >>> Thomas G. Marshall wrote:
> >>>> The reason it works is that a variable to a class object of any
> >>>> value can still yield access to a static.
> >>>
> >>> Actually, there is no object involved at any point. The *compiler*
> >>
> >> [snip]
> >>
> >> You're right.  What I really should have said was a "variable of
> >> reference of any value", not object.
> >>
> >> Basically, given the declaration & definition:
> >>
> >>         {Type} {Variable Name} = {reference};
> >>
> >> *Regardless* of the value of {reference},
> >>
> >>     {reference}.{static id}
> >>
> >> yields the same thing as
> >>
> >>     {Type}.{static id}
> >
> > It's simply a reference, you don't need a variable at all. It is any
> > expression producing a reference. It could be a method returning a
> > reference or even:
> >
> >   ((Type) null).{static id}
> >
> > The static can be a field or a method.
> 
> Your example is good, and it's one I've used before, except that your
> explanation is missing how the thing is declared, which is why it isn't
> about the reference.
> 
> The variable is declared with a type somewhere, or passed in as a formal
> parameter of some type, etc.  It is that type that determines the static
> used, not the actual polymorphised object underneath.

You completely missed my point. It is about the reference. A variable is not 
necessary. 
There is no 'thing' declared. Try these:

  new String().valueOf("*");

  "".valueOf("*");

  ((String) null).valueOf("*");

  String.valueOf("").valueOf("*");

There are no variables involved. These all use reference expressions. The compiler 
uses 
the type of the reference expression to call the appropriate static method -- 
String.valueOf().

-- 
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS  (http://www.firstsql.com)




==========================================================================
TOPIC: Pausing a Swing Worker Thread?
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/d5da19ea5521b080
==========================================================================

== 1 of 1 ==
Date:   Sat,   Sep 18 2004 8:55 am
From: "xarax" <[EMAIL PROTECTED]> 

"C-man" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Does anybody out there know how to pause/resume a Swing Worker thread. I
> have implemented my program to be able to cancel the thread by checking if
> it has been interrupted() in my code. but how do I pause the thread. If I
> were to use wait() and notify() how to I implement that? Do I have to add a
> new Function to SwingWorker.java?

ISTR SwingWorker is an abstract class. You must extend
it with your own methods anyway. You'll have to decide
what it means to pause the thread, since SwingWorker
is supposed to finish its task and then post a Runnable
to the AWT Event Dispatch Thread (using
SwingUtilities.invokeLater(Runnable)) to notify completion.

-- 
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS for FREE!







==========================================================================
TOPIC: Hello, googs, congratulations!
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/79188f21565e7f7
==========================================================================

== 1 of 1 ==
Date:   Sat,   Sep 18 2004 8:57 am
From: "Thomas G. Marshall" <[EMAIL PROTECTED]> 


You have got to be kidding.

Actually I have mixed feelings about this.  If someone is stupid enough to
run an .exe that they get off usenet, then perhaps it's a form of
techno-Darwinism.

Perhaps I'm equally stupid for replying to this.  Oh well----I'm in an odd
mood today....


-- 
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides






==========================================================================
TOPIC: How to incremet IndetAddress / IP numbers
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/94897e32234ceaaf
==========================================================================

== 1 of 1 ==
Date:   Sat,   Sep 18 2004 9:04 am
From: Paul Lutus <[EMAIL PROTECTED]> 

John B. Matthews wrote:

/ ...

>> > I had missed this thread on c.l.j.h. Before seeing your very
>> > illuminating code, I had tried the following:
>> > 
> [my erroneous code deleted]
>> > 
>> > It seems to work, but I'm vaguely uneasy about relying on
>> > wrap-around with signed integer arithmetic.
>> 
>> There is no need to use this approach. Just increment an integer or a
>> long, dismantle a copy into byte components, and use the bytes to
>> construct the IP address, as in my prior code example.
> 
> Yes, I see. You proposed something like this:
> 
>     public static InetAddress toInetAddress(int addr)
>     throws UnknownHostException {
>         byte[] b = new byte[4];
>         b[3] = (byte) addr;
>         addr >>= 8;
>         b[2] = (byte) addr;
>         addr >>= 8;
>         b[1] = (byte) addr;
>         addr >>= 8;
>         b[0] = (byte) addr;
>         return InetAddress.getByAddress(b);
>     }

Yes. Kind of ugly, isn't it? How about this instead:

      byte[] b = new byte[4];
      int addr = 0x12345678;
      for(int i = 3;i >= 0;i--) {
         b[i] = (byte) addr;
         addr >>= 8;
      }

This is one of those code examples where creating a loop only marginally
improves its looks or its length.

> 
> The inverse would just combine the bytes:
> 
>     public static int toInt(InetAddress ip)
>     throws UnknownHostException {
>         byte[] b = ip.getAddress();
>         int addr = 0;
>         for (int i = 0; i < 4; i++) {
>             addr |= (((int) b[i]) & 0xff) << (8 * (3 - i));
>         }
>         return addr;
>     }
> 
> For reference, my original code was erroneous. The correction is
> as follows:
> 
>     public static InetAddress inc(InetAddress ip) throws
>     UnknownHostException {
>         byte[] b = ip.getAddress();
>         b[3]++;
>         if (b[3] == 0) {
>             b[2]++;
>             if (b[2] == 0) {
>                 b[1]++;
>                 if (b[1] == 0) {
>                     b[0]++;
>                 }
>             }
>         }
>         return InetAddress.getByAddress(b);
>     }
> 
> Sorry, I just can't resist bit-twidling in every language I
> learn:-)

Cute, but IMHO the form that increments an integer is much cleaner. All but
the part where you must convert to four bytes. :)

On that topic, I can't believe there is no InetAddress creation method that
accepts an integer.

-- 
Paul Lutus
http://www.arachnoid.com





==========================================================================
TOPIC: Noobie looking for relevant Java knowledge
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/289f1f05fa606891
==========================================================================

== 1 of 1 ==
Date:   Sat,   Sep 18 2004 9:10 am
From: "Thomas G. Marshall" <[EMAIL PROTECTED]> 

Pingo coughed up:
> Hi  y'all
> I'm just beginning my journey into the world of Java programming. The
> amount of help and information on the net is vast and trying to
> discern what is relevant and necessary can be confusing to say the
> least.
> If anyone can recommend (tried and trusted) texts, websites,  etc that
> they  have used I would be most grateful.
> Thanks for any help.


Check out the Java Ranch.  They have a cute way of presenting the various
issues related to java.  They have a section dedicated to code examples too.
It's worth a click-through.

There are a /lot/ of folks in that organization dedicated to helping java
"dudes".

http://www.javaranch.com/



-- 
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides






==========================================================================
TOPIC: Memory leakage problem with a database application
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/cd24fb0a93e5b285
==========================================================================

== 1 of 1 ==
Date:   Sat,   Sep 18 2004 9:11 am
From: [EMAIL PROTECTED] (Devian) 

Hi,

BK I write a simple application to test my real application's logic
and in that application I'm facing the same problem again.I want to
tell about this program.I have a main frame(Frame2) and in that frame
Frame1 is opened by clicking the related treenode.Frame1's close
operation is set to DISPOSE_ON_CLOSE and Frame1 has a dispose
monitor.When Frame1 is opened memory usage is increasing but when
Frame1 is closed by clicking X button of the window memory never
released.I dont understand what I'm doing wrong?Here is the code of
Frame2:

public class Frame2 extends JFrame {
  XYLayout xYLayout1 = new XYLayout();
  

Frame1 frm = null;
  JScrollPane jScrollPane1 = new JScrollPane();
  DefaultMutableTreeNode trNavForms =  new
DefaultMutableTreeNode("User Forms");
  JTree jTree1 = new JTree(trNavForms);
  databaseapp.NodeInfo fTemp = new NodeInfo();
}




==========================================================================
TOPIC: struts & restarting Tomcat
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/5bee53f53da7265c
==========================================================================

== 1 of 1 ==
Date:   Sat,   Sep 18 2004 9:40 am
From: [EMAIL PROTECTED] (Mike) 



I'm developing a struts application and the only way I've found for a
change in the action class to be recognized is to restart Tomcat.

Is there an easier way?








==========================================================================
TOPIC: xerces and xalan
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/6f2ec969c996f8b1
==========================================================================

== 1 of 2 ==
Date:   Sat,   Sep 18 2004 10:58 am
From: "sp" <[EMAIL PROTECTED]> 

I don't understand the difference from xalan and xerces.
Xalan implements Xpath and xerces not? Are two different JAXP
implementation?





== 2 of 2 ==
Date:   Sat,   Sep 18 2004 1:00 pm
From: Sudsy <[EMAIL PROTECTED]> 

sp wrote:
> I don't understand the difference from xalan and xerces.
> Xalan implements Xpath and xerces not? Are two different JAXP
> implementation?

Xalan lets you perform translations (XSLT). It also implements
XPath.





==========================================================================
TOPIC: what u program?
http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/ee20f99e67fd5410
==========================================================================

== 1 of 1 ==
Date:   Sat,   Sep 18 2004 11:17 am
From: Michael Borgwardt <[EMAIL PROTECTED]> 

Tor Iver Wilhelmsen wrote:
>>It has been since 1993.
> 
> Yes, but all these recent newbie questions to cljp are the effect of
> the "old" September principle.

A stronger version of it, in fact, since the group's topic is directly
related to many students' curriculum.



=======================================================================

You received this message because you are subscribed to the
Google Groups "comp.lang.java.programmer".  

comp.lang.java.programmer
[EMAIL PROTECTED]

Change your subscription type & other preferences:
* click http://groups-beta.google.com/group/comp.lang.java.programmer/subscribe

Report abuse:
* send email explaining the problem to [EMAIL PROTECTED]

Unsubscribe:
* click http://groups-beta.google.com/group/comp.lang.java.programmer/subscribe


=======================================================================
Google Groups: http://groups-beta.google.com 



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/BCfwlB/TM
--------------------------------------------------------------------~-> 

<a href=http://English-12948197573.SpamPoison.com>Fight Spam! Click Here!</a> 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/kumpulan/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

Reply via email to