Slashdot Mirror
Email In Oracle-Google Case Will Remain Public
itwbennett writes "When last we left the Oracle/Google patent infringement saga, Oracle had been ordered by Judge William Alsup to lower its claim for damages to $100 million, give or take. Today Judge Alsup denied Google's attempt to get a potentially damaging e-mail redacted. 'What we've actually been asked to do by Larry and Sergey is to investigate what technology alternatives exist to Java for Android and Chrome,' Google engineer Tim Lindholm wrote in the Aug. 2010 e-mail. 'We've been over a hundred of these and think they all suck. We conclude that we need to negotiate a license for Java.'"
It fits if google were thinking oh shit oracle have their hands on java we are screwed get us out, but its not like right at the start they were rubbing their hands with glee we know we have to pay for a license but we are not going to.
http://michaelsmith.id.au
August 2010 is much later than when Oracle bought Sun and long after Android was initially announced. In fact, all this email was sent just 2 days before Oracle filed their lawsuit.
Most ignorance is vincible ignorance. We don't know because we don't want to know. --Aldous Huxley
No, I'm serious. This is not about emails and licenses but about whether we tolerate monopoly ownership of ideas, i.e. software patents (or patents at all). Up until recently Google has been deliberately naive about the problem, shrugging it off and allowing others to take the hit. It's allowed Microsoft and Apple to accumulate large patent portfolios intended to stop free competition.
Google need to get hit, and they need to see software patents as a real threat to their plan of world domination. They need to realize that $100M buys a lot of lobbyists, and they need to spend that money in Washington to end the software patent system. Oracle is doing us a favour by forcing Google into court here. They're greedy enough to not want a nominal settlement, and they're smart enough to win their case.
So despite the fact that I'd rather stab myself with a blunt fork than install a piece of Oracle software on any machine I own, I'm rooting for them in this case, and I hope they win big.
My blog
ZING! But there's an NDK for Android as well, so it's not like you have to use Java anyway. There's even a way to write apps in Ruby now. Oh, and apparently you can sell AIR apps through the Android market as well. Realistically at this point Android doesn't really need Java at all, but it's too late for them to take it out. I personally think they should have done all the base components native, made an X11 like protocol for communication between widgets and apps and whatever, and then just told everyone to go for it. If that were the case using a VM based language would spare you some headaches, but even then you wouldn't be tied to Java as Ruby, Python, AIR/AS3, and a whole bunch of others would work just the same.
On a side note, I'm a bit ashamed to admit it but the SDK for Android running in Eclipse is really really nice and they've streamlined all the Java stuff and added enough libraries that things are pretty easy to understand and work with. I would have preferred something other than Java, and in general I'm a VIM/Makefile kind of guy so the whole IDE thing still puts me off but still I have to admit they did a great job.
One more thing: Fuck you Oracle!
> ZING! But there's an NDK for Android as well, so it's not like you have to use Java anyway.
Oh how naive you are... the NDK are C wrappers for the Java API. Yes, you heard me correctly... the C API wraps the Java API and not the other way around like it *should* be.
... for all the abuse Microsoft gets, at least you can do stuff like change the program counter in the IDE to re-run a piece of code.
Don't know whether the Java VM API (JVMTI) would allow setting the PC, but you can use "drop to frame" to start the current method again.
yup, it sounds like the email is a nerd's response to being asked to choose something other than his favourite technology... "we've been over a hundred of these" and the *only* one that I think is good enough is Java, of course. Just be thankful it wasn't someone who thought C# was the ultimate in all language technologies.
My position: C (maybe C++) would have been ideal for a low-level API that you then build on top of. In whatever language/technology you like once you have that API library established.
Years ago Google should have bought Sun Microsystems which I am sure why didn't they. Or why doesn't Google buy Oracle NOW
that's not how patent litigation works, i'm afraid.
if it did work like that and the jurys were free to do research on their own, then majority of patent litigation cases would end up with both parties patents being stamped with "obvious shit". because very few patents end up being groundbreaking or so innovative that they'd be worthy of a patent, and that's the world we're living in now.
world was created 5 seconds before this post as it is.
Some of us juggle all that stuff in our heads and have a complete map of our code, which becomes difficult to track when we have to deal with automagic shit or go make amendments or deletions from one side or the other.
There is no automagic. There never is. There are IDE-assisted automatic features (the majority of which is useful), the configuration and behavior of which are not rocket science, and which we either understand or we do not.
Others write bits of business logic and string it together, and hope it works; often these people rely on development environments to take care of some of the stringing together.
False dichotomy between the previous case and the later ones. It might surprise to some, there is people out there who understand the code and intelligently use automated tools for integrating it. We don't get paid to show off our l33t hax0r skills, but to intelligently use tools available for coding to our employer's benefit.
I will also argue, and there is plenty of evidence of it, that, unless you are an absolute genius, if you can completely map the code out in your brain, the complexity (not necessarily the size) of that code is trivial, or small-sized at best. Some languages (say Ruby or Python) are better than others (Java, C++) for helping the developer write more succinct, mentally-manageable code. But beyond a certain size and complexity, independently of whether it is systems or application development, one simply cannot claim to mentally map the code (unless you are the owner of a module and you are actively maintaining it.)
Also, it is a false dichotomy to present business logic and code as separate entities. Business logic gets implemented on code, on top of other non-functional requirements. Code is the executable representation of business logic, it is knowledge captured and codified in software. Break that relationship, and all you have is code for shit. Business logic changes constantly causing inevitable code/system changes and increasing entropy (yes, the 2nd law of thermodynamics applies to software).
It is our job to put constant effort in controlling/negating entropy in the affected systems. And that's what integrated environments are for, to provide for automated tools that when used intelligently in conjunction with good programming practices helps with that part of the software development cycle. These are just tools and they perform according to the hand that wields them. This is something that is sadly neglected or considered irrelevant or trivial.
Actually i'm willing to pay top-dollar for ANY of todays tablets that can run an optimized Lisp(common lisp preferred), any suggestions?
Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
Yeah, I was too vague when I said that. The integration in Eclipse is well done. Eclipse itself (editing) is awful. Things like Eclipse automatically adding random lines (like imports) whenever I copy and paste between files? Yeah, that's a terrible feature. Panes/splitting and pane management is very obscure as well. Oh, and tabs are characters, not 4 spaces - seriously fucking stop with the tab conversion.
C'mon man, this is 2011.
1. Window/Preferences/Editors/Text Editors/Insert spaces for tab (uncheck)
2. Windows/Preferences/Java/Code Style/Formatter/Active Profiler/Edit/Indentation Tab/Tab Policy: Use spaces to indent wrapped lines (uncheck)
You find those two in a most trivial manner. JFGI Eclipse style. Simply enter "tab" in the search box in the Windows/Preference window, and voila, it shows you how to control tab expansion. This is a capability present in any modern IDE or code editor. It is something trivial that one should reasonably expect any developer to figure it out rather quickly.
There are a lot of challenging things in software. This ain't one of them.
Go does not run in a VM - it's compiled directly to native code in the existing implementation. I assume they were looking at alternatives to JVM there.
False dichotomy between the previous case and the later ones. It might surprise to some, there is people out there who understand the code and intelligently use automated tools for integrating it. We don't get paid to show off our l33t hax0r skills, but to intelligently use tools available for coding to our employer's benefit.
If you are completely crippled by your tools not being available, you are not "intelligently using tools available." Many developers are baffled by things like memory management or reference counting, and want the language to figure out when memory is no longer in use and garbage collect it because they simply can't wrap their head around the idea of tracking data; many others sit down and design a program before writing spaghetti code, and occasionally cause implementation bugs. While you can be competent and write in Java, you can also turn white at the mention of C (and immediately confuse it with C++) and use Java to simulate knowing what in the hell you're doing.
All tools are like this. If you use them as a crutch, you will be glued to the tool, and probably come out incompetent. Some of us never liked the crutches. I don't like tap shifters and prefer a clutched manual transmission, and I -hate- automatics (having driven automatic only for 7 years before learning to drive a clutch, I think I'm qualified to comment on my preference against them). Some people drive automatics well; other people are constantly doing the ass dance on the brakes and gas, driving inefficiently and dangerously, following too close, burning up their brakes, etc. These people can't handle a clutch because they don't know how to drive in the first place, and driving on a stick will prove a completely confusing challenge. I have an uncle like that, and while he's mastered not stalling his car by braking too god damn much, he also burns clutches out in 10,000 miles.
Tools are tools. If you can't live without a certain tool, you are blind and don't understand the task you're doing. Building houses with hammers and nails is slow and sucky; building a house with power drills and screws or with nail guns is excellent, takes a day or so for a good team (yeah, it can be done), but in a pinch you can spend a few weeks or months hammering together a big 4 bedroom 3 bathroom house with primitive hand tools. It is the same with other tools--some tools facilitate complex and blindingly fast work, while others simply add convenience but can be discarded by those who favor a different method.
I will also argue, and there is plenty of evidence of it, that, unless you are an absolute genius, if you can completely map the code out in your brain, the complexity (not necessarily the size) of that code is trivial, or small-sized at best. Some languages (say Ruby or Python) are better than others (Java, C++) for helping the developer write more succinct, mentally-manageable code. But beyond a certain size and complexity, independently of whether it is systems or application development, one simply cannot claim to mentally map the code (unless you are the owner of a module and you are actively maintaining it.)
I put a lot of time into the design of programs, so much so that I actually enjoy designing more than actually programming. At a high level, it is possible to determine a lot of the problems you'll face (mostly data management between business logic modules), and then come up with strategies for making everything work together. It is this that you work on first, such that the complex portion becomes little bits of "tell it to do this, it works." In short, separate tasks that can be separated even if they make no logical sense to separate: sure, I'll only do X and Y when doing X, Y, and Z, but why should I make X and Y one giant, complicated, confusing operation when I can make it one small, streamlined operation or--failing that--two operations that are easy to understand separately?
One thing I do when bore
Support my political activism on Patreon.