M Beck

Originally posted by P. Ingle:
I am loading native library in static block - which, if fails, shuts JVM all together. I would like to have some graceful way of handling this situation.

if the failure really should exit the entire program, then you don't need to throw an exception in order to achieve this — you can just print an error message and System.exit() to get out. in fact, that would likely be more graceful than leaving the user with a stack dump from an unhandled exception on the screen.

to the best of my knowledge, there is no difference between them; i have always understood the terms to be synonyms. that said, in Java the word "reflection" seems to be the preferred one, the word "introspection" seems more popular among users of some other languages.

what the thing does is let you operate on the structure of classes. Sun has a tutorial on the topic, and it is also mentioned in the API.

what are the most common ways in which this approach fails? how does your recommendation for using java.lang.ClassLoader avoid those failures, and how does it answer the original question concerning adding items to the system classpath? what if i want to modify the behaviour of the default class loader?

what about it looks dangerous to you? sure, it ties you to certain versions of the API, and forces you to re-test your code every time a new version of the API is released, but other than that i see nothing platform-specific about it at all. using it would be a burden on testing and maintenance, but honestly, i see little real danger in it. i'd be interested in hearing what about it scares you.

it's kindof hard to completely ignore Java's OO features when you have to write all your code in classes, and explicitly type your "main" as "public static". ;-)

what exactly is "OO" will likely be debated forever. i like this summary of things people usually want in an "OO language", for a quick reference; note item 6, which has been brought up in this thread already. personally, i'm fond of items 5 and 3.

the language comparison that's been referred to here seems out of date. i know recent Python versions no longer use reference counting alone in their garbage collector, for example, and the column for Visual Basic is not talking about VB.NET, which is a quite different language from pre-dotnet versions. it's a good starting point, but i suspect no comparison of this sort can ever be kept very well up to date as there is simply too much change to track in too many different environments.

the worst flaw with that comparison seems to be that it apparently takes the Capers Jones language level study seriously. that latter study ranks "languages" such as HTML, Excel, shell scripts, and COBOL on a single linear scale... and ranks HTML higher than (for example) Lisp. i'm sorry, but anyone who thinks that is more than a bad joke frankly brings their own judgement into question.

depending on exactly what the linux platform is, the package manager might actually be of considerable help. packages often can list what "features" they provide, and some package managers can be asked what packages provide a given "feature". for example, on my Mandrake Linux system, i can do this:
# rpm -q --whatprovides webclient links-graphic-2.1-0.pre11.1mdk lynx-2.8.5-1mdk links-2.1-0.pre13.3mdk kdebase-common-3.2.3-134.8.101mdk mozilla-1.7.2-12.2.101mdk epiphany-1.2.8-4.2.101mdk wget-1.9.1-4.2.101mdk
here, the "webclient" feature should be "provided" by every package that can serve as a "web browser" of sorts. but there are several things to note:

some of the items make little sense. "kdebase-common", for example. well, that's because the KDE desktop environment has a "file manager" that can double as a web browser... but unless you knew that about KDE, you'd be unlikely to know what that item was about.

some of the items aren't what you'd think of as a "web client". wget, for example, just downloads files to your hard disk, it doesn't try to display them at all. is that a "web client"? well, it speaks HTTP, so...

it missed my firefox, because that wasn't installed using the package manager.

i had to know that "webclient" was the right "feature" to use. not every distribution will necessarily use that name for it.

not every distribution will necessarily use a package manager that can do this at all!

so, for certain specific cases — for example, if you decide to formally support only one linux distribution — this might be of some use. but in the general case, when you need true platform independence, Ernest's advice is far better; in those cases, you'll just have to search for executable file names. or ask the user which browser to start.

very true. but more to the original poster's point, even though double has higher precision than float, it's not necessarily a superset of float — there may be (and probably are) many numbers that "float" can represent exactly yet double can only approximate.

to make a long story short, the problem mr. Walters was seeing stems from a floating-point conversion operation. when a float is cast to a double, the implicit conversion — like any other operation on floating-point numbers, really — always runs a risk of rounding error, introducing inaccuracy. frankly, i'm surprised that a double declared from a constant doesn't also reduce to the same inaccurate approximation as the double cast from a float. i can only assume that the compiler uses a different conversion method when reading constants from source code than the JVM uses when casting variables at run-time. which is odd, but i've seen odder...

