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.
Not posted using Java because it's too slow to get First Post
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!
Except after you get pestered every hour to update your Java runtime, you actually do update it and it breaks compatibility with all existing apps. Other than that, yea WORA is great stuff.
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!
Unfortunately, people don't work for free.
Or if they do, you can't exploit it.
Damn communists, they don't respect other's greed.
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.
Agreed, he should have licensed it under the MSPL.
Rootbeer appears to have some kind of runtime component that you need to use with your generated code.
I don't see an exception regarding that, so you'd need to GPL your code to comply with the license.
Mod me down, my New Earth Global Warmingist friends!
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
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.
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.
So last you checked was 2001?
This hasn't been the case for quite some time, it's pretty easy for any competent programmer to write code that runs on any runtime environment from Java 5 and up. Any mediocre programmer can support Java 6 and up run times without trying.
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)
Just like any other programming language?
Um, essentially yes. Java is just like every other language which was the point of the comment. Read the contrarian comment it was in reply to for refreshment on what the GP was arguing against. You and whoever modded you "underrated" need to keep up.
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.
So can I suggest you just not update Java on your machines until you're sure your applications are compatible? That seems like a good idea to me. You can also just keep multiple versions on the machines and start the application with a fully qualified path name to the particular java you want.
2012 called and would like to know where to get some ganj
Honestly the platform is broken by the fact the super secret only work here bits existed in the first place.
No, it used to be broken. You don't have to use those APIs anymore so now it's the developers and project managers at Cisco working on the application that are broken. Got it?
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.
2004, try 2000. Java is well known to be deficient in modern language features and has stagnated to the point where it doesn't look like it will ever catch up. Even good old C++ has been updated recently. Not all languages need to have all features but I never find anything in Java to make up for everything it misses.
A skill programmer is smart enough to avoid Java if possible. So while it might need a skilled programmer to get good results from it, we will never know since they are all using something that doesn't suck.
It was either Java 6u10 or 6u14 that changed their wsimport tool, which made breaking changes.
Going between a major release I can accept breaking changes with enough notice, but breaking changes to a common compilation tool in a random update is ridiculous. It wasn't too terrible to fix the issue, but it is not an issue that most developers will know how to fix without breaking things elsewhere, without figuring out a tool that should have just worked.
Beyond that, I have seen very few issues with Java compilation/being cross platform, and I say that as someone that regularly writes web applications along with my full time job programming against a 3D application written completely in Java.
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.
Because people are incapable of learning without the government, right?
There will always be good programmers, regardless of what the government institutions churn out.
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?
Will it make Minecraft look better?
Java does indeed provide some benefits, such as memory safety. Unfortunately this comes at the cost of
-Garbage Collection, which kills User Experience due to unpredictable freezing of the whole program
-no way to allocate more than just primitive variables on the stack. That eliminates the fastest allocation method of all.
-being forced to use Arrays Of Pointers, when an array of objects would be perfectly sufficient
-being forced to use a pointer when object agggregation would be perfectly sufficient
-being forced to use the GC even if an object tree is in no way cyclic
-not having Destructors
I've create a programming language called Sappeur which has the same memory safety assurances as Java, but does not have all the downsides as listed above. It is still a bit rough around the edges, but it clearly works and demonstrates that the Java inefficiency is not a god-given thing. Sappeur programs start up as fast as any C or C++ program and terminate equally fast. They are nearly as efficient as C++ programs, which means they are much superior to anything you can do in Java or C#
Here it is:
http://sourceforge.net/projects/sappeurcompiler/
Unfortunately I do not use Nvidia GPU
I would be interested in publishing this under different licenses, such as Apache.
Because a skill programmer would know that Java has evolved and that the language has many features that it didn't have in v1.0
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.
Shit Cisco wont support anything outside of IE 7. Talk about some innovative and modern tech company.
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
At least that's what all those Node.js people keep saying.
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?
Hi,
Right but if you make the deal, they own your code.
Not exactly freedom.
Please check your sources : the GPL does not claim ownership of code written by others.
No license can legally do that in the current international copyright framework.
Now, you have the freedom to believe all the FUD^Wmisleading affirmations that you want. Just make sure to be informed and to read the texts to clear any misconceptions or prejudices.
Back to my JS madness now.
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.
- 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?
Except that it lowers the bar so much that shitty programmers ended up using it.
People who call out Shitty programmers are usually Shittier programmers. Just sayin...shitty.
Good suggestion. Everyone, stop updating your Java!
- MalwareAuthor
"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!
right... you do know that just saying things doesn't actually make them true, right?
you have fun with those other languages that fulfill whatever it is you think Java is lacking..
i'll be using whatever companies pay the most for.
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 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 can think of a few programming languages which are certainly "not cross" platform, or only have "cross platform capabilities" due to some half-assed hack that is likely to be undermined by the people that are responsible for the language at any moment, so no, you drooling muppet, not like "any" other programming language.
Are you confused about the difference between GPL and LGPL? Chances are, so was the author of the software. If you believe code should have been released under LGPL instead of GPL, contact the author of the software. Chances are they were confused and are more than willing to adjust the license to LGPL where fit. People typically release software under GPL to make it EASIER for others to use it and contribute to it, rather than to inhibit 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!
Maybe I have a strange sense of humor, but this would have been so much better without that 2012 post in between.
Awesome. Now this is useful because ...?
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
if oracle wants a java compiler let them write it, stop being a corporate toady.
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.
> 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.
Given Java's current direction (Oracle) and all of the hell we (the IT industry) have been put through already with Java's false promises of WORA, shouldn't most of our efforts be towards abandoning Java entirely. Frankly, code translators, like Facebook's PHP to C translator seem like better investments in code performance and portability (I am aware portability is not their goal, but it is an interesting side effect).
Get the industry to rally behind a consistent language which has strong RAD functionality (Python?) and find better ways to translate and optimize the slow chunks of code during interactive compilation and profiling. IDEs and compilers need to move the direction of content creation tools like Dreamweaver, where the developer can see the results interactively and instantly on a variety of platforms via virtualization. How great would it be if following a multi-platform compilation run, a LibreOffice developer could see and interact with the results on Ubuntu, Windows, OSX, and Android all at the same time?
Running crap code on more interesting platforms does not fix the problems already there.
Does this mean the malware can now run on the GPU and evade detection by a virus scanner?
Will we need a new virus scanner for the GPU?
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.
All I can say, is that Cisco must have spent a lot of money, and many man hours to find a way to abuse Java to the degree you describe. Real people who don't deliberately set out to undermine the system don't even have to think about it to create portable code. It Just Works.
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?
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.
Only academics claim that refcounting is inferior; engineers have built lots of systems based on that technique and they work extremely well.
Thanks for the references; I will look into them, but I am still highly in doubt about "realtime GC" and I have never heard of anything actually realt-time critical being done in a GC language. Where is the drone flown by a LISP control law program ??
Just a heads up that you over use parentheses. Your second sentence is shorter than the content in parentheses, and people tend to skip/skim over parentheses. Every sentence seems to have a parenthetical reference to something. Make new sentences instead of using large swaths of parenthetical text.
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.
Regardless of whether you personally find Java's performance to be acceptable, it's proprietary. I prefer not to use proprietary development languages and tools.
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"
Well, "Used intelligently by a skilled programmer, ", C or C++ "can deliver great results....."
So AMD hardware aren't GPUs then? Where's the OpenCL support? Well?
That's not exactly the case. At any time, you could stop using the GPL library and take your code private again as you are the copyright holder. You also need to distribute your code on request. Most people put it up on a webserver to make it easier, but the GPL doesn't actually require that. The number of people who see the code can be somewhat controlled in this fashion if you choose.
Having said that, it's not really the spirit of the GPL. The point is to show how "stupid" copyright law is and that we shouldn't have it at all. The utopia for RMS is not to need the GPL once everyone has been properly trained to think his way.
You trolled so much I actually defended the GPL. Bastard.
"Getting a say" and "owning" are quite different. Also, they don't get a say: you decide to release your under a compatible license if you use their code. What is so hard about 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.
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!
Properties .... really?? I guess you never programmed in Java. ..... I guess you have no clue of how object oriented programing works. ..... what the hell do you think classes are? .... are you really this dumb??? How the hell do you think Java passes data?? .... HINT: Java is not C.
Method pointers
user defined types
parameter pass by reference
operator overloading
In conclusion, you are beyond ignorant and really hope you never work on anything computer related ... because you don't even have the ability to self educate yourself.
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?
That's what is relevant when you play a shooter game and somebody aims at you; can then the "seldom" GC event kick in ?
Just look at this
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java
and please don't tell me memory is cheap. There will always be applications which max out RAM and you cannot simply "solve" that problem by buying more. There are always some hard limits on what you can plug into a certain class of computer. Don't assume everybody is in the transaction processing business writing business logic;some people are actually developing database engines, data mining engines, signal processors, CAD systems, realistic 3D games, simulators, image processors, movie rendering engines and the like.
That is a freeware delphi clone and it displays almost all of delphi's advantages plus it is multi-platform. So extremely quick compilation, nice IDE, nice GUI library, proper type system and efficient runtime behaviour. I don't think python has all that.
So you can create portable GUI programs which are also highly efficient. Just don't use platform-specific stuff such as Windows-only system calls. Also, that approach can be also applied to many other fields such as Sound, networking, database access, printing and so on. Just don't blindly take some vendor's lock-in API. Research what exists and leverage that.
The submitter is new here and the mods didn't RTFA and therefor failed to catch this.
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!
of course it does not at all make sense to generate String objects in every iteration of a frequently used loop. Re-use a StringBuffer on every iteration in that case. Re-using frequently used objects is probably a good idea. But that does indeed lead you into making your own memory managers, as it is not obvious when you will have to release an object pool. Still, it is almost inevitable to create garbage and even if you do it at a very low rate, at one point the GC will kick in and according to Murphy that will be 30 minutes into a critical presentation to your customer.
With Android phones, I suspect it kicks in every minute or so and it does indeed damage User Experience.
> 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?).
It would also be possible to license most of the "compiler" part (e.g. the static bytecode analysis/translation parts) under the GPL, but any parts used in the "runtime" (e.g. classes linked from user code) could be licenses BSD/MIT/Apache.
That way the innovative part of the project (cross-compiling Java to CUDA) remains as a common good always protected under the GPL, but does not limit how projects are allowed to license their own cross-compiled code.
This still limits licensing options for people embedding your compiler within their java application, though... but that seems like a limited use-case, since it would only really be worthwhile for applications that themselves dynamically generate java bytecode (which is a pretty small subset, in my experience).
Are you talking about real cases?
"I think this line is mostly filler"
How exactly is a GPLed language proprietary?
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.
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.
The really really good programmers I know would prefer to work with PHP and Javascript than write Java apps for blue chip companies.At least writing good code in PHP and Javascript is a rightful challenge and the people you end up working with are nicer.
Well and development costs. The more versions they specify their apps work with the move development environments they need to support internally. And they have to do regression tests on all of them. And this is likely something that scales proportional to n factorial, so you quickly reach the point where there are not enough resources to track the specification as it evolves over time. Every change in the spec consumes programmer resources, the more targets you support the higher the cost.
This is true to an extent with compiled code using libraries. The difference is the costs as versions change are spread over the entire body of users and are done once in one place by the people maintaining the OS, compilers, and libraries, instead of for every application written.
> 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
Well, just like you are NOT forced to use the GPL, or any license, :-) :-)
nobody forces you to read, and even post on this site.
Enjoy your God-sent freedom and stop wasting your time
You will see, it's just a matter of choice (and sticking to it).
Have fun with your life
(captcha: "conflict" hahaha)
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.
Concidering how much CPU Minecraft takes up, tranfering the load to the GPU will be a blessing
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"
Numbers != good code.
Might want to look over the code of a few of your favorite projects (that you haven't worked on.) Let me tell you about poorly-optimized. Oh, like Minecruft.
How is this different than Aparapi?
http://code.google.com/p/aparapi/
Aparapi is a heterogeneous compute and data parallel framework for Java that automatically generates OpenCL from bytecode. There is no reason that Aparapi could not produce CUDA or HSA are well.
Aparapi was open-sourced by AMD over a year ago and is actively maintained by both AMD and other contributors.