Re: Why not Half Life 3 on Java ?


"Raghar" <notfor@xxxxxxxx> wrote in message
news:Xns96A6E15A1A21ERaghar@xxxxxxxxxxxxxxxxx
> "cr88192" <cr88192@xxxxxxxxxxxxxxxxxx> wrote in
> news:243e5$42ef8f08$ca8019bc$13362@xxxxxxxxxx:
>
>>
>> <tudortihan@xxxxxxxxx> wrote in message
>> news:1122978296.935021.315190@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>> cr88192 said:
>>> [quote]however, there are "other" costs likely worth
>>> consideration, which make me
>>> doubt, at least for the time being, that java will really gain
>>> much ground
>>> vs c and c++. [/quote]
>>>
>>> What other costs can you see here? I'm not a Java guru, so
>>> please explain.
>>>
>> well, I am not much of a java guru either (most of my experience
>> is with c). it has been quite a long time since I have even
>> really looked much at java, but, now, there are a few cases
>> where it seems interesting and imo warrents further
>> investigation.
>>
>>
>> in the static compilation case:
>> lack of all that much on the grounds of statically compiled
>> implementations appart from gcj (aka: gcc+java) afaik.
>> ok, gcj is interesting, since it can be used as both a
>> java->object and java->bytecode compiler. this could be good.
>>
>
> Excelsior JET is able to do reasonable "static" compilation. Of
> course one of greater problems with statical compilation is not all
> parts of Java program are needed to be known at compile time.
> Program could decide it would like to do a code infusion, or create
> source file in memory and compile and add it at runtime...
>
> Not to mention bigger size of a statically compiled program in
> comparison to simple .jar just in time compiled selfexecutable.
> Of course .exe has the advantage of protection against redefinition
> of standard launcher under windoze.
>
yes, ok.

I was looking, my guess is that using gcj would imply a dependency on libgcj
and friends. no supprise probably, using this likely implying a dependency
on the gnu's vm...

others, likely similar...


on, of course, just use gcj for compiling the class files, and using an app
written vm. the jvm shouldn't be too difficult to implement (well, ok, just
the core vm, and not the large set of runtime classes). probably it would
work ok for scripting if one so felt like it.

>>
>> the language itself has a few issues, eg, lack of manual control
>> and pointers. I just feel unsure if one can adequately use a
>> language like this without the lack of pointers comming up and
>> biting at some point (imo, pointers are a blessing and a curse).
>>
>
> You can do someArray[4* a + b] = something
> Refferences are nearly identical to pointers, without an ability to
> shread OS to pieces.
>
yes, maybe.
I am not saying one can't get by without pointers, I just feel not entirely
sure, having lacked much experience doing much large-scale development in a
language without them.

>> this may not be that big of a problem, I just feel unsure, being
>> a person who tends to use pointers quite heavily in my own
>> projects...
>>
>> however, pointers are likely to be a problem for anything
>> expected to really be used in an interpreted context (they
>> somewhat limit the implementation, are a lot more difficult to
>> verify, ...).
>>
>>
>> also, I am not really sure on the state of java and operator
>> overloading. absent this, I feel, a lot of potential developers
>
> Only legal operator overloading is the operator overloading defined
> in language specification. No surprises with operator . redefined
> for dot product, and operator * redefined for cross product.
>
yeah though, but I still feel unsure, lack of operator overloading has the
potential of being a problem, or, at least, makes it less likely to sway
developers from c++.

>> may be driven away (actually, for me operator overloading is one
>> of the major things pulling me twards c++, but c++ lacks much
>> infrastructure for interpreted use, and c++ is imo a terribly
>> complicated beast).
>>
clarify: if one wanted to write a parser or interpreter.

even normal c, I had found, became a bit of a beast when I tried writing an
interpreter (actually, more like the parser/compiler portion, the bytecode
interpreter is likely to be fairly simple).

or whatever...


.

Relevant Pages

  • Re: Why not Half Life 3 on Java ?
    ... I'm not a Java guru, ... > in the static compilation case: ... > and pointers. ... Only legal operator overloading is the operator overloading defined ...
    (comp.games.development.programming.misc)
  • Re: The Java no pointer big fat lie!
    ... > reference types, it wouldn't be a good comparison. ... and what you can't - and there is a big difference in Java to C and C++. ... You cannot change it in the language itself, ... Thus I would distinguish pointers from ...
    (comp.lang.java.programmer)
  • Re: 7.0 wishlist?
    ... Other postings on that thread reveal my opinions on operator overloading more clearly. ... The main thread on which I discussed this was titled Java 7 Features. ... No language exists in a vacuum; note that Java's generics feature is roughly based on C++'s templates, at least in terms of syntax. ... I would expect that someone should avoid repeating points belabored to death before posting something. ...
    (comp.lang.java.programmer)
  • Re: 7.0 wishlist?
    ... my class would effectively implement dozens of interfaces that I didn't know exist and whose contracts I am probably violating. ... For division and subtraction, it would have to either give up or look for the RHS to have plus and negated, or times and invert. ... If you've previously expressed distaste here for operator overloading, that really should not mean that everybody else has to refrain from discussing the subject here on pain of being personally insulted by you. ... We should remain free to discuss what we please, even topics that you might dislike, so long as they pertain to Java. ...
    (comp.lang.java.programmer)
  • Re: 7.0 wishlist?
    ... The primary purpose of unchecked conversions is to facilitate migration to generics at disparate times. ... Operator overloading is principally used for mathematical constructs. ... It is not the job of the language designer to enforce against every conceivable misuse of a language feature, least of all to do so by simply refusing to add any features at all for fear that they might otherwise be abused. ... it is difficult for Java to not have chosen C++ syntax for various reasons. ...
    (comp.lang.java.programmer)
Loading