Non-blocking and semi-blocking Sockets class.

Discussion in 'Java' started by nukleus, Jan 18, 2007.

  1. nukleus

    nukleus Guest

    I am working on a network related application.
    There is an issues with sockets blocking and how to handle it.
    There are several approaches:

    1. Use blocking sockets and set timeout.
    In this case, if connection is lost or socket object is not created
    yet as we are in the middle of connect operation, the process
    effectively hangs and user has to wait for timeout expiration.
    Not a very desirable approach.

    2. Use byte reads and buffered input stream and check
    if data is available. In case of text, if it is, then read it
    until you get a line separator character, and then return
    a text line to a caller of getLine().

    If eof condition happens, returned by -1 on a read,
    that could mean the server closed a connection for whatever reason.
    In this case, simply return. Non blocking operation.

    If there is nothing in the buffer, but you are waiting for a server
    standard response or data, you loop untill such data arrives.
    This is blocking operation and has all sorts of nasty side effects.
    The loop uses a separate timer from the socket timeout timer.
    When that timer expires, the getLine() returns with error or
    throws a TimeOut exception.

    But it could be resolved usint a separate thread for a blocking socket.

    One of the alternatives here is to use a byte read loop with that
    could be interrupted, say, if user realizes there is error, and hits
    Cancel button. In this case, the event handler sets the event,
    that is tested in a read loop, and if the flag is set, the loop
    terminates.
    This is interruptible blocking operation, which should effectively
    behave like a non-blocking operation for practical purposes.

    3. Blocking socket running as a separate thread.
    This seems to be the best overall approach, as we can allow
    the socket thread to block, but we are not block on the main
    thread level and all our gui stuff operations as advertised.

    But there are issues with this. Since you are running a separate
    thread, how do you tell it what command we issue to the server
    and how does the main thread knows when operation is completed
    successfuly. Anotherwords, how do you exchange the information
    and various error conditions between the main object and the socket?

    From windows C++ standpoint, you can go asynchronous using
    overlapped structures for one thing.

    Question: what is the best approach with java and what are the
    exact steps to design the separate socket thread?
    Do we use Events?
    What happens to Exceptions running in a separate thread that
    need to be communicated to a different thread of different frame object?

    Since we create a separate thread for a socket that has its own
    run() loop and we could be performing either send or receive
    network operation, how do we exchange data between socket
    thread and a parent class?

    4. Fully asynchronous design.
    This design, by definition, is non-blocking.
    The overall architecture may be implemented with a state machine
    approach. In this case, there is never any blocking on a socket
    object. But how do you do it in Java?
    It seems events are the way to go, but how do you set up your
    architecture to do it?

    Related question:
    Anyone can suggest a good state machine design in Java?
    I used my own design in C++ that had a vector of state class
    objects and a state machine iterating code. Each state object
    had a paramter telling it which is the next state to proceed to
    in case of successful result, which state to proceed to in case
    of error result, and which alternative states to proceed to in
    case of minor error conditions, such as incorrect user command
    issued to the server in our situation, or incorrect value of data
    passed to server.

    This design is flexible in that the state machine could even be
    substituted for another state machine, need be. For example,
    if you are trying to send email, and you made a mistake in your
    configuration that tells the server that you are connecting to
    NNTP server, than the server log-in response code would be
    different. In this case, you could switch the state machine on
    the fly and perform the NNTP related operation. This is just
    and abstract example. You wouln't probably want to do that
    in real life. :--}

    Does anyone have any feedback on this all?

    Thanks in advance.
     
    nukleus, Jan 18, 2007
    #1
    1. Advertising

  2. nukleus wrote:
    > I am working on a network related application.
    > There is an issues with sockets blocking and how to handle it.
    > There are several approaches:
    >
    > 1. Use blocking sockets and set timeout.
    > In this case, if connection is lost or socket object is not created
    > yet as we are in the middle of connect operation, the process
    > effectively hangs and user has to wait for timeout expiration.
    > Not a very desirable approach.
    >
    > 2. Use byte reads and buffered input stream and check
    > if data is available. In case of text, if it is, then read it
    > until you get a line separator character, and then return
    > a text line to a caller of getLine().
    >
    > If eof condition happens, returned by -1 on a read,
    > that could mean the server closed a connection for whatever reason.
    > In this case, simply return. Non blocking operation.
    >
    > If there is nothing in the buffer, but you are waiting for a server
    > standard response or data, you loop untill such data arrives.
    > This is blocking operation and has all sorts of nasty side effects.
    > The loop uses a separate timer from the socket timeout timer.
    > When that timer expires, the getLine() returns with error or
    > throws a TimeOut exception.
    >
    > But it could be resolved usint a separate thread for a blocking socket.
    >
    > One of the alternatives here is to use a byte read loop with that
    > could be interrupted, say, if user realizes there is error, and hits
    > Cancel button. In this case, the event handler sets the event,
    > that is tested in a read loop, and if the flag is set, the loop
    > terminates.
    > This is interruptible blocking operation, which should effectively
    > behave like a non-blocking operation for practical purposes.
    >
    > 3. Blocking socket running as a separate thread.
    > This seems to be the best overall approach, as we can allow
    > the socket thread to block, but we are not block on the main
    > thread level and all our gui stuff operations as advertised.
    >
    > But there are issues with this. Since you are running a separate
    > thread, how do you tell it what command we issue to the server
    > and how does the main thread knows when operation is completed
    > successfuly. Anotherwords, how do you exchange the information
    > and various error conditions between the main object and the socket?
    >
    > From windows C++ standpoint, you can go asynchronous using
    > overlapped structures for one thing.
    >
    > Question: what is the best approach with java and what are the
    > exact steps to design the separate socket thread?
    > Do we use Events?
    > What happens to Exceptions running in a separate thread that
    > need to be communicated to a different thread of different frame object?
    >
    > Since we create a separate thread for a socket that has its own
    > run() loop and we could be performing either send or receive
    > network operation, how do we exchange data between socket
    > thread and a parent class?
    >
    > 4. Fully asynchronous design.
    > This design, by definition, is non-blocking.
    > The overall architecture may be implemented with a state machine
    > approach. In this case, there is never any blocking on a socket
    > object. But how do you do it in Java?
    > It seems events are the way to go, but how do you set up your
    > architecture to do it?
    >
    > Related question:
    > Anyone can suggest a good state machine design in Java?
    > I used my own design in C++ that had a vector of state class
    > objects and a state machine iterating code. Each state object
    > had a paramter telling it which is the next state to proceed to
    > in case of successful result, which state to proceed to in case
    > of error result, and which alternative states to proceed to in
    > case of minor error conditions, such as incorrect user command
    > issued to the server in our situation, or incorrect value of data
    > passed to server.
    >
    > This design is flexible in that the state machine could even be
    > substituted for another state machine, need be. For example,
    > if you are trying to send email, and you made a mistake in your
    > configuration that tells the server that you are connecting to
    > NNTP server, than the server log-in response code would be
    > different. In this case, you could switch the state machine on
    > the fly and perform the NNTP related operation. This is just
    > and abstract example. You wouln't probably want to do that
    > in real life. :--}
    >
    > Does anyone have any feedback on this all?
    >
    > Thanks in advance.


    Use 3. I assume your data is some kind of message? Just have a read
    thread that takes in the data and calls methods appropriate to the
    message. The output can be handled from the GUI. The simpler you make
    it the more reliable and maintainable it will be.

    Just my 2 cents.

    --

    Knute Johnson
    email s/nospam/knute/
     
    Knute Johnson, Jan 18, 2007
    #2
    1. Advertising

  3. nukleus

    Karl Uppiano Guest

    "nukleus" <> wrote in message
    news:eomuht$3m3$...
    >I am working on a network related application.
    > There is an issues with sockets blocking and how to handle it.
    > There are several approaches:
    >
    > 1. Use blocking sockets and set timeout.
    > In this case, if connection is lost or socket object is not created
    > yet as we are in the middle of connect operation, the process
    > effectively hangs and user has to wait for timeout expiration.
    > Not a very desirable approach.
    >
    > 2. Use byte reads and buffered input stream and check
    > if data is available. In case of text, if it is, then read it
    > until you get a line separator character, and then return
    > a text line to a caller of getLine().
    >
    > If eof condition happens, returned by -1 on a read,
    > that could mean the server closed a connection for whatever reason.
    > In this case, simply return. Non blocking operation.
    >
    > If there is nothing in the buffer, but you are waiting for a server
    > standard response or data, you loop untill such data arrives.
    > This is blocking operation and has all sorts of nasty side effects.
    > The loop uses a separate timer from the socket timeout timer.
    > When that timer expires, the getLine() returns with error or
    > throws a TimeOut exception.
    >
    > But it could be resolved usint a separate thread for a blocking socket.
    >
    > One of the alternatives here is to use a byte read loop with that
    > could be interrupted, say, if user realizes there is error, and hits
    > Cancel button. In this case, the event handler sets the event,
    > that is tested in a read loop, and if the flag is set, the loop
    > terminates.
    > This is interruptible blocking operation, which should effectively
    > behave like a non-blocking operation for practical purposes.
    >
    > 3. Blocking socket running as a separate thread.
    > This seems to be the best overall approach, as we can allow
    > the socket thread to block, but we are not block on the main
    > thread level and all our gui stuff operations as advertised.
    >
    > But there are issues with this. Since you are running a separate
    > thread, how do you tell it what command we issue to the server
    > and how does the main thread knows when operation is completed
    > successfuly. Anotherwords, how do you exchange the information
    > and various error conditions between the main object and the socket?
    >
    > From windows C++ standpoint, you can go asynchronous using
    > overlapped structures for one thing.
    >
    > Question: what is the best approach with java and what are the
    > exact steps to design the separate socket thread?
    > Do we use Events?
    > What happens to Exceptions running in a separate thread that
    > need to be communicated to a different thread of different frame
    > object?
    >
    > Since we create a separate thread for a socket that has its own
    > run() loop and we could be performing either send or receive
    > network operation, how do we exchange data between socket
    > thread and a parent class?
    >
    > 4. Fully asynchronous design.
    > This design, by definition, is non-blocking.
    > The overall architecture may be implemented with a state machine
    > approach. In this case, there is never any blocking on a socket
    > object. But how do you do it in Java?
    > It seems events are the way to go, but how do you set up your
    > architecture to do it?
    >
    > Related question:
    > Anyone can suggest a good state machine design in Java?
    > I used my own design in C++ that had a vector of state class
    > objects and a state machine iterating code. Each state object
    > had a paramter telling it which is the next state to proceed to
    > in case of successful result, which state to proceed to in case
    > of error result, and which alternative states to proceed to in
    > case of minor error conditions, such as incorrect user command
    > issued to the server in our situation, or incorrect value of data
    > passed to server.
    >
    > This design is flexible in that the state machine could even be
    > substituted for another state machine, need be. For example,
    > if you are trying to send email, and you made a mistake in your
    > configuration that tells the server that you are connecting to
    > NNTP server, than the server log-in response code would be
    > different. In this case, you could switch the state machine on
    > the fly and perform the NNTP related operation. This is just
    > and abstract example. You wouln't probably want to do that
    > in real life. :--}
    >
    > Does anyone have any feedback on this all?
    >
    > Thanks in advance.


    For clients and smaller server applications, Solution 3 seems like the best
    option to me. Your concerns about communicating between threads can be
    solved with standard threading design patterns. Java 1.5 introduced three
    entire packages devoted to thread synchronization (java.util.concurrent,
    java.util.concurrent.atomic and java.util.concurrent.locks). I think you
    need to look into that part of the problem.

    Package java.nio (possibly option 4) is good for server networking
    applications that need to scale massively, but NIO has a pretty steep
    learning curve.

    State machines... I have written lots of them. They usually consist of a
    state variable that might hold a reference to an interface or abstract base
    class that implements the state.

    interface state {
    /**
    * State implementations execute their state,
    * and set a state variable to the "next" state.
    */
    public void execute();
    }


    class stateMachine {
    stateVariable = new state0();

    while(true) {
    stateVariable.execute();
    }
    }

    Obviously, this pseudo code glosses over the details. I would probably make
    the state implementations inner classes of the state machine, so they would
    have access to stateVariable to set it. I might even make the state
    implementations themselves stateless, and static final, so setting the state
    would be a simple assignment of "constants". Maybe enums could represent the
    state. I haven't had to do a state machine since Java 1.5 introduced enums,
    but it sounds promising.
     
    Karl Uppiano, Jan 18, 2007
    #3
  4. Karl Uppiano wrote:
    > "nukleus" <> wrote in message


    > >I am working on a network related application.


    Sorry. Is that the AWT application you were
    referring to, ealier? (another thread, different issue
    re. layouts).

    Because I meant to ask at the time, why the
    application was AWT based, which suggests
    to me that it is very old. Swing was a bit shaky
    in 1.2, but by Java 1.3, it was quite usable.

    Do you need to support older VMs?
    If so, what minimum version?

    Which then brings me (after a big snip) to..

    > ...Java 1.5 introduced three
    > entire packages devoted to thread synchronization (java.util.concurrent,
    > java.util.concurrent.atomic and java.util.concurrent.locks). I think you
    > need to look into that part of the problem.


    ...If you actually need to support the application at
    a specific Java version (pre. 1.5), it might be a good
    idea to mention that on any thread related to the
    application, as people would have to 'think back',
    even to remember what could be supported in 1.4!

    Andrew T.
     
    Andrew Thompson, Jan 18, 2007
    #4
  5. nukleus

    nukleus Guest

    In article <AnDrh.66603$>, Knute Johnson
    <> wrote:
    >nukleus wrote:
    >> I am working on a network related application.
    >> There is an issues with sockets blocking and how to handle it.
    >> There are several approaches:
    >>


    >> 3. Blocking socket running as a separate thread.
    >> This seems to be the best overall approach, as we can allow
    >> the socket thread to block, but we are not block on the main
    >> thread level and all our gui stuff operations as advertised.
    >>
    >> But there are issues with this. Since you are running a separate
    >> thread, how do you tell it what command we issue to the server
    >> and how does the main thread knows when operation is completed
    >> successfuly. Anotherwords, how do you exchange the information
    >> and various error conditions between the main object and the socket?
    >>
    >> Does anyone have any feedback on this all?
    >>
    >> Thanks in advance.

    >
    >Use 3. I assume your data is some kind of message? Just have a read
    >thread that takes in the data and calls methods appropriate to the
    >message. The output can be handled from the GUI. The simpler you make
    >it the more reliable and maintainable it will be.


    Thanks. That is i was thinking of. I'll try.

    >Just my 2 cents.
     
    nukleus, Jan 18, 2007
    #5
  6. nukleus

    nukleus Guest

    In article <CdErh.16731$Ch1.12840@trndny04>, "Karl Uppiano"
    <> wrote:
    >
    >"nukleus" <> wrote in message
    >news:eomuht$3m3$...
    >>I am working on a network related application.
    >> There is an issues with sockets blocking and how to handle it.
    >> There are several approaches:


    >> 3. Blocking socket running as a separate thread.
    >> This seems to be the best overall approach, as we can allow
    >> the socket thread to block, but we are not block on the main
    >> thread level and all our gui stuff operations as advertised.
    >>
    >> But there are issues with this. Since you are running a separate
    >> thread, how do you tell it what command we issue to the server
    >> and how does the main thread knows when operation is completed
    >> successfuly. Anotherwords, how do you exchange the information
    >> and various error conditions between the main object and the socket?


    >> Does anyone have any feedback on this all?
    >>
    >> Thanks in advance.


    >For clients and smaller server applications, Solution 3 seems like the best
    >option to me. Your concerns about communicating between threads can be
    >solved with standard threading design patterns. Java 1.5 introduced three
    >entire packages devoted to thread synchronization (java.util.concurrent,
    >java.util.concurrent.atomic and java.util.concurrent.locks). I think you
    >need to look into that part of the problem.


    Well... Unfortunately, i am using jdk 1.3.
    So...

    >Package java.nio (possibly option 4) is good for server networking
    >applications that need to scale massively, but NIO has a pretty steep
    >learning curve.


    >State machines... I have written lots of them. They usually consist of a
    >state variable that might hold a reference to an interface or abstract base
    >class that implements the state.
    >
    >interface state {
    > /**
    > * State implementations execute their state,
    > * and set a state variable to the "next" state.
    > */
    > public void execute();
    >}
    >
    >
    >class stateMachine {
    > stateVariable = new state0();
    >
    > while(true) {
    > stateVariable.execute();
    > }
    >}


    >Obviously, this pseudo code glosses over the details. I would probably make
    >the state implementations inner classes of the state machine, so they would
    >have access to stateVariable to set it. I might even make the state
    >implementations themselves stateless, and static final, so setting the state
    >would be a simple assignment of "constants". Maybe enums could represent the
    >state. I haven't had to do a state machine since Java 1.5 introduced enums,
    >but it sounds promising.


    Thanks.
     
    nukleus, Jan 18, 2007
    #6
  7. nukleus

    nukleus Guest

    In article <>, "Andrew
    Thompson" <> wrote:
    >Karl Uppiano wrote:
    >> "nukleus" <> wrote in message

    >
    >> >I am working on a network related application.

    >
    >Sorry. Is that the AWT application you were
    >referring to, ealier? (another thread, different issue
    >re. layouts).


    Yep.

    >Because I meant to ask at the time, why the
    >application was AWT based, which suggests
    >to me that it is very old. Swing was a bit shaky
    >in 1.2, but by Java 1.3, it was quite usable.


    The problem is, i am using ms vj2003 which does not have
    javax stuff and i AM using jdk 1.3. It would be great if i could
    somehow turn on the javax libraries as it has some nice features,
    but i just don't know if it is possible. I have to live with what i got.

    >Do you need to support older VMs?
    >If so, what minimum version?


    Yep. I think going back to jdk 1.3.

    >Which then brings me (after a big snip) to..


    >> ...Java 1.5 introduced three
    >> entire packages devoted to thread synchronization (java.util.concurrent,
    >> java.util.concurrent.atomic and java.util.concurrent.locks). I think you
    >> need to look into that part of the problem.


    >...If you actually need to support the application at
    >a specific Java version (pre. 1.5), it might be a good
    >idea to mention that on any thread related to the
    >application, as people would have to 'think back',
    >even to remember what could be supported in 1.4!


    I see... Thanks.

    >Andrew T.
    >
     
    nukleus, Jan 18, 2007
    #7
  8. nukleus

    Chris Uppal Guest

    nukleus wrote:

    > > 1.5
    > > introduced three entire packages devoted to thread synchronization
    > > (java.util.concurrent, java.util.concurrent.atomic and
    > > java.util.concurrent.locks). I think you need to look into that part of
    > > the problem.

    >
    > Well... Unfortunately, i am using jdk 1.3.
    > So...


    http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

    BTW, why are you limited to 1.3 ? I'm only curious, but I can't think of any
    plausible reason myself.

    -- chris
     
    Chris Uppal, Jan 18, 2007
    #8
  9. nukleus

    nukleus Guest

    In article <45af9c4f$1$758$>, "Chris Uppal"
    <-THIS.org> wrote:
    >nukleus wrote:
    >
    >> > 1.5
    >> > introduced three entire packages devoted to thread synchronization
    >> > (java.util.concurrent, java.util.concurrent.atomic and
    >> > java.util.concurrent.locks). I think you need to look into that part of
    >> > the problem.

    >>
    >> Well... Unfortunately, i am using jdk 1.3.
    >> So...

    >
    >http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html


    Thanx.

    >BTW, why are you limited to 1.3 ? I'm only curious, but I can't think of any
    >plausible reason myself.


    Because that is all i have at the moment.
    Secondly, as i understand, 1.3 is stable enough.
    I read some articles about all sorts of issues with 1.4.
    My development environment does not support anything beyond 1.3.
    :--{

    Such is life...

    Do you have any idea, by any chance if it is possible to turn on
    the javax library in ms vj++ 2003?



    > -- chris
     
    nukleus, Jan 19, 2007
    #9
  10. nukleus wrote:
    > In article <45af9c4f$1$758$>, "Chris Uppal"
    > <-THIS.org> wrote:
    >> nukleus wrote:
    >>
    >>>> 1.5
    >>>> introduced three entire packages devoted to thread synchronization
    >>>> (java.util.concurrent, java.util.concurrent.atomic and
    >>>> java.util.concurrent.locks). I think you need to look into that part of
    >>>> the problem.
    >>> Well... Unfortunately, i am using jdk 1.3.
    >>> So...

    >> http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

    >
    > Thanx.
    >
    >> BTW, why are you limited to 1.3 ? I'm only curious, but I can't think of any
    >> plausible reason myself.

    >
    > Because that is all i have at the moment.


    Well go download 1.6 at java.sun.com and move into this century.

    --

    Knute Johnson
    email s/nospam/knute/
     
    Knute Johnson, Jan 19, 2007
    #10
  11. nukleus

    Chris Uppal Guest

    nukleus wrote:

    [me:]
    > > BTW, why are you limited to 1.3 ? I'm only curious, but I can't think
    > > of any plausible reason myself.

    >
    > Because that is all i have at the moment.


    Seems an easy enough problem to fix ;-)


    > Secondly, as i understand, 1.3 is stable enough.


    My vague memory is of 1.3 not being impressively stable. It's a long time ago,
    though, so I could easily be mis-remembering. But that's the main point -- 1.3
    is so old that it's obsolete.


    > My development environment does not support anything beyond 1.3.
    > :--{


    I suggest changing your development environment -- at least for Java work.


    > Do you have any idea, by any chance if it is possible to turn on
    > the javax library in ms vj++ 2003?


    Not the faintest, I'm afraid. I dislike MS's dev tools in the first place
    (even though I'm a Windows user) even for C++ work; and wouldn't even consider
    using them for Java, so I have no experience with vj++ at all.

    -- chris
     
    Chris Uppal, Jan 19, 2007
    #11
  12. nukleus

    Lew Guest

    nukleus wrote:
    > The problem is, i am using ms vj2003 which does not have
    > javax stuff and i AM using jdk 1.3. It would be great if i could
    > somehow turn on the javax libraries as it has some nice features,
    > but i just don't know if it is possible. I have to live with what i got.


    According to Sun, <http://java.sun.com/javase/downloads/previous.jsp>:

    "J2SE 1.3.1 has begun the Sun End of Life (EOL) process. The EOL transition
    period is from Oct 25, 2004 until the General Availability (GA) of the next
    Java version, Java SE 6."

    Java 6 has been out for a few weeks, so guess what? The two-plus year "EOL
    transition" is officially over, and Java 1.3 is obsolete. Unsupported. Dead.

    For over two years Java 1.3 has been moribund. How long do people need to move on?

    - Lew
     
    Lew, Jan 19, 2007
    #12
  13. nukleus

    Lew Guest

    nukleus wrote:
    >> Do you have any idea, by any chance if it is possible to turn on
    >> the javax library in ms vj++ 2003?


    Chris Uppal wrote:
    > Not the faintest, I'm afraid. I dislike MS's dev tools in the first place
    > (even though I'm a Windows user) even for C++ work; and wouldn't even consider
    > using them for Java, so I have no experience with vj++ at all.


    Isn't that the MS version of "Java" that lost them that lawsuit from Sun for
    trademark violation, since it was not a compatible language and therefore not
    really Java?

    - Lew
     
    Lew, Jan 19, 2007
    #13
  14. nukleus

    nukleus Guest

    In article <>, Lew
    <> wrote:
    >nukleus wrote:
    >>> Do you have any idea, by any chance if it is possible to turn on
    >>> the javax library in ms vj++ 2003?

    >
    >Chris Uppal wrote:
    >> Not the faintest, I'm afraid. I dislike MS's dev tools in the first place
    >> (even though I'm a Windows user) even for C++ work; and wouldn't even

    > consider
    >> using them for Java, so I have no experience with vj++ at all.

    >
    >Isn't that the MS version of "Java" that lost them that lawsuit from Sun for
    >trademark violation, since it was not a compatible language and therefore not
    >really Java?


    I think it is becasue they did have javax in vj++ 6, but in 2003 version
    it was all gone.

    >- Lew
     
    nukleus, Jan 20, 2007
    #14
  15. nukleus

    Chris Uppal Guest

    Lew wrote:

    [me:]
    > > I dislike MS's dev tools in the first
    > > place (even though I'm a Windows user) even for C++ work; and wouldn't
    > > even consider using them for Java, so I have no experience with vj++ at
    > > all.

    >
    > Isn't that the MS version of "Java" that lost them that lawsuit from Sun
    > for trademark violation, since it was not a compatible language and
    > therefore not really Java?


    If I remember correctly that particular legal fuss (justified, IMO) was at the
    time of MS Visual Studio 6 and the incompatible implementation of Java that MS
    were pushing around that time. The corresponding element of Visual Studio was
    "Visual J++ 6" (which didn't ship as a standard component of the IDE --
    presumably because of the "fuss").

    My /guess/ is that the OP, when he said "vj++" was really meaning Visual J#,
    since VJ++ is not part of VS 2003, but Visual J# is. That targets the
    Java-like Java-like language J# -- which has not (as far as I know) been the
    subject of any lawsuits.

    -- chris
     
    Chris Uppal, Jan 22, 2007
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hendra Gunawan
    Replies:
    1
    Views:
    12,754
    Allan Herriman
    Apr 8, 2004
  2. fishfry

    Non-blocking sockets?

    fishfry, Feb 7, 2005, in forum: Java
    Replies:
    1
    Views:
    481
    Aquila Deus
    Feb 7, 2005
  3. Tim Black
    Replies:
    1
    Views:
    1,118
    Alan Kennedy
    Aug 3, 2004
  4. James Stroud

    py2app semi-standalone semi-works

    James Stroud, Oct 4, 2006, in forum: Python
    Replies:
    2
    Views:
    731
    James Stroud
    Oct 4, 2006
  5. conrad
    Replies:
    1
    Views:
    655
Loading...

Share This Page