Slashdot Mirror
Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU
An anonymous reader writes "Today the source code to the Rootbeer GPU Compiler was released as open source on github. This work allows for a developer to use almost any Java code on the GPU. It is free, open source and highly tested. Rootbeer is the most full featured translator to convert Java Bytecode to CUDA. It allows arbitrary graphs of objects to be serialized to the GPU and the GPU kernel to be written in Java." Rootbeer is the work of Syracuse University instructor Phil Pratt-Szeliga.
This work allows for a developer to use almost any Java code on the GPU.
Except for the code my students write. :rolleyes:
Taking guns away from the 99% gives the 1% 100% of the power.
Maybe now the x264 developers will add GPU support and we'll finally have a solution for video encoding that uses the processor and GPUs in parallel. Here's to hoping... :\
#fuckbeta #iamslashdot #dicemustdie
Why?
Pretty much. Now, instead of having to bundle your blessed version of java and libraries with the app, you have to bundle those, AND a graphics card that speaks CUDA and has a specific driver version.
That whole "write once, run anywhere" was never true, and not only because it's stretching the word "run". Now it gets even less true.
The WORA aspects of Java work flawlessly these days.
Mod me down, my New Earth Global Warmingist friends!
2004 called, they want their blind hate for Java back.
Used intelligently by a skilled programmer, Java can deliver great results and provide exactly the sort of cross platform capabilities it was designed for. Used by idiots and/or kids who just earned that undergrad CS degree, it tends to provide less.
-Lod
You don't have to update and if you do, it doesn't break compatibility with existing apps.
Mod me down, my New Earth Global Warmingist friends!
Summary says it's a compiler. It should not force GPL on it's output any more than GCC would.
If I write proprietary code with gedit, is it forced to be GPL?
Unicode in Slashdot
2004 called, they want their blind hate for Java back.
Used intelligently by a skilled programmer, Java can deliver great results and provide exactly the sort of cross platform capabilities it was designed for. Used by idiots and/or kids who just earned that undergrad CS degree, it tends to provide less.
Just like any other programming language?
This is simply not true for code written by a professional and competent Java developer (note: part of my consulting gig means I code Java on a professional basis).
If you write only to the public APIs then Java truly is Write-Once-Run-Anywhere (although some bad Java developers use internal functionality that can change between Java versions - I'm guessing that perhaps these folks are used to coding to the Undocumented APIs of Win32 that you used to have to use to get things done). In Java you shouldn't do this. IIRC, Sun created around ten thousand unit tests to ensure Java worked correctly on each platform (wonderful, they did all the porting and port testing effort so Java developers don't have to).
Aside from my professional coding (where Java written on a Mac works flawlessly when deployed to Linux and Windows servers) in my spare time I'm working on modern jet air combat simulator in Java. The same Java+JoGL code works flawlessly on Mac, Linux and Windows. Any differences are in capabilities/performance of individual graphics cards (AMD/ATI vs NVidia).
This article about being able to write Java for the GPU is very interesting, since writing shaders via OpenGL is a little bit of a PITA (there is an impedance mismatch between the conventions of Java, OpenGL and GLSL - it would be fabulous to just write in Java [akin to how I can do this on the Web using Google Web Toolkit]).
So I don't think your statement is really true - except for buggy software written by developers who have bad simple-platform habits.
Usually there is only a problem when your application server (I'm looking at you, stinky Websphere) relies on a particular vendor's implementation of Java (eg. IBM JDK). With recent Sun/Oracle Java Runtime Environments (that is: Java 6, which is around 5 years old; and Java 7) applications usually run flawlessly (at least, mine do - and I'm doing all the usual Java funky stuff: radar, roadsign and head tracking hardware device control, networking, web, 3D graphics, rich clients, etc).
As a current practitioner in the field I wonder whether your experience is from a long time ago (and polluted by the experience of using software that was based on Microsoft's awful [and deliberately incompatible - which they lost the famous lawsuit over] Java implementation from a long time ago).
It's CUDA only, meaning it does not support any open standards. Call me when when I can target OpenCL.
---- GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
released as open source on github
Damn, Slashdot, I almost had a freaking heart attack when I moused over (you don't think I actually clicked do you? New here?) the link in the summary and it was to the actual github page rather than some crappy 10 page blog post based on something pulled off the reuters wire from last week.
I'm impressed!
The soylentnews experiment has been a dismal failure.
You must run some VERY different apps than I do. Every management app I've used seems to be tied to different versions of java everything for ui glitches though plain just not working.
No sir I dont like it.
"Used intelligently by a skilled programmer"
2010 called. What you ask for is in extremely short stock and will be as long as the educational systems go to shit.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Whose freedom is limited ?
The only limit I know is enforced by Microsoft who forbids its employees to read xGPL'd source code.
My opinion is that the GPL is a license that tells the user to be responsible and respectful of the authors's work.
For the record, I don't have an account here. How could I mod you in any way ?
OK, I return to my JavaScript stupidities, licensed under AGPLv3 :-D
Um, 'scuse me, you got a license for the use of the word Java in that first post?
-- Oracle lawweasel
Primarily with those java management apps related to networking kit. You know those things that are embedded in firmware and sometimes the only way to do more than get an IP on the box to get to said java nightmare. I've had the issues as recent as a few weeks ago when a java update stopped some dialog boxes from working on a supermicro ipkvm java app. Same update killed all my ASDM java apps for working with CIsco ASA's (though it still works as a web app for whatever reasons)
No sir I dont like it.
He means it would be too slow to fly to java before posting from an internet cafe.
http://michaelsmith.id.au
Guess what I'm not coding for it just using apps from major corps. Those fun management apps that on some kit you must use as the cli will only setup basic ip settings, any real config requires some java monstrosity. Just a few weeks back a java update broke some buttons on the latest supermicro ipkvm java app and the cisco asdm launcher (though the web launched versions works). I would not call cisco some fly by night company.
No sir I dont like it.
Let's see, the Linux kernel uses the GPL. There must be millions of products with Linux embedded in them.
From my experience those developers are the majority of business java dev's it would seem. Honestly the platform is broken by the fact the super secret only work here bits existed in the first place. Functionally the java apps should know what versions and extensions they require to run and have the launcher use them or go download the required version.
No sir I dont like it.
Here, from GitHub, is the short presentation. This is very impressive. It finds parallelism automatically, at least for simple cases. Over 50x performance improvement on matrix multiply and naive Fourier transform (not FFT), both of which have very simple inner loops. Not clear how it does on less obvious problems.
Yeah I guess I do. I tend to use good software.
Java doesn't have a monopoly on shitty software.
Mod me down, my New Earth Global Warmingist friends!
Would be nice to actually see this great quality java code in the wild.
We have a ton of server-side java *crap*. It is all crap. I have never seen a java server app that did proper logging-- seems all server-side java coders think uncaught exceptions leading to stack traces are "super cool".
On the client side, things like the java app to manage Brocade FC switches will sometimes show 90% of the zones missing! Oh, you kill all java instances and re-run it, and all is cool. Yeah, java is great.
In the early 90s I was a believer, but too many crappy experiences with java-- now, when I hear java, I just assume total piece of shit until proven otherwise (which is _super rare_; being generous-- I can't think of anything great written in java off the top of my head)
I rarely see problems involving new releases of Java... with one specific exception: 64-bit Java. I've seen more than a few apps that die horrible deaths with 64-bit Java... and almost exactly the same number that specifically *require* 64-bit Java when running under 64-bit Windows.
I'm still trying to figure out what, exactly, causes some random Java app to specifically require one or the other when running under Win7/64. I suspect it has something to do with changes Microsoft made to 64-bit Windows that forced (or at least induced) Sun, then Oracle, to change something major with 64-bit Java... but I've never seen any white paper or article that identifies and explores the specific reasons why this might be so. I'm sure the mass layoffs and exodus of Sun's employees right around the time 64-bit Java became relevant, and 64-bit Windows became mainstream, didn't help.
No, *you* get to dictate the licence of your software. It is *you* who chooses to use a GPL library in your code.
The Author of the GPL code did not put a gun to your head and forced you to choose their code.
64 bit java works just fine for me. The only issue I could see is in JNI applications which were only compiled for 32 or 64.
The think that performs like death has been with random bugs in Java7 and OpenJDK (reliably dies on many commonly used programs...)
Bye!
This is simply not true for code written by a professional and competent Java developer (note: part of my consulting gig means I code Java on a professional basis).
If you write only to the public APIs then Java truly is Write-Once-Run-Anywhere (although some bad Java developers use internal functionality that can change between Java versions - I'm guessing that perhaps these folks are used to coding to the Undocumented APIs of Win32 that you used to have to use to get things done). In Java you shouldn't do this. IIRC, Sun created around ten thousand unit tests to ensure Java worked correctly on each platform (wonderful, they did all the porting and port testing effort so Java developers don't have to).
Aside from my professional coding (where Java written on a Mac works flawlessly when deployed to Linux and Windows servers) in my spare time I'm working on modern jet air combat simulator in Java. The same Java+JoGL code works flawlessly on Mac, Linux and Windows. Any differences are in capabilities/performance of individual graphics cards (AMD/ATI vs NVidia).
This article about being able to write Java for the GPU is very interesting, since writing shaders via OpenGL is a little bit of a PITA (there is an impedance mismatch between the conventions of Java, OpenGL and GLSL - it would be fabulous to just write in Java [akin to how I can do this on the Web using Google Web Toolkit]).
So I don't think your statement is really true - except for buggy software written by developers who have bad simple-platform habits.
I would tend to disagree. Why? Because companies like cisco, ibm, etc. all only certify certain versions of java for use in their applications. The cisco apps are cross platform but do NOT play well with different versions of java. I'm not a java expert (I'm a C#/RoR guy) but if fortune 500 companies can't get it right, can you really say that java is cross version compatible?
I would be interested in publishing this under different licenses, such as Apache.
Hello, I am thinking maybe I will use the Apache license...
We have some (too expensive to justify replacing) facilities control modules at work whose 'web interface' consists of a java applet that won't run on anything more recent than J2SE 1.4(early 2002, for those keeping score).
Given the relative costs of replacing the module(the closest thing to a firmware update that the vendor offers) and just maintaining a VM snapshot of a decade-old java setup, we obviously went with the latter.
I have no particular reason to believe that java itself is to blame, rather than merely being the instrument of somebody's apathy and/or incompetence; but there are definitely some special applications floating around.
Considering the approach that Oracle is taking of trying to copyright and charge license fees just for using the Java API's (see Oracle vs Google) I cant see any sane person developing on a non-Oracle provided Java platform. If they can sue Google for Dalvik they can certainly sue whoever deploys Rootbeer if they feel like it.
pgmer6809
With the caveat that you only do things the underlying OS can handle(though this is hardly unique to Java). If you use a garbage OS(read Windows) then what works perfectly on real OSs can often fail(shit like soft links and anything that opens more than a handful of TCP/IP sockets comes to mind). But then again if you are doing server side Windows you probably aren't a good coder to start with....
Monstar L
2020 called and said "they grow it EVERYWERE, man and it's awesome, man." Then it forgot to hang up the phone.
Different how, sparrow bean?
also automagically turn all serial algorithms into massively parallel as well?
Congratulations on inventing C++
Don't quote me on this.
Twelve years into a century that started with a pile of installed 64 bit CPUs and we're still getting this kind of shit happening? Pretty sad isn't it.
Garbage Collection, which kills User Experience due to unpredictable freezing of the whole program
Note that this is a product of a crappy garbage collector in the Java runtime, not intrinsic to garbage collection per se--there are plenty of well-known real time GCs that allow you to set a maximum latency on the collector.
See, for instance:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.4550
http://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Realtime.html
http://portal.acm.org/citation.cfm?id=604155
rage, rage against the dying of the light
- it would be fabulous to just write in Java [akin to how I can do this on the Web using Google Web Toolkit]).
I cannot let any undue praise for GWT go unrebuked. While I find it impressive from a technical point of view, I've come to believe actually using it is a potentially expensive mistake.
What you write for GWT, I wouldn't call Java but a-language-with-a-java-like-syntax-but-totally-different-characteristics. If you use your Java best practices, you'll end up with code that doesn't compile - only a certain subset of the Java api is supported - or worse. Don't assume a particular Locale? Using GWT you better assume the default. Program to interfaces rather than implementations? If you do that with GWT the client ends up downloading 20 megabytes worth of javascript to support every known implementation of every sub interface of java.util.Collection. Choosing GWT is also a way of saying 'who needs a steenkin frontend specialist?'. Since all that frontend stuff is generated from java-like server code, your UI will end up being coded by your server side java people. Finally, I'm not convinced Google will continue to support it, since they are actively working on a number of other javascript avoidance technologies, and have a history of announcing the end of life of a product they lose interest in with only a few days notice.
Shouldn't title mention "nVidia GPU" or did I miss that AMD now supports CUDA on top of OpenCL?
a skill programmer would know that Java has evolved and that the language has many features that it didn't have in v1.0
A few new features have been added to the java language over the yers but many features that have been in other languages for years are still missing. For example
properties*
method pointers**
user defined value types
parameter pass by reference
operator overloading
* Specifically i'm reffering to the language feature that VB and Delphi have, not the conventions that Java has to make up for the lack of that language feature.
** You can achive a somewhat similar effect with interfaces and inner classes but it''s a lot messier.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
"They" do not "dictate" anything : see ThePeices's comment before about the gun, it's your choice.
The author of GPL'd code gets to say how HIS(/her) code is used. Because they own their code. Like everybody else.
This is the same basic logic as Microsoft, IBM, Oracle or whatever you wish : will you contact MS and ask them to license their source code in whatever-license-suits-you-so-you-are-happy ?
But the GPL garantees to not leave you in the mud, because everybody should pass along the same rights to each other. You can even make a buck (or a billion, ask RedHat) in the process.
Either you agree with a licence (whichever) and you use the software according to it,
or you buy a commercial version of "Free Software" off the author (Dual licensing exists)
or you buy commercial software (many providers exist)
or you write your own code (what I do).
Pick one, no need to bitch^Wwhine.
This is a strange argument logically...
Are you saying all these major corps are idiots for choosing Java in the first place? That doesn't lend much credibility to your use of them as an example of producing well written software. Certainly these major corporations didn't just randomly choose to use Java.. so how does your logic work exactly?
-Lod
They don't "own your code" in any sense. If you violate the license, you're committing copyright infringement, but it has no effect on the copyright status of your own work.
Good old C did manage to dethrone Java as the programming language with the most "skilled engineers world-wide" recently, but Java is still #2.
If the 2nd most popular language is indeed in "extremely short stock of skill", please let me take this opportunity to let everyone know that I can provide skilled Java work at reasonable rates (well... reasonable considering it's scarcity).
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
-Lod
No, everybody owns your code, including you. GPL makes the code free (as in freedom), BSD makes the developer who uses the code free. It depends where your priorities are. If *you* are making a big project like this open source, surely you don't want tons of people leeching off of your work? Surely you want to see what probable uses are?
Also, just because RootBeer is GPL doesn't mean *your* code has to be GPL, only the changes you make to RootBeer have to be GPL. Just like if you compiled something with GCC it doesn't mean you need to GPL your code.
Help I am stuck in a signature factory!
GCC is GPL too, yet many commercial products use it.
You usually only need to use a compiler for development, licenses like GPL only need to apply once you ship it.
I've had very few problems, most applications continue to run just fine as you upgrade java...
Many of them don't officially "support" newer versions, and will often try to insist you must run an ancient (and full of security holes) version of java...
The few java apps i had problems with weren't incompatible with the modern jre per se, they just included explicit checks and would complain if they detected a version they didn't recognise, but if you manually hacked out the checks the apps usually ran anyway.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Alternatively, there is the Classpath exception that could be added to the relevant modules.
https://en.wikipedia.org/wiki/Classpath_exception
You never know what is enough unless you know what is more than enough. - Blake
yeah, you can even automate it..
now, I wonder if this gpu project could be used to run http://www.ode4j.org/ ..(ode for java is a port of a c/c++ physics lib to java, mostly automated conversion. it actually works pretty nicely.)
world was created 5 seconds before this post as it is.
In many cases Java developers have turned to other languages such as Scala, Groovy and Clojure for more advanced features. It is still somewhat ironic that you cite rapidly declining dinosaurs such as VB and Delphi in an argument against Java.
> With the caveat that you only do things the underlying OS can handle(though this is hardly unique to Java).
Huh? sorry, I'm missing the point here. Hard to do stuff your O/S doesn't as an application programmer. However, if you meant to say that Java only has a common subset of functionality across platforms, then that is a fair comment. I find that the functionality is good enough to make great programs.
> But then again if you are doing server side Windows you probably aren't a good coder to start with....
\ Most Java coders don't get to choose their customer's infrastructure. You are right in that a good Java coder knows how to develop for more than just one platform.
This is no different to the ActiveX controls that are floating around (eg. some banking access programs), or all the Internet Explorer 6 sites around. It has always been possible to write stuff so it is not to tied to a particular setup, or at least to limit the platform specific bits. It is surprising that an applet can't be rewritten - they're usually not that complex (and getting unit test coverage during maintenance would go quite far).
> I'm not a java expert (I'm a C#/RoR guy) but if fortune 500 companies can't get it right, can you really say that java is cross version compatible?
Is that your argument? Just because corporate developers (including a lot of C# guys, but there are always exceptions) are often morons doesn't mean Java blows - these guys can and do butcher any technology when they build stuff (hell, even after giving one guy proper code for calculating any date he come back with his shitty VB.NET that was an abomination and had so many holes).
I've written a *lot* of different systems in Java. From embedded, web, graphical, network, rich client etc and the version gotchas (there are minor things you learn to avoid) are nothing in Java compared to the C, C++ and C# systems I used to work on. Hence, my statements.
But has Netcraft confirmed it?
The Tao of math: The numbers you can count are not the real numbers.
Bro, you simply have a bias against Java and this means you are not reasoning fully. Admit this to yourself. People can (with some effort) write cross-platform C and C++ apps, yet people often write apps that fall over with new service packs to their operating system. Yet you choose to blame a particular technology rather than accept that , "You can write bad FORTRAN in any language".
"Used intelligently by a skilled programmer, Java can deliver great results"
Used intelligently by a skilled programmer, Fortran, Cobal and Z-80 can deliver great results.
Problem is missing ingredients. The first two.
Would be nice to actually see this great quality java code in the wild.
We have a ton of server-side java *crap*. It is all crap. I have never seen a java server app that did proper logging-- seems all server-side java coders think uncaught exceptions leading to stack traces are "super cool".
On the client side, things like the java app to manage Brocade FC switches will sometimes show 90% of the zones missing! Oh, you kill all java instances and re-run it, and all is cool. Yeah, java is great.
In the early 90s I was a believer, but too many crappy experiences with java-- now, when I hear java, I just assume total piece of shit until proven otherwise (which is _super rare_; being generous-- I can't think of anything great written in java off the top of my head)
There's no point in singling out Java for any of that. As long as the order of the day is cheaper software produced faster instead of spending time and money to get quality, software is going to be garbage.
I do know some really excellent java apps, and a very large quantity of excellent open-source java support libraries, but the finest tools in the hands of 15-rupee/hour junior programmers working to a fantasy schedule aren't going to produce them.
I provide a lot of advice to Java programmers, and one of the top items I warn them to do is use logging. My own stuff not only logs extensively, it even sends me email for the really dire stuff. As far as letting exceptions fall out on the floor goes, that's a mortal sin in my book.
Of course, because I DO have quality standards, I just get yelled at for not being "productive" enough.
> I'm not a java expert (I'm a C#/RoR guy) but if fortune 500 companies can't get it right, can you really say that java is cross version compatible?
Is that your argument? Just because corporate developers (including a lot of C# guys, but there are always exceptions) are often morons doesn't mean Java blows - these guys can and do butcher any technology when they build stuff (hell, even after giving one guy proper code for calculating any date he come back with his shitty VB.NET that was an abomination and had so many holes).
I've written a *lot* of different systems in Java. From embedded, web, graphical, network, rich client etc and the version gotchas (there are minor things you learn to avoid) are nothing in Java compared to the C, C++ and C# systems I used to work on. Hence, my statements.
Java is pretty much unique in its inherent support for cross-version support. There's a special deprecation annotation you can attach to any function or class that causes warnings if you attempt to use downgraded features. You won't find that in C/C++ or VB. In fact, one reason I bailed from Microsoft was that not only was I routinely getting nailed on MS apps to the degree that in extreme cases, I was looking at re-installing an old OS so I could install an old IDE so I could use an old compiler to make a 2-line emergency change, MS would routinely replace an entire API with a totally incompatible one. I got nailed hard on this with SOAP, but the Database API-of-the-day way outright comical - they wouldn't even have the kinks out of the previous one before the next one came along.
With Java's deprecation, you can make your panic fixes, note the deprecation warnings, and make proper version-related updates when things are less stressful (yeah, like that ever happens). The actual Sun-supplied deprecations tend to live forever, so even some items deprecated from Java Version 1 can still be used/abused today. They are a bit weak on the clairvoyance features, however, so forward version dependencies are a bit hit and miss.
The primary reason that major vendors are so picky about JVM brands and versions is that they want to keep their support costs down and even in a strict version-supportive environment like Java, the smaller the number of permutations, the better. Even when the language itself is supportive, the bugs vary from release to release, and yes, some "clever" application programmers do code to internal implementation details or mis-read specs.
Android has had NDK for at least as long as I've been using Android. It's Xbox Live Indie Games and Windows Phone 7 that aren't allowed to use native code.
It is surprising that an applet can't be rewritten
Well technically it can. Business-wise it'd cost money, and the manufacturer would rather sell you new hardware containing the rewrite.
How should a Java application read the joystick, camera, and microphone attached to a computer? For example, this joystick driver is described as "Works on Windows and Linux" and presumably not Mac OS X.
In before someone suggests a workaround of using your netbook to connect to a more powerful computer using X11 or RDP or VNC, in much the same way that iPad apologists claim to be able to use their iPads for software development through remote access. But then I've had to work around it a different way because I'm often using my netbook on the bus, which does not provide Wi-Fi to passengers, and I don't have the money to "Share Everything" as Verizon Wireless has been calling it.
Oracle lost that battle on all claims.
They can lose, but that doesn't mean they can't appeal and use up more of the opponent's legal funds.
If this "NOTE!" is proved necessary, Oracle could claim copyright infringement against anyone who bundles a modified OpenJDK with GPL-incompatible applications.
Google was sued because they took the Java APIs and have not got a license from Oracle (that was before Java was released under the GPL with OpenJDK). [...] Since Java is now at least 6 years under the GPL there are no issues anymore.
I don't remember being able to buy an HTC Dream, the first Android phone, in 2006.
We now all know the result of that venture, the SSO of APIs is not copyrightable
How is the structure, sequence, and organization of APIs not copyrightable, while the structure, sequence, and organization of a video game is?
few people care about ATI cards for anything else than video games
Aren't AMD cards better than NVIDIA for the calculations used in Bitcoin verification?
So why hasn't Oracle improved the garbage collection behavior of Java Standard Edition based on the proofs of concept presented in those articles? Or if it has, why does there remain a perception that Java's garbage collection performs poorly?
Presumably that bad teacher was once a student. A bad student - after all she wasn't very good at studying how to be a teacher, was she? Perhaps that was because her teacher of teaching was bad. Rinse & repeat.
So who's to blame? Jesus? Buddha? Aristotle?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
FTFY
A marriage is always made up of two people who are prepared to swear that only the other one snores.
You must have checked a long time ago...or trying to use a program compiled for a new version of Java in an older runtime.
"I think this line is mostly filler"
I don't have any control over the developers and project managers at Cisco, or a SuperMicro, or wherever. Fact is - they wrote "java" and it breaks. Somebody dropped the ball along the way, and it's not just them.
I would have to say that they dropped the ball if they don't correct or update their products to support newer versions of Java or eliminate the need for an applet for manage an appliance (we are not in 2000 anymore).
"I think this line is mostly filler"
We had an incident a couple of years ago were all our apps (four jboss instances) started running in java 6 32-bits instead of the java 5 64-bits they were always tested and run because of an error on the data center provider who maintained the operating system installed and changed the system default version of java.
We didn't even notice the change except that a third-party native shared object (a dll in linux) started to fail, because it was compiled in C for 64-bits.
Modern Java reasonably written has wonderful compatibility and portability.
"I think this line is mostly filler"
They have. The multithreaded garbadge collecter which is available in java 7 really only pause programs for a very very short time because it does most of the garbadge collection in the background. (Also a very good use of modern multi core cpus).
Nothing which the require the developer to write in php can be called progress.
And while the ability to run LibreOffice and modify the code while the program is running would be really cool, the available tools are still far from able to do that.
There are funny enough java tools which are working in that direction. And the best are able recompile parts of a running program, and then let the program use the new code without stopping it.
Will it make Minecraft look better?
Or run better/faster?
I can't believe you cited Total Recall as a reliable source of science. I just. Wow. I'm flabbergasted.
Hmm, my bad.
Don't quote me on this.
"If you write only to the public APIs then Java truly is Write-Once-Run-Anywhere"
That's FUNNY. I've found a bug in a java program that failed because the vendors's version string was malformed.
Start up a bunch of threads and your Java program is NOT going to behave the same on every platform. Differences in OS schedulers means that a program that runs right EVERY TIME on one platform will fail EVERY TIME on another platform.
Start up threads, and all cross-platform compatibility goes out the window.
Different java implementations have WILDLY different dynamic performance characteristics.
Face it, for any real program it's "write once test everywhere"
Tell me with CONFIDENCE that your "cross-platform" java code is gonna run without failure on OpenVMS's java implementation.
Hard to do stuff your O/S doesn't as an application programmer.
It's EASY to do stuff that won't work the same on every OS.
Your fancy multithreaded java program, that works right every time on Linux, will FAIL on Solaris or OpenVMS because of their different thread execution models. You THOUGHT there were no race conditions in your code, but you couldn't test them, so you had no idea.
It's not all that bad these days.
Garbage collection will only pause for user noticeable times when running huge memory sets (think gigabytes). Some care must be taken not to overdo the creation of garbage -- ie, throwing away a full frame of HD video as garbage at 24fps can create 100's of MB's of garbage per second. Even under those loads it is possible with some tuning to get a smooth experience though.
Objects these days can be allocated on the stack if the compiler determines it doesn't escape the method it was created in (escape analysis).
As to your other points, I don't see any of them as down-sides, they are minor issues at best in properly written Java software. We're more worried about design and long term maintainability and compatibility.
You must be doing it wrong. WORA is working perfectly for me and everyone I've met in the field at the various companies I've worked for in the past 15 years. Usually it is written and tested on Windows boxes, and deployed on Linux, already at my most recent job it is developed on Linux and deployed on Solaris.
I'm not confused about anything.
You fucking retards on slashdot are also part of why the GPL is not useful.
Mod me down, my New Earth Global Warmingist friends!
You don't compile your software against the kernel, you fuck up.
The kernel just facilitates running your software on the CPU.
God fucking hates slashtards.
Mod me down, my New Earth Global Warmingist friends!
GCC is GPL too, yet many commercial products use it.
The little library GCC uses for builtin functions etc. is not under the GPL.
Finally! A year of moderation! Ready for 2019?
Dump x264 as badly designed and use a new video compression design that can take advantage of the parallelism.
now we need to go OSS in diesel cars
Yeah, it must be hard being a genius among idiots. My heart goes out to you!
> Start up a bunch of threads and your Java program is NOT going to behave the same on every platform.
This is because a threaded application is non-deterministic. This is true for C and C++ programs as much as for Java programs. So I don't quite get what your point is.
> That's FUNNY. I've found a bug in a java program that failed because the vendors's version string was malformed.
Please elaborate as I'm curious about this. Note that I didn't say Java was bug-free (no non-trivial piece of software is, and the Java platform is far from trivial). Also, why would you rely on a vendor version string in the first place? sounds a little dodgy to rely on informational strings that are not actually part of the API. Furthermore, you found a bug in Java, big deal. Try and find a development platform that doesn't have at least some bugs in it (and the one you found is pretty trivial).
> You THOUGHT there were no race conditions in your code, but you couldn't test them, so you had no idea.
Actually, it's not that hard to write unit tests for race conditions (and the synchronization that prevents them). The tests may take some time to run, but that does not mean it is impossible. I'm wondering why you had no idea about this?
> It's EASY to do stuff that won't work the same on every OS.
I suggest you go back and re-read the comment you quoted. What the original poster said was that
So far your comments are akin to the old joke, "Doctor! doctor! it hurts when I touch my eye! so don't touch your eye.". Not every style of writing Java will produce the same results on all platforms. This should be a surprise to no-one experienced in the field. However, with proper testing it is entirely possible to write Java programs that will execute the same way on different platforms. I manage to do this, so I'm struggling to see what your argument is, apart from some alarmism (of someone with a different pet language? something you think is a better multi-domain cross-platform solution than Java?).
Are you talking about real cases?
"I think this line is mostly filler"
If only idiots and kids write bad java code as you say and java code from large corps is nearly universally bad as has been my experience then union of those two statements would be that large corps seems to only employ idiots and kids to write there managements apps. The truly bad part is for some of the apps I can see no reason for the java app vs a well written web app.
No sir I dont like it.
Properties .... really??
Java DOES NOT have properties at the language level meaning that code using objects inevitablly ends up get/set infested making lines of code unnecessarily long and obscure. If you have ever programmed in a language that has proper support for them it's painful to switch to a language that doesn't.
I guess you never programmed in Java.
I have programmed in java usually because of libraries I wanted to use and wide support but I find it a horribly constricting language to work in.
Method pointers ..... I guess you have no clue of how object oriented programing works.
Method pointers are by far the neatest soloution to event handling i've come across though admittedly inner classes aren't worlds away from method pointers just uglier (much like the getters and setters java coders use to make up for the lack of properties).
user defined types ..... what the hell do you think classes are?
I said value types. Java classes always have an implicit pointer.
So if I want a big array of my custom data type I either have to seperately allocate every element creating a load of unnessacery work for the memory manager and an unnessacery pointer lookup on every access or use paralell arrays of primitives (which is what those who want high performance and are stuck with java do but it's a pretty twisted way to code).
parameter pass by reference .... are you really this dumb??? How the hell do you think Java passes data??
Java parameters are always passed by value. This along with the lack of user value types means that all your options for returning more than a single numeric value from a function suck.
You can create an object and return it. Unless the VM is doing REALLY clever optimisation* this means that for every invocation of the function an object will be created and most likely thrown away.
You can fill in values in an object provided by the parent (while the parameter itself is passed by value the implicit pointer mentioned about comes into play so the function can change the objects fields even though it can't change what object the caller is referring to). This isn't as bad as the first option but depending on how often the parent function is called it can still create loads of unneeded garbage.
You can use static variables or fields in the object the function belogs to (if it's an instance function) etc (YUCK).
operator overloading .... HINT: Java is not C.
Afaict Java is basically the subset of C++ that sun thought crappy programmers could come with and that they could successfully sandbox (with the technology of the early 1990s) with garbage collection (which was needed because manual memory management is hard to sandbox and hard for crappy programmers to cope with) added on.
you don't even have the ability to self educate yourself.
You sound like someone who completely lacks the experience to compare and contrast different programming languages.
* I firmly belive that if you have to implement escape analysis to make up for the lack of reference parameters your language is fundamentally broken.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Nope brandy spanking new java apps with a latest and greatest auto downloaded java 7 something. Just a few weeks back got one of those fun update java and went from a working app that's is only a few months old to a non working app also took out a several years old app with the same update.
This is especially fun when the java app runs out of firmware with no other method of configuring the device and the device maker has no plants to fix it. Keeping that odd vm around with some specific version of java just to be able to configure a device is so much fun. Honestly it's getting as bad as having to keep some old version of IE installed to get some web app to work.
No sir I dont like it.
> Face it, for any real program it's "write once test everywhere"
Yes. This is why we write unit, integration and system tests as part of development (this is an accepted part of Java development these days). Fortunately once you have these tests the testing of any new platforms and any code enhancements is effortless. You do Test Driven Development (TDD) don't you?
> Tell me with CONFIDENCE that your "cross-platform" java code is gonna run without failure on OpenVMS's java implementation.
You sound like you require Java to work without a developer ever having to their test suite against the target platform. Incidentally, what Java Runtime Environment implementation are you using on OpenVMS?
Amen to your post. As another developer I certainly respect your skill and commitment to quality. Most developers (no matter what language) don't plan on giving themselves informative messages (eg. what was the failed value, what was expected/the range of valid values, what other related values are there).
FYI the current year is 2012. The 90's were quite some time ago. If you are a windows user consider the change in quality/reliability/functionality from Windows 95 to Windows 7 today. The same is true of Java (and Linux, and Mac, ....). Your data point is rather old and rather out of date for this particular issue.
> We have a ton of server-side java *crap*. It is all crap. I have never seen a java server app that did proper logging-- seems all server-side java coders think uncaught exceptions leading to stack traces are "super cool".
Exception stack traces are usually very handy in diagnosing rare faults. Java's 'chained' exceptions are *exceptional* in helping (terrible pun intended). Stack traces have their place. The problem is with the coders for the software you are having to maintain. I certainly write very informative exception messages at the point of failure (fail fast, and collect up all the information you can before you throw). Quite often I'm also able to include a message on what went wrong and what should be done to fix it (eg. if there is an issue that I can't handle as a programmer, such as environmental resource exhaustion cases like network-down, or out-of-disk; in addition to the usual bad input validation).
The problem is not that the coders leave exceptions. The problem is that they are not thinking of what could go wrong at each step of processing and either failing fast (reporting before getting into an inconsistent state, and remaining in a safe state ready to process the next request) and what outside the system can screw things up (environmental problems). If you think this is unique to Java programmers then I hope you get to look after big server-side C++ systems some day where you get a core dump with no symbols. Joy.
> On the client side, things like the java app to manage Brocade FC switches will sometimes show 90% of the zones missing! Oh, you kill all java instances and re-run it, and all is cool. Yeah, java is great.
I think what you mean to say is that Brocade are useless with this app (that is, despite your frustration please get some perspective). Don't blame Java just because it is accessible enough that morons can use it. (I've done a lot of hardware interfacing in the past and I have to say that letting hardware guys write code is nearly always a disaster - at least as much as letting a software guy like me build hardware systems [it works, but it is not elegant like an experience hardware guy would do]).
The problem (for me) is that none of those languages allow the creation of modern applications that work on all modern platforms.
That, and that finding a job doing any of them would be a real pita.
-Lod
Interesting how in the 80's the CPU was doing most of the graphical heavy lifting, it then moved to the GPU in the 90's, and now the kernel is moving there too... When will we see a booter straight to the GPU ? I think some projects are already thinking about it.
Start up threads, and all cross-platform compatibility goes out the window.
Different java implementations have WILDLY different dynamic performance characteristics.
Face it, for any real program it's "write once test everywhere"
Tell me with CONFIDENCE that your "cross-platform" java code is gonna run without failure on OpenVMS's java implementation.
OK. I'm confident. Subject only to the constraint that the OpenVMS JVM is Sun-compliant. I speak from long experience.
ANY multi-threaded environment is subject to synchronicity issues, and it's considered an axiom that multi-threaded code is 10x harder to work with than single-threaded code (and that interrupt service code is 10x harder than that).
You don't have to move to a different platform to get screwed by multi-threading, just change CPU speeds. Or peripheral speeds. Or system loads.
IF a multi-threaded application is properly designed and implemented, it should run on any compliant JVM. How well it runs will depend on how good a match the multi-threaded design is for the target environment. That's a whole different matter. Presumably one is multi-threading to obtain performance advantages inherent in parallel processing over the single-threaded model, so if there's a mismatch between the thread expectations and the target machine enviroment, that advantage may be neutralized. That's an architectural fault, however, not a language fault. It would work just as miserably in any language.
I have used quite a few languages which use GC and even though some are quite mature now, like VW Smalltalk, all of them freeze on a regular basis, just when you don't want it to happen. I have also used and developed large-scale systems which do not have this trait, and all of them were done in C or C++ and they use explicit allocation or reference-counted memory management.
1. VW Smalltalk uses a full (non-generational) tracing collector which makes no pretenses of being low-latency, let alone realtime.
2. Refcounting is a kind of GC, not something different; mark-sweep is the other most common algorithm, but it's a mistake to refer to any one method as "garbage collection" at the expense of others.
3. If you want to look at real-word implementations, Lua and squeak are probably the two most prevalent systems that use realtime GC (squeak is only mostly there--doing weird things in destructors can make it not real-time). OCaml is 2nd-generation incremental, which is not realtime but is low-latency in the common case.
Lua added incremental GC as of version 5.1 mainly because it's seeking to be used as an extension language in games which have pretty rigorous soft realtime requirements.
IBM's Metronome (AKA Websphere Realtime) is a realtime JVM that's seen a fair amount of use in the real world. It uses a newer algorithm by Bacon (who's mentioned above) that's completely hard realtime and fits the constraints of the JVM. http://researcher.watson.ibm.com/researcher/view_project.php?id=174
rage, rage against the dying of the light
Where is the drone flown by a LISP control law program ??
Oh, yeah, and it's not a drone but there were certainly a number of military robots developed by IS Robotics and others using realtime Lisp variants in the 1990s. e.g.:
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA399584
rage, rage against the dying of the light
So why hasn't Oracle improved the garbage collection behavior of Java Standard Edition based on the proofs of concept presented in those articles? Or if it has, why does there remain a perception that Java's garbage collection performs poorly?
Who knows, that's hardly the only major issue with Java.
If I were inclined to put a reason on it other than laziness or ignorance: Possibly they've focused primarily on throughput at the expense of latency, believing that's a better bang for their buck for wherever they're making money selling/supporting Java? Which is plausible, if desktop Java is paying out more support to 3rd party tools and toolkits (money not going to Oracle), while server-side Java helps fuel more JVM support contracts and Oracle DB sales?
If so it seems a short-sighted policy.
rage, rage against the dying of the light
C and C++ doesn't have "write once, debug everywhere" emblazoned all over its marketing.
There's a difference between not claiming something, or claiming it and then not providing it.
In the second case, people make assumptions (like shipping stuff that's supposed to have a long shelf life and work cross platform in your langauge), because they bought into the hype.
That's what I object to. Stuff written in Java which doesn't work everywhere.
Still, the vendors of things which require badly written java to work have plenty of blame to share too.
Probably quite true, but I still don't have any control over that unless I'm a very big customer. But they require java because someone, somewhere, believed the glossy brochure which said that Java would solve all their problems and make them coffee while I did so.
> Still, the vendors of things which require badly written java to work have plenty of blame to share too. :)).
Require? don't you mean vendors implement and distribute things in badly written Java. How is this in any way different to crappy apps written in any other language? Have you never seen a well-written and robust multi-platform Java app? they do exist (hint: I produce them
Ah, it seems a common case. Some brands of device and networks appliances seem to have used Java applets for management in the first half of 2000 (or programmed like they were stuck at that age) and then didn't keep with technology advances. Somewhat more modern Java versions let the programmer specify the Java version in the applet tag allowing each applet use different java versions.
I wonder if it is possible to use some browser plugin like monkeygrease (for firefox) to change the applet tag dinamically allowing the use of this method in your case?
"I think this line is mostly filler"