When libraries aren't good enough ...



  • ... we must reinvent the wheel ...


    public static double getRoundValue(double d, int precision) {
      String s = new String( "." );
      for ( int i = 0 ; i < precision ; i++)
      {
        s += '0';
      }
      s += '5';
      double rounder = Double.parseDouble( s );

      // NOW CHOP OF THE DECIMAL PLACES THAT ARE PAST PRECISION
      String temp = "" + d;

      int i = temp.indexOf( '.' );
      if ( i + 1 + precision < temp.length() - 1)
      {
        d += rounder;
        temp = "" + d;
        temp = temp.substring( 0, i + precision + 1 );
        d = Double.parseDouble( temp );
      }

      return ( d );
    }



  • @zelmak said:

    public static double getRoundValue(double d, int precision) {
      String s = new String( "." );

    Argh.



  • @b_redeker said:

    @zelmak said:

    public static double getRoundValue(double d, int precision) {
      String s = new String( "." );

    Argh.

     

    Wow, I didn't even notice that until you pointed it out. I think my brain just refused to accept that it was actually there.



  • Indeed. I'm trying to break the other programmers of this habit, but it's slow going.



  • @zelmak said:

    Indeed. I'm trying to break the other programmers of this habit, but it's slow going.

    So there's more than one person who does this? Where did they all get the idea that using a copy constructor on a literal of the same type makes any kind of sense?



  • Actually, what bugged me, is that when you want to perform an operation on one datatype, and you feel the need to immediately declare a helper in a completely unrelated datatype, then you should be scratching your head, because chances are YOU'RE DOING IT WRONG, IDIOT!

    I didn't even want to read the rest of the function. I think it probably fails in certain circumstances (rounding 42 to 7 decimals) but I'm not going to check that because it MAKES ME ANGRY and want to SMASH things and I'm going all GREEN and...

    OK, so let me rephrase that. If you're trying to do a very common operation on a very common datatype in a very common language (younger than me, say) and you feel the need to actually create that function instead of googling/MSDNning/Javadoccing it for 5 seconds then...

    Argh.

     



  • @b_redeker said:

    I think it probably fails in certain circumstances (rounding 42 to 7 decimals)

    Actually, as far as I can see, it handles that case correctly (who would have thought?). It'll fall over horribly if you pass in a negative precision, and it'll round incorrectly if the original number is negative (if you round -3.2985 to one decimal place it'll give you -3.2; -3.2222 would round to -3.1). There also seems to be an off-by-one error in the logic that decides whether it should truncate the string or just return the original number. I'm pretty sure that if you try to round 5.26 to one decimal place, you'll get 5.26 back (unless the 5.26 becomes 5.25999999994 or something in string form, in which case you'll be OK), but I'm not a Java coder so I welcome correction if I'm wrong on this point.

    In weak defense of the code, while it took me about five seconds to find Math.round(), and another ten seconds to realise that it only does integer rounding and not variable precision like a decent language ought, I can understand why someone might think they had to write their own routine... oh, who am I kidding? It only took another ten seconds of googling to find a reasonable sample routine - and while there are potential overflow / underflow issues with "multiply by 10^x, round, divide by 10^x", that's still much better than the issues with this routine. At least they'll work with most inputs :)



  • @Someone You Know said:

    @zelmak said:

    Indeed. I'm trying to break the other programmers of this habit, but it's slow going.

    So there's more than one person who does this? Where did they all get the idea that using a copy constructor on a literal of the same type makes any kind of sense?

     

    It's java(I guess, looks like it). so there is no copy constructor, and the code is not really more ineffective then just writing s="." (But s="." is more readable).

     What is really ineffective is that strings in java are imutable so each time it does a += it creates a new string and throw the old string away.



  • @tiller said:

    @Someone You Know said:

    @zelmak said:

    Indeed. I'm trying to break the other programmers of this habit, but it's slow going.

    So there's more than one person who does this? Where did they all get the idea that using a copy constructor on a literal of the same type makes any kind of sense?

     

    It's java(I guess, looks like it). so there is no copy constructor, and the code is not really more ineffective then just writing s="." (But s="." is more readable).

     What is really ineffective is that strings in java are imutable so each time it does a += it creates a new string and throw the old string away.

     

    The String(String) constructor being used here takes a String as an argument and constructs a new String object that is a value copy of that String. In what way is that not a copy constructor? 

    It is "more ineffective" than String s = "."; because it creates two String objects — the literal "." and s — and discards one of them without using it for anything.

    I wouldn't worry about the concatenations as much, though; newer versions of Java are reasonably clever about that, and will convert String += String expressions to use StringBuffer or StringBuilder behind the scenes if there are a significant number of them in rapid succession.



  • In weak defense of the code, while it took me about five seconds to find Math.round(), and another ten seconds to realise that it only does integer rounding and not variable precision like a decent language ought, I can understand why someone might think they had to write their own routine... oh, who am I kidding? It only took another ten seconds of googling to find a reasonable sample routine - and while there are potential overflow / underflow issues with "multiply by 10^x, round, divide by 10^x", that's still much better than the issues with this routine. At least they'll work with most inputs :)

    ---------- 

     I'd point you to BigDecimal. http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/math/BigDecimal.html

    Immutable, arbitrary-precision signed decimal numbers. A BigDecimal 
    consists of an arbitrary precision integer unscaled value and a 32-bit 
    integer scale. If zero or positive, the scale is the number of digits to 
    the right of the decimal point. If negative, the unscaled value of the 
    number is multiplied by ten to the power of the negation of the scale. 
    The value of the number represented by the BigDecimal is therefore 
    (unscaledValue × 10-scale). 
    

    The BigDecimal class provides operations for arithmetic, scale manipulation, rounding, comparison, hashing, and format conversion. The toString() method provides a canonical representation of a BigDecimal.

    ---------- 

    Everything they needed was already available. Ignorance and not knowing where to look kept them from finding it.


  • @Someone You Know said:

    @tiller said:

    @Someone You Know said:

    @zelmak said:

    Indeed. I'm trying to break the other programmers of this habit, but it's slow going.

    So there's more than one person who does this? Where did they all get the idea that using a copy constructor on a literal of the same type makes any kind of sense?

     

    It's java(I guess, looks like it). so there is no copy constructor, and the code is not really more ineffective then just writing s="." (But s="." is more readable).

     What is really ineffective is that strings in java are imutable so each time it does a += it creates a new string and throw the old string away.

     

    The String(String) constructor being used here takes a String as an argument and constructs a new String object that is a value copy of that String. In what way is that not a copy constructor? 

    It is "more ineffective" than String s = "."; because it creates two String objects — the literal "." and s — and discards one of them without using it for anything.

    I wouldn't worry about the concatenations as much, though; newer versions of Java are reasonably clever about that, and will convert String += String expressions to use StringBuffer or StringBuilder behind the scenes if there are a significant number of them in rapid succession.

     

    You are right, it is a copy constructor unless the java compiler does some fancy optimization. Is someone bored enough to try and compile and then dis-assable the program to se if java compiler does the obvious optimization :}

    But the java compiler wil not rewrite the += anyware in this program to use a StringBuffer.

    It will only insert an extra StringBuffer when you do something like "Some" + myVar + "other things" but in this case the right side is always a single char/string so it wil generate a new string for each +=. But given the number of wtf's in this code and the fact that this is most likely not in a performence critical place that is rather low on the list of things to fix.



  • ... guess what? I found this exact same method/function in a second 'Utils' class ...

    And NetBeans tells me both are in-use.

    *headdesk*



  • oh, and one more thing ... I have yet to track down HOW it's being used. It could be used only in GUIs and output to files ...

    Which could be handled, simply, by a Formatter.



  • @tiller said:

    You are right, it is a copy constructor unless the java compiler does some fancy optimization. Is someone bored enough to try and compile and then dis-assable the program to se if java compiler does the obvious optimization :}

    The documentation for that method states explicitly that it creates a new object. Compilers shouldn't be going against that; the one from Sun Oracle certainly doesn't.

    The same documentation also basically says that you should never use that constructor for anything, ever, but I doubt if the people who wrote this code have ever read it.

    @tiller said:


    But the java compiler wil not rewrite the += anyware in this program to use a StringBuffer.

     

    The language spec allows compilers to optimize this sort of thing wherever they want. I admit that I don't know exactly where it's done in practice, but it may differ from compiler to compiler.



  • Everything else has been covered, but this is what bugs me:

    @zelmak said:


      String temp = "" + d;

     

    If only there was a way to convert something toString!



  • @pkmnfrk said:

    If only there was a way to convert something toString!
    \

    Now that's crazy talk. Next you'll be telling me there's a way to round a double.

     



  • @pkmnfrk said:

    Everything else has been covered, but this is what bugs me:

    @zelmak said:


      String temp = "" + d;

     

    If only there was a way to convert something toString!

     

    That's pretty standard Java idiom. It's the shortest way to code that.



  • @mol1111 said:

    @pkmnfrk said:

    Everything else has been covered, but this is what bugs me:

    @zelmak said:


      String temp = "" + d;

     

    If only there was a way to convert something toString!

     

    That's pretty standard Java idiom. It's the shortest way to code that.

     

    That and the primitive data types in Java do not have a toString() method.  So you could do it like this I guess:

    String temp = new Double(d).toString();

    or

    String temp = Double.toString(d);

    Looking at the implementation that I found for the Double class, calling that method does this:

    public static String toString(double d) {
      return org.apache.harmony.luni.util.NumberConverter.convert(d);
    }

     That method looks like this:

    <font color="#7f0055">public</font> <font color="#7f0055">static</font> String convert(<font color="#7f0055">double</font> input) {
    <font color="#7f0055">return</font> getConverter().convertD(input);
    }
    getConverter() does:
    <font color="#7f0055">private</font> <font color="#7f0055">static</font> NumberConverter getConverter() {
    <font color="gray"></font> <font color="#7f0055">return</font> <font color="#7f0055">new</font> NumberConverter();
    <font color="gray"></font>}
    Wait, what?  We need a new instance of the class we're already in? WTF?
    And finally the convertD() method does this:
    <font color="gray">055:</font>            <font color="#7f0055">public</font> String convertD(<font color="#7f0055">double</font> inputNumber) {
    <font color="gray">056:</font> <font color="#7f0055">int</font> p = <font color="#990000">1023</font> + <font color="#990000">52</font>; <font color="#3f7f5f">// the power offset (precision)</font>
    <font color="gray">057:</font> <font color="#7f0055">long</font> signMask = <font color="#990000">0x8000000000000000L</font>; <font color="#3f7f5f">// the mask to get the sign of</font>
    <font color="gray">058:</font> <font color="#3f7f5f">// the number</font>
    <font color="gray">059:</font> <font color="#7f0055">long</font> eMask = <font color="#990000">0x7FF0000000000000L</font>; <font color="#3f7f5f">// the mask to get the power bits</font>
    <font color="gray">060:</font> <font color="#7f0055">long</font> fMask = <font color="#990000">0x000FFFFFFFFFFFFFL</font>; <font color="#3f7f5f">// the mask to get the significand</font>
    <font color="gray">061:</font> <font color="#3f7f5f">// bits</font>
    <font color="gray">062:</font>
    <font color="gray">063:</font> <font color="#7f0055">long</font> inputNumberBits = Double.doubleToLongBits(inputNumber);
    <font color="gray">064:</font> <font color="#3f7f5f">// the value of the sign... 0 is positive, ~0 is negative</font>
    <font color="gray">065:</font> String signString = (inputNumberBits & signMask) == <font color="#990000">0</font> ? <font color="#2a00ff">""</font>
    <font color="gray">066:</font> : <font color="#2a00ff">"-"</font>;
    <font color="gray">067:</font> <font color="#3f7f5f">// the value of the 'power bits' of the inputNumber</font>
    <font color="gray">068:</font> <font color="#7f0055">int</font> e = (<font color="#7f0055">int</font>) ((inputNumberBits & eMask) >> <font color="#990000">52</font>);
    <font color="gray">069:</font> <font color="#3f7f5f">// the value of the 'significand bits' of the inputNumber</font>
    <font color="gray">070:</font> <font color="#7f0055">long</font> f = inputNumberBits & fMask;
    <font color="gray">071:</font> <font color="#7f0055">boolean</font> mantissaIsZero = f == <font color="#990000">0</font>;
    <font color="gray">072:</font> <font color="#7f0055">int</font> pow = <font color="#990000">0</font>, numBits = <font color="#990000">52</font>;
    <font color="gray">073:</font>
    <font color="gray">074:</font> <font color="#7f0055">if</font> (e == <font color="#990000">2047</font>)
    <font color="gray">075:</font> <font color="#7f0055">return</font> mantissaIsZero ? signString + <font color="#2a00ff">"Infinity"</font> : <font color="#2a00ff">"NaN"</font>;
    <font color="gray">076:</font> <font color="#7f0055">if</font> (e == <font color="#990000">0</font>) {
    <font color="gray">077:</font> <font color="#7f0055">if</font> (mantissaIsZero)
    <font color="gray">078:</font> <font color="#7f0055">return</font> signString + <font color="#2a00ff">"0.0"</font>;
    <font color="gray">079:</font> <font color="#7f0055">if</font> (f == <font color="#990000">1</font>)
    <font color="gray">080:</font> <font color="#3f7f5f">// special case to increase precision even though 2 *</font>
    <font color="gray">081:</font> <font color="#3f7f5f">// Double.MIN_VALUE is 1.0e-323</font>
    <font color="gray">082:</font> <font color="#7f0055">return</font> signString + <font color="#2a00ff">"4.9E-324"</font>;
    <font color="gray">083:</font> pow = <font color="#990000">1</font> - p; <font color="#3f7f5f">// a denormalized number</font>
    <font color="gray">084:</font> <font color="#7f0055">long</font> ff = f;
    <font color="gray">085:</font> <font color="#7f0055">while</font> ((ff & <font color="#990000">0x0010000000000000L</font>) == <font color="#990000">0</font>) {
    <font color="gray">086:</font> ff = ff << <font color="#990000">1</font>;
    <font color="gray">087:</font> numBits--;
    <font color="gray">088:</font> }
    <font color="gray">089:</font> } <font color="#7f0055">else</font> {
    <font color="gray">090:</font> <font color="#3f7f5f">// 0 < e < 2047</font>
    <font color="gray">091:</font> <font color="#3f7f5f">// a "normalized" number</font>
    <font color="gray">092:</font> f = f | <font color="#990000">0x0010000000000000L</font>;
    <font color="gray">093:</font> pow = e - p;
    <font color="gray">094:</font> }
    <font color="gray">095:</font>
    <font color="gray">096:</font> <font color="#7f0055">if</font> (-<font color="#990000">59</font> < pow && pow < <font color="#990000">6</font> || (pow == -<font color="#990000">59</font> && !mantissaIsZero))
    <font color="gray">097:</font> longDigitGenerator(f, pow, e == <font color="#990000">0</font>, mantissaIsZero, numBits);
    <font color="gray">098:</font> else
    <font color="gray">099:</font> bigIntDigitGeneratorInstImpl(f, pow, e == <font color="#990000">0</font>,
    <font color="gray">100:</font> mantissaIsZero, numBits);
    <font color="gray">101:</font>
    <font color="gray">102:</font> <font color="#7f0055">if</font> (inputNumber >= <font color="#990000">1e7D</font> || inputNumber <= -<font color="#990000">1e7D</font>
    <font color="gray">103:</font> || (inputNumber > -<font color="#990000">1e-3D</font> && inputNumber < <font color="#990000">1e-3D</font>))
    <font color="gray">104:</font> <font color="#7f0055">return</font> signString + freeFormatExponential();
    <font color="gray">105:</font>
    <font color="gray">106:</font> <font color="#7f0055">return</font> signString + freeFormat();
    <font color="gray">107:</font> }
     
    Now, I haven't seen the implementation for the + operator overloading of String + double, so I can't say that it is any better.

     



  • @amischiefr said:

    That and the primitive data types in Java do not have a toString() method.  So you could do it like this I guess:

    String temp = new Double(d).toString();

    or

    String temp = Double.toString(d);

     

    Your second example would be preferred in this case, since it avoids creating a Double object that doesn't then get used for anything. That's why the static Double.toString(double) method exists in the first place. Granted, one extra local Double is probably not going to cause any serious problems, but it's better style (and slightly faster to type).

    @amischiefr said:

    getConverter() does:
    <font color="#7f0055">private</font> <font color="#7f0055">static</font> NumberConverter getConverter() {
    <font color="gray"></font> <font color="#7f0055">return</font> <font color="#7f0055">new</font> NumberConverter();
    <font color="gray"></font>}
    Wait, what?  We need a new instance of the class we're already in? WTF?

    That is a fairly odd way to structure a class, especially since all the instance method it's calling is public. It's possible that at one point all the conversion logic was implemented with static methods, and when it was changed to use instance variables and methods, the designers didn't want to break old code that was using it.


  • @Someone You Know said:

    The documentation for that method states explicitly that it creates a new object. Compilers shouldn't be going against that; the one from Sun Oracle certainly doesn't.

    The same documentation also basically says that you should never use that constructor for anything, ever, but I doubt if the people who wrote this code have ever read it.

    @tiller said:


    But the java compiler wil not rewrite the += anyware in this program to use a StringBuffer.

     

    The language spec allows compilers to optimize this sort of thing wherever they want. I admit that I don't know exactly where it's done in practice, but it may differ from compiler to compiler.

     

    The compiler can optimize what it want as long as it don't change the semantic of the program. So it might in this case notice that no other function is given a reference of the string in the loop, and add usage of a StringBuffer.But I really don't think the compiler wil do that. I mean sun have added StringBuffer/StringBuilder for people who want Strings which can change so there is no reason to assume that += should be optimized for strings. (Unless you optimize your compiler for code submitted to thedailywtf.

    Ofcause the real wtf is that the only Object in java which can use is += is String which is also specified as immutable and thus the only class which in no way can make an effective append operation.

     



  • @Someone You Know said:

    Your second example would be preferred in this case, since it avoids creating a Double object that doesn't then get used for anything. That's why the static Double.toString(double) method exists in the first place. Granted, one extra local Double is probably not going to cause any serious problems, but it's better style (and slightly faster to type).
     

    Fair enough, but I guess my point was that we don't really know which way is better: using the Double.toString(), the new Double(d).toString() or the use of the "String + double" overloaded "+" operator.  Since I can't find how the logic for that is implemented it's hard to say which method is actually more effecient.   On top of that, we don't know what the compiler is doing.  The compiler might simply lump the two different ways together into the same byte code when all is said and done. 



  • @amischiefr said:

    we don't really know which way is better: using the Double.toString(), the new Double(d).toString() or the use of the "String + double" overloaded "+" operator.
     

    My guess would be that it will me more or less the same, plus or minus a couple CPU cycles, or some memory. Most of those diffferences might get optimized away by a compiler. Personally, I couldn't care less, unless you're on an embedded system without file system.

    Possibly more important for the future is which notation will confuse the least people, including yourself. For instance the line 

        temp = "" + d;

    Is about as unclear as it gets. Without knowing the language, it's even impossible to know if this is a valid statement or even whether it makes sense. For me, personally

        strTemp = Double.toString(d);

    would be a huge improvement (and thereby save CPU cycles and memory).

     



  • @b_redeker said:

    @amischiefr said:

    we don't really know which way is better: using the Double.toString(), the new Double(d).toString() or the use of the "String + double" overloaded "+" operator.
     

    My guess would be that it will me more or less the same, plus or minus a couple CPU cycles, or some memory.

    if you are using java, i don't believe you care about CPU cycles or memory



  • @Nelle said:

    @b_redeker said:
    My guess would be that it will me more or less the same, plus or minus a couple CPU cycles, or some memory.
    if you are using java, i don't believe you care about CPU cycles or memory
    [Citation needed]



  •  @Xyro said:

    [Citation needed]

    Very cool. BTW, Racket? Damn, those kids keep making new * languages.

     

     

    * yes, I know, 1994. Newfangled stuff. I remember when all we had was mumble mumble.



  • @Xyro said:

    @Nelle said:
    @b_redeker said:
    My guess would be that it will me more or less the same, plus or minus a couple CPU cycles, or some memory.
    if you are using java, i don't believe you care about CPU cycles or memory
    [Citation needed]



    citation



    i know its from 2005 and that much has changed since then, but the cards in the industry have already been dealt. c/c++ got real-time/embedded/efficient and java got enterprise.



    or do you really think that an average Java programmer cares about cpu cycles or ram?

    hell if you'd googled memory problems and java, i'm sure the most common response would be setting the -Xm... flags and not "optimizing the code".



  • @Nelle said:

    @Xyro said:
    @Nelle said:
    @b_redeker said:
    My guess would be that it will me more or less the same, plus or minus a couple CPU cycles, or some memory.
    if you are using java, i don't believe you care about CPU cycles or memory
    [Citation needed]

    citation

    i know its from 2005 and that much has changed since then, but the cards in the industry have already been dealt. c/c++ got real-time/embedded/efficient and java got enterprise.

    or do you really think that an average Java programmer cares about cpu cycles or ram?
    hell if you'd googled memory problems and java, i'm sure the most common response would be setting the -Xm... flags and not "optimizing the code".
     

    Well, that's not a citation about Java developers' apathy towards resources, but at the same time I don't disagree with that article.  With any language, you have to consider the appropriateness of its application, C/C++ included. I am a Java developer and I care about CPU and memory.  I design my programs to be light and fluidic and responsible and XML-free.  Java is an appropriate language for what I do, as it's not unusual for my work programs to be deployed to Solaris and HP-UX (some PA-RISK, some Itanium) after they're developed on Windows.  And all the skills and techniques and custom libraries are directly transferable to my projects at home on Linux.  I consciously trade off OCD-level control of the memory for monstrous horsepower and ease of development and deployment. (As well as not wasting my time with resource bookkeeping -- isn't that why we invented computers in the first place?)

    As a keen developer of Java, yes, I know very well what a beast of a language it is to use.  I have other posts you can read to see me bash it. And I know very well that the JVM itself can allocate hundreds of megs of memory just to keep things flowing smoothly, but that can just as well be used as an asset (cheap-as-in-free [code]new[/code]'ing).

    Accusing developers in any language to be ignorant or apathetic of resources is a pretty useless statement to make.  Of course, I'm sure folks were saying that of C back when it was new, to say nothing of COBOL.  Assembly forever!



  • I took a look at the bytecode for a statement like this:

    strTemp = "" + d;
    It creates a StringBuilder, appends an empty String to it, appends d to

    it, then calls its toString() method and stores that value in strTemp.

    I
    don't have the implementation of StringBuilder.append(double) handy at
    the moment. However, if it's comparable in efficiency to
    Double.toString(double), then the latter is clearly preferable, given
    the overhead of creating a StringBuilder, the useless call to
    StringBuilder.append(String) with an empty String, and then flattening the
    StringBuilder into a String at the end.

     



  • @Nelle said:

    @Xyro said:
    @Nelle said:
    @b_redeker said:
    My guess would be that it will me more or less the same, plus or minus a couple CPU cycles, or some memory.
    if you are using java, i don't believe you care about CPU cycles or memory
    [Citation needed]

    citation

    i know its from 2005 and that much has changed since then, but the cards in the industry have already been dealt. c/c++ got real-time/embedded/efficient and java got enterprise.

    or do you really think that an average Java programmer cares about cpu cycles or ram?
    hell if you'd googled memory problems and java, i'm sure the most common response would be setting the -Xm... flags and not "optimizing the code".
     

    Not a very compelling article.  While I did like the Doom series,  Carmack is hardly the expert on what is the best language.  He has made his living on developing rendering engines and video games in C.  This is sort of like asking a UNIX fenatic to give a fair evaluation of Windows 7.

    The reason most Java developers don't worry about cpu cycles is because they don't have to.  For the last time: JAVE IS NOT A LOW LEVEL LANGUAGE!  It is not designed to mess with memory address registries. Get over it.  It is designed to remove this burdon from the programmer so that they can focus on design rather than low level "did I allocate enough memory?" 

    So it doesn't perform as fast as native C, boo fucking hoo.  If I was writing code for the CIA that needed to be lightning fast or Al Queda would swoop down and bomb the capitol I might go with something else, but if I'm developing some stupid little web app I'm gonna use Spring MVC, get it done in a couple of days and move on with my life in the knowledge that I did not have to suffer through one fucking segmentation fault.



  • @amischiefr said:

    The reason most Java developers don't worry about cpu cycles is because they don't have to.  For the last time: JAVE IS NOT A LOW LEVEL LANGUAGE!  It is not designed to mess with memory address registries. Get over it.  It is designed to remove this burdon from the programmer so that they can focus on design rather than low level "did I allocate enough memory?" 



    exactly my point



  • @Xyro said:

    I am a Java developer and I care about CPU and memory.  I design my programs to be light and fluidic and responsible and XML-free. 



    you and 7 other Java Developers, find two more and you can call yourselves a minority :)



  • @Nelle said:

    @Xyro said:
    I am a Java developer and I care about CPU and memory.  I design my programs to be light and fluidic and responsible and XML-free. 

    you and 7 other Java Developers, find two more and you can call yourselves a minority :)
    Google's Java libraries are quite a nice piece of work.  I would even go as far as suggesting that their Collections framework (now part of Guava) is a showcase for model Java library development.

    But mostly I'm replying to you post because I'm curious:  what are we called when we're too small to be a minority?

    (Also, did a Java program steal your toys when you were young or something?)



  • @Xyro said:

    what are we called when we're too small to be a minority?
     

    Irrelevant.



  • @Someone You Know said:

    I took a look at the bytecode for a statement like this:

    Do you use any tools to disassemble Java .class files? JAD? A hexdump and the spec?

    Color me curious...



  • @zelmak said:

    @Someone You Know said:

    I took a look at the bytecode for a statement like this:

    Do you use any tools to disassemble Java .class files? JAD? A hexdump and the spec?

    Color me curious...

    In this case I used this Java Bytecode Editor. I examine Java bytecode so rarely that I haven't done any research on whether there are any better tools out there.

    (JAD decompiles a Java class file back into Java code, so it's not quite what we're looking for here.)




  • @zelmak said:

    @Someone You Know said:

    I took a look at the bytecode for a statement like this:

    Do you use any tools to disassemble Java .class files? JAD? A hexdump and the spec?

    Color me curious...

    If you're using Sun's Java, there's javap, no external tools required.


Log in to reply