Apple is deprecating Java

Discussion in 'Java' started by Xah Lee, Oct 21, 2010.

  1. Xah Lee

    Xah Lee Guest

    Apple is deprecating Java! See: developer.apple.com. Quote:

    Java Deprecation

    As of the release of Java for Mac OS X 10.6 Update 3, the version
    of Java that is ported by Apple, and that ships with Mac OS X, is
    deprecated.

    This means that the Apple-produced runtime will not be maintained
    at the same level, and may be removed from future versions of Mac OS
    X. The Java runtime shipping in Mac OS X 10.6 Snow Leopard, and Mac OS
    X 10.5 Leopard, will continue to be supported and maintained through
    the standard support cycles of those products.

    Am so glad of this. Sooo glad. Death to you, Sun Microsystems, and
    your Java ****. Thank you for your incredible unscrupulous marketing
    lies and lawsuit gaming.

    12 years ago, the creator of tcl, John K Ousterhout, wrote a well
    known article〈Scripting: Higher Level Programming for the 21st
    Century〉 at Source. It is finally coming true in recent years.

    * Xah's Java Logo
    * Jargons of Info Tech Industry
    * What are OOP's Jargons and Complexities
    * The Tech Geekers and Software Engineering
    * Proliferation of Computing Languages

    for links, see: http://xahlee.blogspot.com/2010/10/apple-is-deprecating-java.html

    Xah
    Xah Lee, Oct 21, 2010
    #1
    1. Advertising

  2. Xah Lee

    projectmoon Guest

    On Thu, 21 Oct 2010 09:08:29 -0700, Xah Lee wrote:

    > Am so glad of this. Sooo glad. Death to you, Sun Microsystems, and your
    > Java ****. Thank you for your incredible unscrupulous marketing lies and
    > lawsuit gaming.


    Apple has concentrated mostly on Objective-C lately anyway. Java isn't
    going anywhere. It is firmly entrenched in business and server-side
    programming. Just because Apple will drop support for it at some
    indeterminate point in the future doesn't mean your strange dream is
    going to come true.
    projectmoon, Oct 21, 2010
    #2
    1. Advertising

  3. Xah Lee

    Xah Lee Guest

    and if you search lang popularity on the web, java is still #1. In
    fact, the top 3 are Java, C, C++.

    Pretty sad. I wait for them to all die. Gone.

    scripting lang isn't gonna replace these due to lang level, but i hope
    Scala, Clojure, Ocaml, F#, will do, soon.

    how soon do u think will it happen?

    my random guess is... humm.. 5 or 10 years? gosh, pretty sad to think
    about.

    Xah
    Xah Lee, Oct 21, 2010
    #3
  4. Xah Lee

    Arne Vajhøj Guest

    On 21-10-2010 14:21, BGB / cr88192 wrote:
    > "projectmoon"<> wrote in message
    > news:4cc07761$0$1853$c3e8da3$...
    >> On Thu, 21 Oct 2010 09:08:29 -0700, Xah Lee wrote:
    >>
    >>> Am so glad of this. Sooo glad. Death to you, Sun Microsystems, and your
    >>> Java ****. Thank you for your incredible unscrupulous marketing lies and
    >>> lawsuit gaming.

    >>
    >> Apple has concentrated mostly on Objective-C lately anyway. Java isn't
    >> going anywhere. It is firmly entrenched in business and server-side
    >> programming. Just because Apple will drop support for it at some
    >> indeterminate point in the future doesn't mean your strange dream is
    >> going to come true.

    >
    > possibly is goes to being more like Windows:
    > people use the Sun/Oracle implementation, rather than a native version
    > provided by the OS vendor.


    Could be.

    If Oracle wants to.

    Technically it would not be a big problem given that OpenJDK
    BSD port builds on MacOS X!

    But that does not guarantee that the business case will be
    good.

    > MS essentially killed off their own Java implementation as well, and no one
    > noticed.


    A lot of people noticed when applets stopped working
    on a newly installed Windows.

    And it was not voluntarily.

    So not that good an analogy.

    Arne
    Arne Vajhøj, Oct 21, 2010
    #4
  5. Xah Lee

    Xah Lee Guest

    On Oct 21, 2:17 pm, Arne Vajhøj <> wrote:
    > > possibly is goes to being more like Windows:
    > > people use the Sun/Oracle implementation, rather than a native version
    > > provided by the OS vendor.

    >
    > Could be.
    >
    > If Oracle wants to.
    >
    > Technically it would not be a big problem given that OpenJDK
    > BSD port builds on MacOS X!
    >
    > But that does not guarantee that the business case will be
    > good.
    >
    > > MS essentially killed off their own Java implementation as well, and no one
    > > noticed.

    >
    > A lot of people noticed when applets stopped working
    > on a newly installed Windows.
    >
    > And it was not voluntarily.
    >
    > So not that good an analogy.


    and remember when java started, Sun pitches it to be the revolution of
    the web, where, every webpage will be dynamic with java applet. So in
    late 1990s, huge amount of toy applets showed up, but since dot com
    bubble,
    these just waned, Flash and js took over. Sun did a bunch of idiotic
    things like started to have some java web start, a bunch of scripting
    langs in java like groovy n beenshell stuff , javaFX (another jargon
    shit), but tooo little tooo late. n what's that java markup lang? ah
    JSP. I used it in 2000. incredibly idiotic.

    Java pretty much moved very early to server market. Originally it is
    intended to be a lang for embedded devices... is it much used there?

    actually am too out of touch here. The only thing i know is that
    Google use it heavily for their entire web apps. Who uses java besides
    Google? and for what? I can just remember Steve Jobs saying “Nobody
    uses Java anymoreâ€. and That was in 2007.

    Xah ∑ http://xahlee.org/ ☄
    Xah Lee, Oct 21, 2010
    #5
  6. Xah Lee

    Arne Vajhøj Guest

    On 21-10-2010 17:17, Xah Lee wrote:
    > and if you search lang popularity on the web, java is still #1. In
    > fact, the top 3 are Java, C, C++.
    >
    > Pretty sad. I wait for them to all die. Gone.


    All languages will eventually die.

    > scripting lang isn't gonna replace these due to lang level, but i hope
    > Scala, Clojure, Ocaml, F#, will do, soon.
    >
    > how soon do u think will it happen?
    >
    > my random guess is... humm.. 5 or 10 years? gosh, pretty sad to think
    > about.


    More like 20-30.

    Arne
    Arne Vajhøj, Oct 21, 2010
    #6
  7. Xah Lee

    Steve Sobol Guest

    In article <i9q0bo$u2r$>, says...

    > MS essentially killed off their own Java implementation as well, and

    no one
    > noticed.


    That was different. Microsoft Java was a bastardized version of Java
    based on a 1.1 JVM with some M$-specific extensions.

    Apple has supported *real* Java up until now. I just got a used Mac Mini
    from a friend, he did a fresh install of Snow Leopard and Apple's 1.6.0
    JVM is part of the OS.

    > MS implements Java;
    > MS extends Java (J++);
    > Sun sues MS;


    And I don't think Oracle sued anyone over Apple's JVM.



    --
    Steve Sobol, Apple Valley, California, USA
    Steve Sobol, Oct 22, 2010
    #7
  8. Xah Lee

    Steve Sobol Guest

    In article <c7e6b976-83fd-46d0-9bd8-7fcef0917310
    @f16g2000prj.googlegroups.com>, says...


    > actually am too out of touch here. The only thing i know is that
    > Google use it heavily for their entire web apps. Who uses java besides
    > Google? and for what? I can just remember Steve Jobs saying ?Nobody
    > uses Java anymore?. and That was in 2007.


    The Android AND BlackBerry SDKs are Java-based.

    Most dumbphones have Java2 Mobile Edition and run J2ME games/apps, there
    are just a lot more restrictions on programming them.

    Big companies are still hiring Java developers. Go check Dice or
    Monster.




    --
    Steve Sobol, Apple Valley, California, USA
    Steve Sobol, Oct 22, 2010
    #8
  9. Xah Lee

    Arne Vajhøj Guest

    On 21-10-2010 21:40, Steve Sobol wrote:
    > In article<i9q0bo$u2r$>, says...
    >> MS essentially killed off their own Java implementation as well, and

    > no one
    >> noticed.

    >
    > That was different. Microsoft Java was a bastardized version of Java
    > based on a 1.1 JVM with some M$-specific extensions.


    Not only extensions.

    Also a few things removed that MS did not want there.

    The latter has a pretty bad impact on portability.

    Arne
    Arne Vajhøj, Oct 22, 2010
    #9
  10. On Thu, 21 Oct 2010 11:21:42 -0700, BGB / cr88192 wrote:

    > admittedly, I don't (entirely) disagree with some of MS's
    > re-engineering, and also think that, technically/overall, the .NET VM
    > architecture is a little more sensible than the standard JVM
    > architecture


    It can't be. It came from Microsoft.
    ClassCastException, Oct 22, 2010
    #10
  11. On Thu, 21 Oct 2010 22:23:59 -0400, Arne Vajhøj wrote:

    > On 21-10-2010 21:40, Steve Sobol wrote:
    >> In article<i9q0bo$u2r$>, says...
    >>> MS essentially killed off their own Java implementation as well, and

    >> no one
    >>> noticed.

    >>
    >> That was different. Microsoft Java was a bastardized version of Java
    >> based on a 1.1 JVM with some M$-specific extensions.

    >
    > Not only extensions.
    >
    > Also a few things removed that MS did not want there.
    >
    > The latter has a pretty bad impact on portability.


    So do non-standard extensions: developers use them (sometimes
    unwittingly) and then their code isn't portable to the whole rest of the
    world.
    ClassCastException, Oct 22, 2010
    #11
  12. Xah Lee

    Steve Sobol Guest

    In article <i9r3le$if7$-september.org>, zjkg3d9gj56
    @gmail.invalid says...
    >
    > On Thu, 21 Oct 2010 11:21:42 -0700, BGB / cr88192 wrote:
    >
    > > admittedly, I don't (entirely) disagree with some of MS's
    > > re-engineering, and also think that, technically/overall, the .NET VM
    > > architecture is a little more sensible than the standard JVM
    > > architecture

    >
    > It can't be. It came from Microsoft.


    Microsoft doesn't necessarily equal Suck.

    Occasionally, they do a decent job. I've always liked MapPoint, for
    example. Very capable piece of software.

    And, .NET is lightyears ahead of the technology it replaced. I never
    want to go back to VB6 or Classic ASP again - both of those products are
    utter crippleware compared to their .NET replacements.

    I would note that with the .NET platform in general, Microsoft seems to
    have stolen a lot of ideas from Java. Not that that's a bad thing. :)


    --
    Steve Sobol, Apple Valley, California, USA
    Steve Sobol, Oct 22, 2010
    #12
  13. "Steve Sobol" <> wrote in message
    news:...
    > In article <i9r3le$if7$-september.org>, zjkg3d9gj56
    > @gmail.invalid says...
    >>
    >> On Thu, 21 Oct 2010 11:21:42 -0700, BGB / cr88192 wrote:
    >>
    >> > admittedly, I don't (entirely) disagree with some of MS's
    >> > re-engineering, and also think that, technically/overall, the .NET VM
    >> > architecture is a little more sensible than the standard JVM
    >> > architecture

    >>
    >> It can't be. It came from Microsoft.

    >
    > Microsoft doesn't necessarily equal Suck.
    >
    > Occasionally, they do a decent job. I've always liked MapPoint, for
    > example. Very capable piece of software.
    >
    > And, .NET is lightyears ahead of the technology it replaced. I never
    > want to go back to VB6 or Classic ASP again - both of those products are
    > utter crippleware compared to their .NET replacements.
    >
    > I would note that with the .NET platform in general, Microsoft seems to
    > have stolen a lot of ideas from Java. Not that that's a bad thing. :)
    >


    yeah...

    the main thing that is an improvement is supporting a lot more options for
    interop with C and C++ code...

    JNI and JNA leave a bit to be desired...
    having to use pre-existing classes or interfaces to interface Java with
    anything else is... lame...

    these are not unfixable problems, but thus far the major VM's have not done
    much to improve on them.

    even CNI (like GCJ) would be an improvement (just better would be not having
    to use GCJ to use it...).
    admittedly, this front is a little awkward...

    but, I am left to wonder sometimes if the poor interface mechanisms are
    maybe deliberate...

    delaying type-binding would be another possible solution (the code remains a
    little more "fluid" until the last moment), allowing for code which is more
    flexible WRT incomplete types.


    for example:
    package myapp;
    public native class Foo;

    then the compiler is like "ok, this class is not currently visible", but
    uses it just the same (it handles methods and types a little more fluid than
    usual, leaving pretty much everything about the class unknown until "a time
    when it can be determined", likely either when linking the classes or at
    runtime). the idea here is that the class would exist either outside the
    language, or be implemented in some VM-specific way.

    the problem though is that something like this is neither a good match for
    the existing compilers nor for the bytecode (if the compilers supported it,
    likely it would generate rather naive and inefficient bytecode, absent
    something fancy being done in the JIT to try to compensate).

    I guess the newer VM's are adding/have added an "invokedynamic" instruction,
    but I have not looked into much as to how this would relate to this case.


    I had intended to write my own compiler (for my own VM) partly to deal with
    the above issue, but this is going very slow and I am left more using a
    slightly more standard compiler (the Eclipse compiler) for the time being.

    given this setback, I am still having to use JNI, but also partly devised
    another mechanism for the meantime:
    hacking over the JNI mechanism so that it is a little smarter, and can use
    an alternate mechanism (trying to find a compatible match for 'native'
    methods and trying to itself determine a sensible way to marshal the
    arguments).

    admittedly, using JNI some, it is not "as" terrible as it looks, but still
    isn't really exactly nice or convinient either...

    admittedly, my effort has a *long* way to go before "not sucking" is likely
    (at the moment, it is more along the lines of "barely works at all"... as
    both this aspect of the VM, and the class libraries, are woefully
    incomplete).


    OTOH, MS gives us P/Invoke and, better yet, C++/CLI. P/Invoke then provides
    a slightly less awkward way to glue the languages, and C++/CLI allows, more
    so, the ability to write code which sits right on the border...

    now, if this would be done without depending on MS's technology or dealing
    with the relatively poorer quality of the existing OSS VM's (and the
    apparent issue that C++/CLI is currently specific to MS's VM), this would be
    better.

    or such...
    BGB / cr88192, Oct 22, 2010
    #13
  14. Xah Lee

    Steve Sobol Guest

    In article <i9rfjn$29b$>, says...


    > yeah...
    >
    > the main thing that is an improvement is supporting a lot more options for
    > interop with C and C++ code...
    >
    > JNI and JNA leave a bit to be desired...
    > having to use pre-existing classes or interfaces to interface Java with
    > anything else is... lame...


    But even with .NET you have a shim that allows you to deal with legacy
    code.

    With .NET you have the issue of managed code using legacy code.

    With Java you have the issue of Java bytecode using native code, and
    that isn't going to go away due to Java's cross-platformness.

    JNI is a beast. I only use JNI if I need to create a native Windows or
    Linux launcher for a program; otherwise, I use JNA. JNA is about as
    simple as it's going to get, and it works well.


    > these are not unfixable problems, but thus far the major VM's have not done
    > much to improve on them.


    Fixing said problems, IMHO, would entail getting rid of the *best*
    reason to use Java (write once, run almost anywhere).



    --
    Steve Sobol, Apple Valley, California, USA
    Steve Sobol, Oct 22, 2010
    #14
  15. Xah Lee

    Roedy Green Guest

    On Thu, 21 Oct 2010 09:08:29 -0700 (PDT), Xah Lee <>
    wrote, quoted or indirectly quoted someone who said :

    > As of the release of Java for Mac OS X 10.6 Update 3, the version
    >of Java that is ported by Apple, and that ships with Mac OS X, is
    >deprecated.


    Apple is doing this all over. They now want to lock users in, and
    ensure apps for Apple won't run or cannot be easily be made to run
    elsewhere. Now they are getting bigger, they are mimicking IBM's old
    strategies.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    Microsoft has a new version out, Windows XP, which according to everybody is the "most reliable Windows ever." To me, this is like saying that asparagus is "the most articulate vegetable ever."
    ~ Dave Barry
    Roedy Green, Oct 22, 2010
    #15
  16. "Steve Sobol" <> wrote in message
    news:...
    > In article <i9rfjn$29b$>, says...
    >
    >
    >> yeah...
    >>
    >> the main thing that is an improvement is supporting a lot more options
    >> for
    >> interop with C and C++ code...
    >>
    >> JNI and JNA leave a bit to be desired...
    >> having to use pre-existing classes or interfaces to interface Java with
    >> anything else is... lame...

    >
    > But even with .NET you have a shim that allows you to deal with legacy
    > code.
    >


    yes, but one can write this shim in C++/CLI, and it is much nicer.

    more so, not all C or C++ code is "legacy", rather it may be the case that a
    large portion of the app is written, say, in C and C++, and Java or C# is
    intended to be used as a high-level scripting language (along with
    JavaScript and similar...).

    hence Java can be used similar to Python, but less horridly nasty...


    > With .NET you have the issue of managed code using legacy code.
    >
    > With Java you have the issue of Java bytecode using native code, and
    > that isn't going to go away due to Java's cross-platformness.


    the barrier can be lowered, however...

    there is no good reason it has to be JNI, and the issue is with the design
    of the standard JVM and compilers, rather than with the native code.

    I have achieved *much* more transparent interfacing between a JavaScript
    variant and C.
    meanwhile, there is no good way even to plug together between Java and
    JavaScript, even though the underlying implementation could do so without
    issue.


    > JNI is a beast. I only use JNI if I need to create a native Windows or
    > Linux launcher for a program; otherwise, I use JNA. JNA is about as
    > simple as it's going to get, and it works well.


    JNA still has issues though, namely that it is wonky and can't deal with the
    C ABI "on equal terms", and would seem to be a bit less powerful than JNI.

    moving the interface gunk onto the Java side of things is not ideal either
    (far from being transparent).
    better would be if the VM was smart enough to "do the right thing" without
    needing ugly gunk in either language (as in, transparent...).


    >> these are not unfixable problems, but thus far the major VM's have not
    >> done
    >> much to improve on them.

    >
    > Fixing said problems, IMHO, would entail getting rid of the *best*
    > reason to use Java (write once, run almost anywhere).
    >


    that is in the present case:
    nearly every VM implements their own non-standard means to interface with C
    (presumably in addition to JNI).


    but, anyways, major options:
    support delayed-binding in the compiler, and do some magic in the VM (this
    was my original plan of action, but doesn't work so long as I am using a
    standard compiler);
    implement a less braindead alternative to JNI (which is along the lines of
    what I have done for the time-being).


    delayed-binding could allow binding with whatever is visible at the time,
    essentially allowing transparently importing nearly the entire C toplevel
    and typesystem de-facto (provided the implementation can see it), or gluing
    against other languages (such as JS), but this can't be done with standard
    compilers, or efficiently in the current bytecode design (absent hackery).
    nevermind what level of evil hackery goes on behind the scenes.


    the latter option basically looks just like JNI on the Java end (classes
    with 'native' methods).
    however, unlike JNI, the interface is capable of "negotiating" the arguments
    with the C code (it looks up the C declaration, and sees what types it
    expects, and also knows what exists on the Java end, and tries to figure out
    how to best coerce the Java-side arguments into the C-side arguments).

    it might also probe for different C-side functions, such as to make
    interfacing a little more flexible.

    technically, I just sort of hacked over the prior JNI mechanism and patched
    it into other mechanisms elsewhere in the project (it looks up the proper
    JNI function first, and failing this, falls back to the other options).


    granted, I happen to be operating within the confines of a VM which knows
    the C-side declarations for any functions/types/... and in some cases types
    can have special modifiers attached (mostly these are used to give the VM
    additional abilities to figure out C side types, such as when the object is
    visible via a dynamically-typed reference or "void *" pointer, ...).

    for example, in the interface, the 'this' argument is known by using a
    special type which flags that a 'this' value is expected for this argument
    (if omitted, 'this' is discarded).

    so, for example:
    public class Foo {
    public native void bar(String str);
    }

    and in C, this could be used:
    API void Foo_bar(dycThis self, char *str)
    {
    //captures 'this', and coerces the string to a C string
    ...
    }

    dycThis/dycObject/... are related to my framework's internal OO facilities
    (sadly, these aren't transparently accessible from C either, and I am not as
    inclined to do something along the lines of Objective-C nastiness to make it
    work...). (partly this is because most of my C code is still compiled with
    native compilers, as they tend to do the best job...).


    but, this could be used:
    API void Foo_bar(char16 *str)
    {
    //ignores this, coerces to a 16-bit string
    ...
    }

    or:
    API void bar(char *str)
    {
    //treats it more like a toplevel function
    }

    or:
    ....

    but, the above is a bit of a compromise, but at least, it provides a
    slightly less ugly alternative...


    the system is also capable of looking into structs, ... but there is little
    hope of cleanly mapping this to Java (it is used with my JS variant though,
    which is capable of looking into C structs).

    as noted, types visible via "void *" pointers pose an issue, but my
    framework also supports dynamic-type tagging, and it is common to indicate
    (at the typedef's) that a given dynamic type name refers to a specific C
    type, hence allowing dynamic typing on C structs (and type visibility
    through void pointers).


    on the Java end, something like this would require a wrapper class or
    similar, say:
    class TypedPointer extends Pointer {
    ...
    public native int geti(String name);
    public native long getl(String name);
    public native float getf(String name);
    public native double getd(String name);
    public native Pointer getp(String name);
    public native Object geto(String name);
    ...
    public native void set(String name, int val);
    public native void set(String name, long val);
    ...
    }

    or such...
    BGB / cr88192, Oct 22, 2010
    #16
  17. Xah Lee

    Arne Vajhøj Guest

    On 22-10-2010 11:06, Steve Sobol wrote:
    > In article<i9rfjn$29b$>, says...
    >> yeah...
    >>
    >> the main thing that is an improvement is supporting a lot more options for
    >> interop with C and C++ code...
    >>
    >> JNI and JNA leave a bit to be desired...
    >> having to use pre-existing classes or interfaces to interface Java with
    >> anything else is... lame...

    >
    > But even with .NET you have a shim that allows you to deal with legacy
    > code.


    If it is a Win32 DLL, then you don't need to write any glue code at all.

    > JNI is a beast. I only use JNI if I need to create a native Windows or
    > Linux launcher for a program; otherwise, I use JNA. JNA is about as
    > simple as it's going to get, and it works well.


    JNA still uses JNI.

    It is just a convenience.

    Arne
    Arne Vajhøj, Oct 22, 2010
    #17
  18. Xah Lee

    Steve Sobol Guest

    In article <>,
    lid says...


    > Apple is doing this all over. They now want to lock users in, and
    > ensure apps for Apple won't run or cannot be easily be made to run
    > elsewhere. Now they are getting bigger, they are mimicking IBM's old
    > strategies.


    And we all know how well that worked for IBM.




    --
    Steve Sobol, Apple Valley, California, USA
    Steve Sobol, Oct 22, 2010
    #18
  19. Xah Lee

    Steve Sobol Guest

    In article <4cc1fcb8$0$23763$>,
    says...


    > If it is a Win32 DLL, then you don't need to write any glue code at all.


    That wasn't my impression, but I don't do a ton of work with .NET, and
    my code basically never needs to interact with a 3rd-party DLL. I could
    definitely be wrong.

    > > JNI is a beast. I only use JNI if I need to create a native Windows

    or
    > > Linux launcher for a program; otherwise, I use JNA. JNA is about as
    > > simple as it's going to get, and it works well.

    >
    > JNA still uses JNI.
    >
    > It is just a convenience.


    Granted. But using JNA means I don't have to use JNI directly, which
    makes me happy, because JNI is butt-ugly.

    The only time I use JNI directly is when I use the Invocation API to
    launch a Java application from an .EXE.

    I don't mean to imply that JNA is perfect, or that it isn't closely tied
    to JNI.


    --
    Steve Sobol, Apple Valley, California, USA
    Steve Sobol, Oct 22, 2010
    #19
  20. Xah Lee

    Arne Vajhøj Guest

    On 22-10-2010 18:32, Steve Sobol wrote:
    > In article<4cc1fcb8$0$23763$>,
    > says...
    >> If it is a Win32 DLL, then you don't need to write any glue code at all.

    >
    > That wasn't my impression, but I don't do a ton of work with .NET, and
    > my code basically never needs to interact with a 3rd-party DLL. I could
    > definitely be wrong.


    If it is a Win32 DLL with a C API and the types are
    not too tricky, then a simple DllImport attribute (annotation
    in Java terminology) is all that is needed. .NET provides all
    the glue.

    Arne
    Arne Vajhøj, Oct 22, 2010
    #20
    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. Jenny
    Replies:
    2
    Views:
    412
    Andrew Thompson
    Aug 13, 2004
  2. Thomas Hawtin

    deprecating abstract methods

    Thomas Hawtin, Apr 10, 2006, in forum: Java
    Replies:
    5
    Views:
    618
    Gabriel Belingueres
    Apr 17, 2006
  3. Gianni Mariani
    Replies:
    1
    Views:
    317
    Ian Collins
    Oct 28, 2008
  4. Chris Friesen
    Replies:
    0
    Views:
    75
    Chris Friesen
    Nov 21, 2013
  5. Chris Angelico
    Replies:
    0
    Views:
    86
    Chris Angelico
    Nov 21, 2013
Loading...

Share This Page