Forgot your password?
typodupeerror

Comment: Re:Blu-ray? (Score 2) 339

by arjan_t (#47122773) Attached to: The Energy Saved By Ditching DVDs Could Power 200,000 Homes
I noticed the exact same thing. The reason why we bother is probably because nearly 8 years later it's still the highest quality you can buy, and it was miles better than any streaming format when blu-ray just came out. Even if in 6 years streaming will be in 50Mbit/s with better or comparable quality, then it still means we have had some 14 years where blu-ray was the best thing out there.

I also found blu-rays to be often cheaper than digital offerings (e.g. many TV shows are cheaper on blu-ray than they are on iTunes).

Further more, for a lot of countries (e.g. The Netherlands) download options for TV shows are incredibly limited. It's often impossible for those countries to stream from places like iTunes, Amazon or the Sony store. The number of shows offered on blu-ray is much larger and while blu-rays unfortunately can be region protected there are still more options to import.

+ - Early collection of Java EE 8 planning articles->

Submitted by Anonymous Coward
An anonymous reader writes "The work for Java EE 8 is currently in it’s early stages. Planning for the overall platform is well underway, but no official expert groups have been formed yet and details about individual specs are still scarce. This page will be updated continuously as more info becomes available . Java EE 8 is expected around 2016/2017 (“the usual pace”)."
Link to Original Source

+ - SSD-HDD Price Gap Won't Go Away Anytime Soon->

Submitted by storagedude
storagedude (1517243) writes "Flash storage costs have been dropping rapidly for years, but those gains are about to slow, and a number of issues will keep flash from closing the cost gap with HDDs for some time, writes Henry Newman at Enterprise Storage Forum. As SSD density increases, reliability and performance decrease, creating a dilemma for manufacturers who must balance density, cost, reliability and performance.

'[F]lash technology and SSDs cannot yet replace HDDs as primary storage for enterprise and HPC applications due to continued high prices for capacity, bandwidth and power, as well as issues with reliability that can only be addressed by increasing overall costs. At least for the foreseeable future, the cost of flash compared to hard drive storage is not going to change.'"

Link to Original Source

Comment: Re:Wonderful! (Score 1) 325

by arjan_t (#36242426) Attached to: Upscaling Retro 8-Bit Pixel Art To Vector Graphics

Either way, having 10 images of a guy who's head is a pixel block will not help you recreate his face.

Actually it could help improve the image. If those 10 images are part of a movement, then it's theoretically possible to reconstruct more detail. The original image moved along the scan-lines of a camera, and every successive shot might have captured a slightly different part of this original image. Understand the scan-lines and the movement, and there's more possible than you might think.

Comment: Java EE 6 - Zero XML (Score 1) 49

by arjan_t (#35885434) Attached to: Book Review: RESTful Java Web Services

In any fully compliant Java EE 6 application server(*), there is no configuration required at all. Just annotate a simple class in any package with @Path and @Produces. Then add a method that you annotate with @GET and you have a rest resource that can be invoked via the URL path specified in the annotations.

Zero XML and you literally have this running in under a minute.

*) Currently only Glassfish V3.x, but although not certified for the full Java EE 6 spec, JBoss AS 6 works too.

Comment: Re:FIRST (Score 1) 525

by arjan_t (#32854796) Attached to: Where I am now, it's ...
Pretty damn hot here in The Netherlands. 29~30 degrees room temperature. Just watched a blu-ray on my PS3 and it switched to the highest fan gear, the one you can normally only get by doing the 'fan test'.

(my PS3 is standing freely on a table without anything blocking its vents)

Comment: Re:Doing all my programming in C# (Score 1) 276

by arjan_t (#32803142) Attached to: Java's Backup Plan If Oracle Fumbles

Then you just don't handle them!

I hear you, but that wasn't what I meant really. When I don't want to handle exceptions because I simply can't handle them, I don't mean I want to swallow them.

In my personal experience, it seems that in a lot of cases the only sensible course of action is to let the exception bubble up right to some top handler that does 'handle' the exception by simply aborting the operating.

In a request/response Java EE situation, this simply means aborting the request and displaying a general error page. Runtime exceptions let you do exactly this without all the boiler plate code and verbosity, which can introduce its own bugs simply by means of obfuscating the real code in your system to your programmers.

No, you should declare an own exception, and wrap the exception of the dependencies in that new exception.

Indeed, this is a reasonable approach, but one that does lead to very deep levels of chained exceptions. Now if the exception is really exceptional this might not be the end of the world, but constantly applying the wrap-retrow pattern can still add a lot of mental overhead to your code. Sometimes this is justified, but in a lot of cases all you want is the exception to be handled by the top level exception handler. You're then creating lots of specific exceptions, lots of specific try/catch code, but it's never really used since it's only the first exception in the chain that counts and nothing is ever done with the intermediate ones.

I do agree that checked exceptions are a great way to force people to document what exceptions a method is expected to throw, which is indeed a benefit.

Anyway, I didn't really start the move away from checked exceptions, just observing that this seems to be happening ;)

Comment: Re:Java isn't really built for the future is it? (Score 1) 276

by arjan_t (#32792158) Attached to: Java's Backup Plan If Oracle Fumbles

... To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest...

Elegance? Closures? Now you have me scared. Really scared.

Don't be afraid for the unknown my brother. For these kinds of libraries closures actually are very elegant. Apple added a similar thing to C for their GCD library.

And about generics, they are definitely not a useless and dangerous disaster. Yes, you can go overboard with them, but when used in moderation (i.e. 'typing containers'), they work perfectly fine. Much better than having to downcast Object all the time to some type I think might be inserted into the collection.

Comment: Re:Doing all my programming in C# (Score 1) 276

by arjan_t (#32791718) Attached to: Java's Backup Plan If Oracle Fumbles

No, it is actually worse to have only RuntimeExceptions and handle none..

Checked vs unchecked is and endless debate in Java, but to add my 2 cents:

If you only have RunTimeExceptions, then at run time the error actually will surface if you don't explicitly handle them. This means your unit tests and integration tests (you do have those, don't you?) will most likely catch them.

Checked exceptions are only useful if you can handle them, but 99 out of 100 times you can't. If there's a SQLException being thrown, seriously, what can your code do about it? In practice what we see is that either exceptions get wrapped and wrapped and wrapped... up till 10 levels or more deep. Alternatively, your code can declare the exceptions being thrown by its dependencies, but then you end up with dependencies bleeding into layers where they have no business.

Comment: Re:Doing all my programming in C# (Score 1) 276

by arjan_t (#32791670) Attached to: Java's Backup Plan If Oracle Fumbles

Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance.

That's only partially true. If the language would only have checked exceptions and you would be coding against interfaces (often still the case with dynamically-loaded code), then checked exceptions would still work, whether the code implementing said interfaces was dynamically loaded or not.

Now the problem here is that there are also unchecked exceptions which the code might throw, but this is really unrelated to the dynamic loading. One thing that could break things though, is if you not only dynamically load the code, but also execute said code via reflection. Then indeed checked exceptions might not do anything...

Comment: Re:What could possibly go wrong ... (Score 1) 276

by arjan_t (#32791644) Attached to: Java's Backup Plan If Oracle Fumbles

People need to remember that if something is really open, then it also means it is open to someone doing their own thing with it.

Right, and so many companies actually did with Java. Only with one 'minor' difference: they didn't call it "Java SE".

The problem with MS was not that it was extending Java, but that it was luring programmers into thinking they were coding for the Java SE standard. If you were at a MS platform and only checked your code with Visual Studio, then you as a programmer wouldn't know. Until your users tried to run your Java app on their Linux or Solaris boxes, and found out it didn't work at all.

A very simple solution for MS would have been to provide flags in their environment for "standard compliance Java development" and "non-standard compliance Java development". If my memory serves me well, they had such flags for C++ in their compiler.

Comment: Re:The next Cobol? (Score 1) 276

by arjan_t (#32791624) Attached to: Java's Backup Plan If Oracle Fumbles

Java, while widely used is on the down slide. There really hasn't been any new revolutionary additions to the language in about 7 years. In another 10 years, it will become like COBOL is to IBM.

The only thing that has remained the same in about 7 years are the posts about "Java is dead", meanwhile Java is still the most widely used language and in those 7 years additions have been made to the language (generics, annotations, type safe enums, etc) and soon we'll have some extra goodies like closures and automatic resource management. Maybe those are not revolutionary, but enough IMHO to keep the language with the times.

Meanwhile, there is a lot of innovation going on in the platform, especially with Java EE and how it uses annotations for things other languages might use keywords for (e.g. annotations to make methods transactional).

Comment: Re:Java isn't really built for the future is it? (Score 4, Insightful) 276

by arjan_t (#32791606) Attached to: Java's Backup Plan If Oracle Fumbles

Is Java doomed to get stuck behind in the single processor world

Far from it actually... of course Java has had the absolute low level concurrency primitives from the very beginning (Threads, synchronized blocks, wait/notify). More than half a decade ago, the java.concurrent library was added to the platform, which added tons of goodies for concurrent/parallel programming like concurrent maps, blocking queues, thread pools and executor services, cyclic barriers, programmatic locks with timeouts (which actually performed better than the build-in locks based on the synchronized keyword) etc.

Now Java 7 will be extended with the join/fork framework, which is essentially a thread pool and support code for (recursively) computational intensive operations and supports advanced features like work stealing. The join/fork framework has been specifically designed to scale into the many, many multi-core range. Not just quad, hex or oct cores but well beyond that.

Parallel array is another topic on the agenda, which allows you to express in an almost declarative style operations on arrays, which the library will then execute for you in parallel. To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest.

This blog post has a nice summary about some of the added concurrency items in Java 7: http://www.baptiste-wicht.com/2010/04/java-7-more-concurrency/

Refreshed by a brief blackout, I got to my feet and went next door. -- Martin Amis, _Money_

Working...