you might want to read this paper.

in short, floating-point types like "float" and "double" are never exact; they are only approximations of the number you want. the differences between the number you want and the number you get, with these types, are complex and detailed, but can be considered more or less random, at least as a rule of thumb.

moreover, the differently-sized floating point types (float versus double, in your case) are inexact in different ways. "double" has more power to represent more decimal places — or to represent larger numbers without dropping low-order digits — but there's not necessarily any one-to-one correspondence between the numbers a "float" can represent and those that "double" can represent, and the inaccuracies each format will introduce are different too.

this is just a fact of life when using floating-point numbers. if it's simply not acceptable, either use rounding methods to your desired number of decimal points, or find a way to make do with integers alone.

actually, if this is a web app, you'll likely want to use higher-level APIs corresponding to www/http concepts, rather than the raw sockets those are built on. look into the java.net package and its classes; the HttpURLConnection class looks promising to me.

if you're willing to go beyond Sun's basic API, then Jakarta Commons looks like it might have a few useful classes. its FileUpload and HttpClient might do things you will want done, perhaps.

count another person who's surprised Apple's going with Intel over AMD. especially if they're looking at performance-per-watt and the laptop market; i would have thought AMD64 should be a far more natural choice under those circumstances. i can only speculate that Intel must have cut a very, very sweet deal for Steve Jobs behind the scenes.

it will be interesting to see if this lets Intel catch up to AMD's multi-core CPU's in the future. i would think Apple's dual-CPU experience could become a driver for that, but it remains to be seen if Intel will listen, or even if they do, whether they can follow through.

performance-wise, i doubt there'll be any huge difference. finding SPECint/SPECfp numbers for Apple's hardware seems difficult, but IBM's server line CPU's do not appear to be performing noticeably better than current Intel/AMD hardware. even if present-day PPCs are faster dollar for dollar than Intel-compatible silicon, that won't last long with the way Intel and AMD have been improving their goods lately; over the long run, switching CPU's will certainly be a performance win for Apple.

other than locking yourself even more closely to your database, you mean? possibly nothing, possibly everything. you might not care about being very closely tied to one given DBMS; then again, maybe you do.

rolling out new releases and testing development code might be trickier if you have to update stored procedures on a "testing" database. testing itself might be trickier or slower if your test cases / test harnesses have to connect to a DB to run. getting the most out of a revision control system might be tricky if the code has to be stored in a database as well; you might run into a "dueling versions" problem between your RCS and your testing DBMS. your coders might have to worry more about database administration than they might like to, and/or get into disputes with your DBA's, if you have any.

you can probably add to the list yourself, but any or all of the items might not be enough of a concern to tip the balance, depending on what your priorities are. you tell us.

when other code uses your code incorrectly, and your code does whatever it does to indicate it's been abused by bad input, it's much easier and more intuitive for the other code to try and catch an IllegalArgumentException than it is to understand why your code suddenly caused an AssertionError.

after all, how often have you written "catch (AssertionError e)" on somebody else's code, as opposed to "catch (IllegalArgumentException e)"? don't you think the latter is far more descriptive of what actually happened?

it's not necessary in Java, but i like to do it myself too. it makes explicit that you're referring to an instance method/variable as opposed to a static method/variable; in the case of variables, it also distinguishes between locals and instance/class variables. i feel explicit is better than implicit, so i accept the extra verbosity of using the "unnecessary" this everywhere.

Originally posted by seb petterson:
bean2.setStringProp(Integer.toString(bean1.getIntegerProp()) And it compiles and works. But when I think about it, it shouldnt work. Because Integer.toString() doesnt take an Integer as argument, only int. Where's the magic?

if you're using Java 5, the magic is in autoboxing. it's a new feature in that version. if you're using java 1.4 or earlier, then you're right, that shouldn't work.

for integer exponents, it's reasonably easy to build your own pow() function. (easy enough that i have to wonder why it isn't there already, in fact...) negative integer exponents just take an additional division operation, and that's there. but real-number exponents would need a natural-logarithm function, which i see isn't there; on them, you may be out of luck (unless you're willing to put in the effort to fix this class up, that is).