Search Results

Search found 67 results on 3 pages for 'polygenelubricants'.

Page 2/3 | < Previous Page | 1 2 3  | Next Page >

  • Extending Throwable in Java

    - by polygenelubricants
    Java lets you create an entirely new subtype of Throwable, e.g: public class FlyingPig extends Throwable { ... } Now, very rarely, I may do something like this: throw new FlyingPig("Oink!"); and of course elsewhere: try { ... } catch (FlyingPig porky) { ... } My questions are: Is this a bad idea? And if so, why? What could've been done to prevent this subtyping if it is a bad idea? Since it's not preventable (as far as I know), what catastrophies could result? If this isn't such a bad idea, why not? How can you make something useful out of the fact that you can extends Throwable?

    Read the article

  • Errata for Java Language Specification 3rd Edition

    - by polygenelubricants
    I use JLS extensively both as a learning and teaching resource, but I've noticed that there are some errors in it. There's the simple typos (e.g. JLS 5.1.4 "convesions"), but there's also some that I consider quite serious errors. For example, JLS 18.1 The Grammar of the Java Programming Language is supposed to be the authoritative reference for the grammar of the Java language, but it contains a production rule that never gets used! (e.g. MoreStatementExpressions). Surely this is a sign of more serious errors in other parts of the given grammar, right? So is there an errata for the 3rd edition? Will there ever be? Should we send errors we've found to Sun/Oracle? Will there ever be a 4th edition?

    Read the article

  • Backreferences syntax in replacement strings (why dollar sign?)

    - by polygenelubricants
    In Java, and it seems in a few other languages, backreferences in the pattern is preceded by a slash (e.g. \1, \2, \3, etc), but in a replacement string it's preceded by a dollar sign (e.g. $1, $2, $3, and also $0). Here's a snippet to illustrate: System.out.println( "left-right".replaceAll("(.*)-(.*)", "\\2-\\1") // WRONG!!! ); // prints "2-1" System.out.println( "left-right".replaceAll("(.*)-(.*)", "$2-$1") // CORRECT! ); // prints "right-left" System.out.println( "You want million dollar?!?".replaceAll("(\\w*) dollar", "US\\$ $1") ); // prints "You want US$ million?!?" System.out.println( "You want million dollar?!?".replaceAll("(\\w*) dollar", "US$ \\1") ); // throws IllegalArgumentException: Illegal group reference Questions: Is the use of $ for backreferences in replacement strings unique to Java? If not, what language started it? What flavors use it and what don't? Why is this a good idea? Why not stick to the same pattern syntax? Wouldn't that lead to a more cohesive and an easier to learn language? Wouldn't the syntax be more streamlined if statements 1 and 4 in the above were the "correct" ones instead of 2 and 3?

    Read the article

  • Auto-(un)boxing fail for compound assignment

    - by polygenelubricants
    Thanks to the implicit casting in compound assignments and increment/decrement operators, the following compiles: byte b = 0; ++b; b++; --b; b--; b += b -= b *= b /= b %= b; b <<= b >>= b >>>= b; b |= b &= b ^= b; And thanks to auto-boxing and auto-unboxing, the following also compiles: Integer ii = 0; ++ii; ii++; --ii; ii--; ii += ii -= ii *= ii /= ii %= ii; ii <<= ii >>= ii >>>= ii; ii |= ii &= ii ^= ii; And yet, the last line in the following snippet gives compile-time error: Byte bb = 0; ++bb; bb++; --bb; bb--; // ... okay so far! bb += bb; // DOESN'T COMPILE!!! // "The operator += is undefined for the argument type(s) Byte, byte" Can anyone help me figure out what's going on here? The byte b version compiles just fine, so shouldn't Byte bb just follow suit and do the appropriate boxing and unboxing as necessary to accommodate?

    Read the article

  • Is -1 a magic number? An anti-pattern? A code smell? Quotes and guidelines from authorities

    - by polygenelubricants
    I've seen -1 used in various APIs, most commonly when searching into a "collection" with zero-based indices, usually to indicate the "not found" index. This "works" because -1 is never a legal index to begin with. It seems that any negative number should work, but I think -1 is almost always used, as some sort of (unwritten?) convention. I would like to limit the scope to Java at least for now. My questions are: What are the official words from Sun regarding using -1 as a "special" return value like this? What quotes are there regarding this issue, from e.g. James Gosling, Josh Bloch, or even other authoritative figures outside of Java? What were some of the notable discussions regarding this issue in the past?

    Read the article

  • ArithmeticException thrown during BigDecimal.divide

    - by polygenelubricants
    I thought java.math.BigDecimal is supposed to be The Answer™ to the need of performing infinite precision arithmetic with decimal numbers. Consider the following snippet: import java.math.BigDecimal; //... final BigDecimal one = BigDecimal.ONE; final BigDecimal three = BigDecimal.valueOf(3); final BigDecimal third = one.divide(three); assert third.multiply(three).equals(one); // this should pass, right? I expect the assert to pass, but in fact the execution doesn't even get there: one.divide(three) causes ArithmeticException to be thrown! Exception in thread "main" java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result. at java.math.BigDecimal.divide It turns out that this behavior is explicitly documented in the API: In the case of divide, the exact quotient could have an infinitely long decimal expansion; for example, 1 divided by 3. If the quotient has a non-terminating decimal expansion and the operation is specified to return an exact result, an ArithmeticException is thrown. Otherwise, the exact result of the division is returned, as done for other operations. Browsing around the API further, one finds that in fact there are various overloads of divide that performs inexact division, i.e.: final BigDecimal third = one.divide(three, 33, RoundingMode.DOWN); System.out.println(three.multiply(third)); // prints "0.999999999999999999999999999999999" Of course, the obvious question now is "What's the point???". I thought BigDecimal is the solution when we need exact arithmetic, e.g. for financial calculations. If we can't even divide exactly, then how useful can this be? Does it actually serve a general purpose, or is it only useful in a very niche application where you fortunately just don't need to divide at all? If this is not the right answer, what CAN we use for exact division in financial calculation? (I mean, I don't have a finance major, but they still use division, right???).

    Read the article

  • Backslashes in gsub (escaping and backreferencing)

    - by polygenelubricants
    Consider the following snippet: puts 'hello'.gsub(/.+/, '\0 \\0 \\\0 \\\\0') This prints (as seen on ideone.com): hello hello \0 \0 This was very surprising, because I'd expect to see something like this instead: hello \0 \hello \\0 My argument is that \ is an escape character, so you write \\ to get a literal backslash, thus \\0 is a literal backslash \ followed by 0, etc. Obviously this is not how gsub is interpreting it, so can someone explain what's going on? And what do I have to do to get the replacement I want above?

    Read the article

  • Best practices regarding equals: to overload or not to overload?

    - by polygenelubricants
    Consider the following snippet: import java.util.*; public class EqualsOverload { public static void main(String[] args) { class Thing { final int x; Thing(int x) { this.x = x; } public int hashCode() { return x; } public boolean equals(Thing other) { return this.x == other.x; } } List<Thing> myThings = Arrays.asList(new Thing(42)); System.out.println(myThings.contains(new Thing(42))); // prints "false" } } Note that contains returns false!!! We seems to have lost our things!! The bug, of course, is the fact that we've accidentally overloaded, instead of overridden, Object.equals(Object). If we had written class Thing as follows instead, then contains returns true as expected. class Thing { final int x; Thing(int x) { this.x = x; } public int hashCode() { return x; } @Override public boolean equals(Object o) { return (o instanceof Thing) && (this.x == ((Thing) o).x); } } Effective Java 2nd Edition, Item 36: Consistently use the Override annotation, uses essentially the same argument to recommend that @Override should be used consistently. This advice is good, of course, for if we had tried to declare @Override equals(Thing other) in the first snippet, our friendly little compiler would immediately point out our silly little mistake, since it's an overload, not an override. What the book doesn't specifically cover, however, is whether overloading equals is a good idea to begin with. Essentially, there are 3 situations: Overload only, no override -- ALMOST CERTAINLY WRONG! This is essentially the first snippet above Override only (no overload) -- one way to fix This is essentially the second snippet above Overload and override combo -- another way to fix The 3rd situation is illustrated by the following snippet: class Thing { final int x; Thing(int x) { this.x = x; } public int hashCode() { return x; } public boolean equals(Thing other) { return this.x == other.x; } @Override public boolean equals(Object o) { return (o instanceof Thing) && (this.equals((Thing) o)); } } Here, even though we now have 2 equals method, there is still one equality logic, and it's located in the overload. The @Override simply delegates to the overload. So the questions are: What are the pros and cons of "override only" vs "overload & override combo"? Is there a justification for overloading equals, or is this almost certainly a bad practice?

    Read the article

  • Premature optimization is the root of all evil, but can it ever be too late?

    - by polygenelubricants
    "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" So what is that 3% like? Can the avoidance of premature optimization ever be taken too extreme that it does more harm than good? Even if it's rare, has there been a case of a real measurable software engineering disaster due to complete negligence to optimize early in the process? Bonus question: is software engineering pretty much the only field that has such a counter intuitive principle regarding doing something earlier rather than later before things potentially become too big a problem to fix? Personal question: how do you justify something as premature optimization and not just a case of you being lazy/ignorant/dumb?

    Read the article

  • Using explicitly numbered repetition instead of question mark, star and plus

    - by polygenelubricants
    I've seen regex patterns that use explicitly numbered repetition instead of ?, * and +, i.e.: Explicit Shorthand (something){0,1} (something)? (something){1} (something) (something){0,} (something)* (something){1,} (something)+ The questions are: Are these two forms identical? What if you add possessive/reluctant modifiers? If they are identical, which one is more idiomatic? More readable? Simply "better"?

    Read the article

  • Is it bad to explicitly compare against boolean constants e.g. if (b == false) in Java?

    - by polygenelubricants
    Is it bad to write: if (b == false) //... while (b != true) //... Is it always better to instead write: if (!b) //... while (!b) //... Presumably there is no difference in performance (or is there?), but how do you weigh the explicitness, the conciseness, the clarity, the readability, etc between the two? Note: the variable name b is just used as an example, ala foo and bar.

    Read the article

  • Can you use zero-width matching regex in String split?

    - by polygenelubricants
    System.out.println( Arrays.deepToString( "abc<def>ghi".split("(?:<)|(?:>)") ) ); This prints [abc, def, ghi], as if I had split on "<|>". I want it to print [abc, <def>, ghi]. Is there a way to work some regex magic to accomplish what I want here? Perhaps a simpler example: System.out.println( Arrays.deepToString( "Hello! Oh my!! Good bye!!".split("(?:!+)") ) ); This prints [Hello, Oh my, Good bye]. I want it to print [Hello!, Oh my!!, Good bye!!]. `.

    Read the article

  • How to limit setAccessible to only "legitimate" uses?

    - by polygenelubricants
    The more I learned about the power of setAccessible, the more astonished I am at what it can do. This is adapted from my answer to the question (Using reflection to change static final File.separatorChar for unit testing). import java.lang.reflect.*; public class EverythingIsTrue { static void setFinalStatic(Field field, Object newValue) throws Exception { field.setAccessible(true); Field modifiersField = Field.class.getDeclaredField("modifiers"); modifiersField.setAccessible(true); modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL); field.set(null, newValue); } public static void main(String args[]) throws Exception { setFinalStatic(Boolean.class.getField("FALSE"), true); System.out.format("Everything is %s", false); // "Everything is true" } } You can do truly outrageous stuff: public class UltimateAnswerToEverything { static Integer[] ultimateAnswer() { Integer[] ret = new Integer[256]; java.util.Arrays.fill(ret, 42); return ret; } public static void main(String args[]) throws Exception { EverythingIsTrue.setFinalStatic( Class.forName("java.lang.Integer$IntegerCache") .getDeclaredField("cache"), ultimateAnswer() ); System.out.format("6 * 9 = %d", 6 * 9); // "6 * 9 = 42" } } Presumably the API designers realize how abusable setAccessible can be, but must have conceded that it has legitimate uses to provide it. So my questions are: What are the truly legitimate uses for setAccessible? Could Java has been designed as to NOT have this need in the first place? What would the negative consequences (if any) of such design be? Can you restrict setAccessible to legitimate uses only? Is it only through SecurityManager? How does it work? Whitelist/blacklist, granularity, etc? Is it common to have to configure it in your applications?

    Read the article

  • ChoiceFormat.setChoices confusion about format parameter type and documentation

    - by polygenelubricants
    From the java.text.ChoiceFormat API: setChoices(double[] limits, String[] formats): Set the choices to be used in formatting. Parameters: limits - contains [...] formats - are the formats you want to use for each limit. They can be either Format objects or Strings. When formatting with object Y, if the object is a NumberFormat, then ((NumberFormat) Y).format(X) is called. Otherwise Y.toString() is called. I'm having difficulties understanding the documentation for the formats parameter: how can you possibly pass a Format/NumberFormat object to setChoices if it's declared String[] formats? Note that interestingly, the getters counterpart of setChoices are declared as follows: double[] getLimits() Object[] getFormats() -- not String[]!!! Is this a bug in the API? Should the setter have been declared setChoices(double[], Object[]) instead, or am I not understanding how to use setChoices correctly?

    Read the article

  • Regular expression: who's greedier?

    - by polygenelubricants
    My primary concern is with the Java flavor, but I'd also appreciate information regarding others. Let's say you have a subpattern like this: (.*)(.*) Not very useful as is, but let's say these two capture groups (say, \1 and \2) are part of a bigger pattern that matches with backreferences to these groups, etc. So both are greedy, in that they try to capture as much as possible, only taking less when they have to. My question is: who's greedier? Does \1 get first priority, giving \2 its share only if it has to? What about: (.*)(.*)(.*) Let's assume that \1 does get first priority. Let's say it got too greedy, and then spit out a character. Who gets it first? Is it always \2 or can it be \3? Let's assume it's \2 that gets \1's rejection. If this still doesn't work, who spits out now? Does \2 spit to \3, or does \1 spit out another to \2 first?

    Read the article

  • Beginner SQL section: avoiding repeated expression

    - by polygenelubricants
    I'm entirely new at SQL, but let's say that on the StackExchange Data Explorer, I just want to list the top 15 users by reputation, and I wrote something like this: SELECT TOP 15 DisplayName, Id, Reputation, Reputation/1000 As RepInK FROM Users WHERE RepInK > 10 ORDER BY Reputation DESC Currently this gives an Error: Invalid column name 'RepInK', which makes sense, I think, because RepInK is not a column in Users. I can easily fix this by saying WHERE Reputation/1000 > 10, essentially repeating the formula. So the questions are: Can I actually use the RepInK "column" in the WHERE clause? Do I perhaps need to create a virtual table/view with this column, and then do a SELECT/WHERE query on it? Can I name an expression, e.g. Reputation/1000, so I only have to repeat the names in a few places instead of the formula? What do you call this? A substitution macro? A function? A stored procedure? Is there an SQL quicksheet, glossary of terms, language specification, anything I can use to quickly pick up the syntax and semantics of the language? I understand that there are different "flavors"?

    Read the article

  • Parantheses around method invokation: why is the compiler complaining about assignment?

    - by polygenelubricants
    I know why the following code doesn't compile: public class Main { public static void main(String args[]) { main((null)); // this is fine! (main(null)); // this is NOT! } } What I'm wondering is why my compiler (javac 1.6.0_17, Windows version) is complaining "The left hand side of an assignment must be a variable". I'd expect something like "Don't put parantheses around a method invokation, dummy!", instead. So why is the compiler making a totally unhelpful complaint about something that is blatantly irrelevant? Is this the result of an ambiguity in the grammar? A bug in the compiler? If it's the former, could you design a language such that a compiler would never be so off-base about a syntax error like this?

    Read the article

  • Weird compile-time behavior when trying to use primitive type in generics

    - by polygenelubricants
    import java.lang.reflect.Array; public class PrimitiveArrayGeneric { static <T> T[] genericArrayNewInstance(Class<T> componentType) { return (T[]) Array.newInstance(componentType, 0); } public static void main(String args[]) { int[] intArray; Integer[] integerArray; intArray = (int[]) Array.newInstance(int.class, 0); // Okay! integerArray = genericArrayNewInstance(Integer.class); // Okay! intArray = genericArrayNewInstance(int.class); // Compile time error: // cannot convert from Integer[] to int[] integerArray = genericArrayNewInstance(int.class); // Run time error: // ClassCastException: [I cannot be cast to [Ljava.lang.Object; } } I'm trying to fully understand how generics works in Java. Things get a bit weird for me in the 3rd assignment in the above snippet: the compiler is complaining that Integer[] cannot be converted to int[]. The statement is 100% true, of course, but I'm wondering WHY the compiler is making this complaint. If you comment that line, and follow the compiler's "suggestion" as in the 4th assignment, the compiler is actually satisfied!!! NOW the code compiles just fine! Which is crazy, of course, since like the run time behavior suggests, int[] cannot be converted to Object[] (which is what T[] is type-erased into at run time). So my question is: why is the compiler "suggesting" that I assign to Integer[] instead for the 3rd assignment? How does the compiler reason to arrive to that (erroneous!) conclusion?

    Read the article

  • Is there a linear-time performance guarantee with using an Iterator?

    - by polygenelubricants
    If all that you're doing is a simple one-pass iteration (i.e. only hasNext() and next(), no remove()), are you guaranteed linear time performance and/or amortized constant cost per operation? Is this specified in the Iterator contract anywhere? Are there data structures/Java Collection which cannot be iterated in linear time? java.util.Scanner implements Iterator<String>. A Scanner is hardly a data structure (e.g. remove() makes absolutely no sense). Is this considered a design blunder? Is something like PrimeGenerator implements Iterator<Integer> considered bad design, or is this exactly what Iterator is for? (hasNext() always returns true, next() computes the next number on demand, remove() makes no sense). Similarly, would it have made sense for java.util.Random implements Iterator<Double>?

    Read the article

  • Writing a synchronized thread-safety wrapper for NavigableMap

    - by polygenelubricants
    java.util.Collections currently provide the following utility methods for creating synchronized wrapper for various collection interfaces: synchronizedCollection(Collection<T> c) synchronizedList(List<T> list) synchronizedMap(Map<K,V> m) synchronizedSet(Set<T> s) synchronizedSortedMap(SortedMap<K,V> m) synchronizedSortedSet(SortedSet<T> s) Analogously, it also has 6 unmodifiedXXX overloads. The glaring omission here are the utility methods for NavigableMap<K,V>. It's true that it extends SortedMap, but so does SortedSet extends Set, and Set extends Collection, and Collections have dedicated utility methods for SortedSet and Set. Presumably NavigableMap is a useful abstraction, or else it wouldn't have been there in the first place, and yet there are no utility methods for it. So the questions are: Is there a specific reason why Collections doesn't provide utility methods for NavigableMap? How would you write your own synchronized wrapper for NavigableMap? Glancing at the source code for OpenJDK version of Collections.java seems to suggest that this is just a "mechanical" process Is it true that in general you can add synchronized thread-safetiness feature like this? If it's such a mechanical process, can it be automated? (Eclipse plug-in, etc) Is this code repetition necessary, or could it have been avoided by a different OOP design pattern?

    Read the article

  • Is concatenating with an empty string to do a string conversion really that bad?

    - by polygenelubricants
    Let's say I have two char variables, and later on I want to concatenate them into a string. This is how I would do it: char c1, c2; // ... String s = "" + c1 + c2; I've seen people who say that the "" + "trick" is "ugly", etc, and that you should use String.valueOf or Character.toString instead. I prefer this construct because: I prefer using language feature instead of API call if possible In general, isn't the language usually more stable than the API? If language feature only hides API call, then even stronger reason to prefer it! More abstract! Hiding is good! I like that the c1 and c2 are visually on the same level String.valueOf(c1) + c2 suggests something is special about c1 It's shorter. Is there really a good argument why String.valueOf or Character.toString is preferrable to "" +? Trivia: in java.lang.AssertionError, the following line appears 7 times, each with a different type: this("" + detailMessage);

    Read the article

< Previous Page | 1 2 3  | Next Page >