Slashdot Mirror
Google Backs Out of JavaOne
snydeq writes "Citing concerns about Oracle's lawsuit against it, Google has backed out of the upcoming JavaOne conference. 'Oracle's recent lawsuit against Google and open source has made it impossible for us to freely share our thoughts about the future of Java and open source generally,' Google's Joshua Bloch said in a blog post. The move may signal eventual fragmentation for Java, with Google conceivably splintering off the Java-like language it uses for Android."
Looks like we're seeing a new loss of confidence in Java, much like the loss of confidence in mono, for which patent concerns stunted its uptake.
So where to next?
And where is my replacement for open office?
Java's death means .NET and Windows in the server arena. Do you really want that?
Java is the defacto standard for most server apps these days as portals are replacing terminals and Java is used for industrial websites as well. This is truly horrible and no php or perl can not just replace it for mission critical servers. It is not hte language but the 200,000 methods and api's to choose from. Only .NET comes close ... not Mono.
http://saveie6.com/
Except that Android doesn't run Java classes - it runs dalvik classes. It's like you taking a .doc file and converting it to pdf so that people don't need the Evil Word.
Java's dying anyway. It's a lot slower than dalvik, and Java simply hasn't lived up to its "write once run anywhere" claims. Just like it hasn't lived up to earlier promises to "reinvent the desktop", or before that, to "change the way we use the Internet with applets - remember them - to add interactivity.
What are they going to do when dalvik is extended to run on regular servers, and all those Java support contracts dry up? Just like is happening right now in the mobile space with the multi-fragmented JavaME?. Pretty bad when your core market tells you that the competition already raided your fridge, ate your breakfast and lunch, and took a dump on your supper.
> Java's death means .NET and Windows in the server arena.
That's an interesting theory and I agree with it. .NET/Windows on the long run to avoid Java?
I'm wondering if this really is one of the consequences Oracle indended with this lawsuit.
What value would the acquired Sun be if everybody switched to
Sun open sourced Java, and you can easily fork it. You can't call it Java unless it still implements the specification correctly, but the license that Sun released the code under means that you are safe from patent problems.
Google's problem is that they did not fork Java, they reimplemented it. This means that they have no copyright problems and do not have to abide by the Java license (GPL + runtime exemption), but they do have potential patent problems. Sun / Oracle has a patent grant that permits the use of their Java-related patents in any complete implementation of the Java spec. Android, however, is not a complete Java implementation. It implements the core language and a number of the java.* classes, but it does not provide the entire java.* class hierarchy. This means that it is not covered by the patent grant.
In summary, open source Java is fine, open source almost-Java is not.
I am TheRaven on Soylent News
The similarity of android's dev language with Java is only superficial
You mean, aside from the fact that they are exactly the same language and both provide a large number of the same classes in the java.* namespace, they are completely different?
I am TheRaven on Soylent News
It's still huge in Big Business, where COBOL also remains alive and well.
.NET.
From what I've seen, it's still largely popular as a web application language for the server-side. Usually an alternative to
This lawsuit boggles my mind. I'm sure the guys running Oracle are pretty smart. Can't they see that no matter the outcome of the lawsuit, they are losing big on reputation and client lock-in just by pursuing it? Am I missing some great strategic outcome Oracle is hoping for?
> In summary, open source Java is fine, open source almost-Java is not.
Where is the difference? Isn't that legal newspeak of corporate lawyers... and why we have a free software movement? I can't see how this sentence makes any sense to an open source developer.
Dream on if yo believe that the JIT is competitive. Even if it were able to pre-compile everything to native methods, you still lack some of the essential programming models that people have been using for decades to make things go faster.
I wasn't asking for proof that native code will be faster than Java, I was asking for proof of your original statement that that Java (I assume you meant the JVM) is a lot slower than Dalvik.
But yes, you're right, there's a hell of a lot of stuff that Java (be it running on a JVM or Dalvik) just won't do well, and anybody wanting to write truly high performance software had really better get used to writing in lower-level languages, or at the very least, understanding their stack right down to the hardware level.
you can't even consider using some algorithms that c programmers use all the time
Like buffer overruns.
-=Maggie Leber=-
... anybody wanting to write truly high performance software had really better get used to writing in lower-level languages, or at the very least, understanding their stack right down to the hardware level.
This has always been the case.
"You want to know how to help your kids? Leave them the fuck alone." -George Carlin
In c, it means that you get in the habit of typing free() right after typing malloc(), then asking yourself, where does the free() really belong? Who is going to "own" this memory. If it doesn't fit naturally within that block, you need to make sure that it's taken care of somewhere else. Move the free() there, and paste in a comment as to who frees it.
In c++, it means making sure that every object owns its own resources, or you enforce a contract with any object it serves as a "factory" to, that the recipient will free it, but not both.
It is possible to write leak-resistant (even leak-free) code. It just takes some attention to detail. But at that point, you have a detrministic program, not one whose performance is dependent on when/if a garbage collector decides to do some cleanup - and you can also do away with the whole {smart|weak}_ptr garbage.
Do you have a bank account?
Most likely the back office operations are using Java in one way or another.
That is just for starters.
People saying that Java is dead and then refer to what is happening on their home computer simply show a degree og ignorance that is short of embarrasing.
IANAL but write like a drunk one.
Oracle is sueing for patent infringement, not trademark infringement.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
So wouldn't Google's best option be for them to just implement the missing classes?
Ah yes, C is good for domain-specific solutions but it doesn't adequately address the issue of multiple inheritance out of the box. (reference)
Same language? C# and Javascript have nearly identical syntax. I think it's completely unreasonable to expect someone to invent a brand new syntax for every programming language.
Some of the same classes? Look at how many other languages have analogous classes in their libraries. It's irresponsible not to provide string utilities, for one.
The similarity of android's dev language with Java is only superficial
You mean, aside from the fact that they are exactly the same language and both provide a large number of the same classes in the java.* namespace, they are completely different?
Damn, I'm going to do it -- I'm going to make a car analogy. I'm sorry in advance, because I *know* someone is going to helpfully correct it and take it far beyond the point I was trying to prove.
Let's say all cars had a single engine they used. They could manufacture this engine themselves, but it had to conform to the agreed-upon specs if they wanted to call it a "car engine". So Ford and Chevy and Toyota are all happily marketing cars with Genuine Car Engines; they have different trim and options, but they all use the same Car Engine under the hood.
Suddenly Hyundai comes along with its new line of cars which also uses a Genuine Car Engine. Except - as it turns out - their engine is custom built from the ground up. Its interfaces conform to the Car Engine spec, but internally it functions completely differently. If you dropped a Ford card body onto a Hyundai Car Engine, it wouldn't work at all correctly. The check engine light would play the tune of Old McDonald's and the turn signals would put the car into reverse.
Hyundai's Car Engine is superficially the same as the standard Car Engine, but it doesn't work the same way; nor does it do the same things.
Okay, I may have gotten carried away there. So let's try without the car analogy. The language constructs are the same. Even many classes are shared with the same functionality. However, you cannot execute compiled GoogleJava code on a standard JVM; and you cannot execute standard Java binaries on a Google Car Engine... erm, JVM. This is true even if the source code uses only classes that are shared in common across both platforms.
In summary, open source Java is fine, open source almost-Java is not.
If you make a derivation/fork with the open source Java code Oracle only extends patent grants if your fork passes Oracle's expensive certification tests for Java. This certification is impractical for most people or organizations and is inherently impossible for anybody who is interested in making a new language with the code or adapting some of the code for other purposes.
In summary:
-stephen
The only difference here is that Sun sued over calling something "Java" that wasn't exactly Java. Oracle is doing something a bit deeper in that they are saying that Google can't fork the language even if they call it something different.
I think I've missed something - last I saw, Google isn't calling it something different? If they were, I can't see how this would be a problem. But when I look at the Android Fundamentals page, this is the first thing I see (emphasis added):
Android applications are written in the Java programming language. The compiled Java code — along with any data and resource files required by the application — is bundled by the aapt tool into an Android package, an archive file marked by an .apk suffix. T
So where do you see that they're not calling it Java?
Don't get me started on the platform.
Okay, I'm game. What's wrong with the platform?
The higher the technology, the sharper that two-edged sword.
That's a technique, not an algorithm.
It's not that hard - just do like your mother taught you - put things back when you're finished with them.
Two things. First it is hard. It takes an almost anal level of attention to detail especially in a multi-threaded environment. That's something woefully missing in your run of the mill programmer. Second, the bugs introduced can be EXTREMELY subtle and VERY difficult to find especially in a multi-threaded environment.
Anecdote: I was working on a multi-threaded realtime system that involved message queues between objects interacting with hardware. The queuing system was developed by someone else and had gone through extensive testing. I was tasked with adding network communications to the messaging system. With the network communications module added it was core dumping at random times and places generally after days of running. I spent over a month trying to find the problem in my code. All the while, the people who had developed the messaging system insisted the problem couldn't be there and showed me the months of tests result on the messaging system. After over a month, including line by line review of my code, I started looking over the messaging system code I found one place where they were releasing a mutex then freeing some memory. 2 lines of code that were reversed amongst 1000's of lines of code. Their testing didn't reveal it because on their test runs there was almost no random variance in the execution. Everything responded at fixed intervals and the pattern never including something getting a pointer to that memory after the mutex was released and before it was freed. The network communications added randomness which disrupted the pattern and this happened periodically.
Who is John Galt?
The C version is easy to understand when you are in total control and total understanding of the program flow. However, it's a nightmare for people trying to enhance or restructure the code because they can so easily cause the free() to not get called, get double called or to simply not realize all the places cleanup code is required. This is particularly true for all kinds of exception-like flows, that everything is cleared up in all varieties.
If you strictly adhere to RAII in C++ then things are fairly ok, but I honestly think that in this case C++ is too C-ish and not object oriented enough. Personally if I was designing a new language from scratch I would not do it like Java, but rather a resource tree where every object has a list of children and explicit keywords to pass and share ownership, where the latter would cause automatic ref-counting pointers. For those of you who have worked with C++/Qt, something like QObject but much deeper integrated into the language itself and with safeguards to not lose pointers so every bit of memory used can be explored from one root node and will be deterministically deleted when its owner goes out of scope or is deleted.
Live today, because you never know what tomorrow brings
Two enormous differences with the Sun/Microsoft case: 1-- Everything Google built for Android is open-sourced; 2-- No Java license is involved
Google built a VM called Dalvik. Like the Java and .Net VM's, it can run code written in a number of languages, including the Java language. That patents at issue are not related specifically to the Java language, but they do cover common techniques in VM implementation, and if upheld could threaten other VM implementations.
Yeah, but Google has no plans to do anything of the sort, and Oracle is still suing.
Oracle's beef seems to be that Android doesn't come with Java but happens to infringe on some Java patents. Why the fuck they don't rectify the problem themselves by releasing a version of Java for Android is anyone's guess. Maybe they're just assholes.
You are not alone. This is not normal. None of this is normal.
No, you may use pointer arithmetic to *IMPLEMENT* an algorithm more efficiently, but that doesn't make it a new or better algorithm, it just makes it a more efficient implementation.
File under 'M' for 'Manic ranting'
The full Java SE is not appropriate for a mobile phone, far to heavyweight and full of APIs like the AWT, SWT etc.
Sun also produced Java ME for mobile use which they charged phone makers to license. Sun (now Oracle) only open sourced, and gave patent grants for, the desktop oriented Standard Edition where they didn't have any revenue anyway. They were careful in the licensing not to allow a free Mobile Edition which would threaten their mobile revenue.
This was a significant problem for Apache's Harmony project. They couldn't accept Sun's restrictions on use so Sun wouldn't license them as a conforming implementation (despite them having done the work to pass the tests).
In practice, the terms of the patent grant mean that while the Java Virtual Machine implementation is free software and can be altered (such as RedHat's work porting the OpenJDK to other architectures). Java as a whole doesn't give you the freedom to make changes to the standard libraries (even if you do call it something else); it's hard to consider it free software.
It's all particularly annoying since, post-iPhone, Java ME has slipped into irrelevancy. There's no particularly strong reason why Google based the Android environment (dalvik) on the java language (though not on the JVM nor standard libs) rather than something else. The availability of Harmony code for reuse, existing tooling in the form of Eclipse, developer familiarity, and substantial internal use of java at Google probably played a part. Interoperability with other mobile java certainly didn't.
Yep, what garbage collection giveth, everything else takes away. For any resource other than RAM Java is more complex/verbose than, say, C++. eg. You want a file to close in a timely manner so the user can copy it to a USB stick without quitting the program first? Start typing another try/finally block. Same with network connections, database connections, etc., you can't rely on the garbage collector to close them for you.
Even garbage collection of RAM is very overrated, eg. I'm working on a 200,000 line C++ program right now and there's exactly 9 'delete' statements in it. All the rest is completely automated via. smart pointers and stack unwinding. The person who adds the tenth 'delete' has to buy lunch for everybody.
Then there's the performance. I don't mean microbenchmarks, I mean real-world performance with millions of memory allocations. Garbage collecting them will destroy any illusion of performance you might have had. Much worse is if you run out of RAM and start paging to disk. In that situation the last thing you want is something continually scanning the entire heap, but that's exactly what the garbage collector does...
Of course C++ can be very complex in other ways and there's an awful lot of traps for beginners, but IMHO Java wasn't the answer and even the famous garbage collection is a two-edged sword.
No sig today...
No, and no. If you are doing multithreaded programming, you can use reference counting. It's not at all hard to do explicit retain/release unless your program is crap by design. In many cases, doing so explicitly and with careful thought can greatly improve performance.
For example, not all garbage collectors do a great job when you have complex circular data structures. However, if you know that your complex structure is principally a tree with some links to higher nodes, you can simply not use a reference count, but rather a reverse reference list to point to the nodes that link backwards, then unlink the back-references as part of your destructor when the reference count goes to zero. Yes, you can potentially use weak references for the same thing, but that assumes that you don't need to change some other aspect of the data structure when the uplinked node becomes unavailable, e.g. caching the last value of some field in the higher node.
And, of course, if you know that the entire data structure, regardless of complexity, comes and goes away as soon as there are no references to the root node remaining, then you can make things much, much simpler with explicit memory management. You use a reference-counted object that points to the root node instead, and in its destructor, you recursively nuke the actual data structure with abandon. Then, there's no reason to worry about whether a particular reference should be strong or weak.
Likewise, many garbage collectors aren't good at quickly disposing of objects that are only created momentarily, used, then disposed of within a single function. For those objects, manual allocation is always a better choice in terms of performance because you can be absolutely certain that they don't linger any longer than necessary. If those data objects are large, this can have a significant impact on performance versus GC.
And without regard to how good or bad the GC system is, you can always get a big performance win by manually managing everything. As soon as you have a thread traversing an object graph to check reachability, you've already lost the performance battle at a very fundamental level. You're either wasting CPU cycles, wasting memory, or both to determine whether an object can be freed---information that the programmer should be able to much more easily and quickly determine due to having a better understanding of which objects can realistically reference it.
Sure, a naive multithreaded programmer who doesn't use any reference counters and tries to free things while another thread is still using them can break things, but that's also true of the naive programmer who doesn't use reader-writer locks around data structures to prevent somebody from reading them while another thread is taking nodes out of a linked data structure, etc. Your example could just as easily have occurred with somebody assigning a value to NULL outside the lock. Indeed, your example is actually trivial to detect with proper tests (particularly when compared with arbitrary data structure mutations, hence the reason that you should religiously confine code that modifies data structures to a handful of functions that do nothing but modify the data structure in a particular way). You can simply add code in the destructor (C++ example):
Check out my sci-fi/humor trilogy at PatriotsBooks.
Which "lower level languages" are you talking about? Lower level languages are platform specific, and the only one people are using is assembler. I know that you didnt mean asembler. I suppose you meant C. Its abstract machine has a generic concept of memory as a linear pool. Good enough to write operating system features that manage linear pools of memory, but decidedly not at all low level. We can't even coerce a C compiler to emit x86 instructions like BT, BTR, and BTS.. instructions which test and manipulate individual bits (in registers or in memory) and are extremely useful (efficient!) for implementing things like a Bloom Hash, or just implementing bit arrays. In C the best we can do is use clunky full-word operations that can not get optimized down to BT, BTR, or BTS for multiple technical reasons.
Is this a joke? Anything that isn't assembly is a high level language? News to me.
C is very obviously a low level language. It's not exactly controversial.
Parent is basically correct. However, pedantically, Dalvik does not, in general, run programs written in the Java language. The language is defined not just by its syntax, but also by a certain set of standard libraries being present and implemented according to Sun/Oracle specification. Dalvik doesn't support all of those, and hence doesn't run Java.
However, Dalvik does run a very Java-like language. One that has all the syntax of Java, and *many* of the same libraries. Moreover (as everyone here knows, I'm sure), programs compiled by 'javac' to .class file may be converted to Dalvik executables (as long as they contain only the subset of Java that Dalvik supports).
It would be proper to prevent Google from claiming that Android "Runs Java"... but then, I'm pretty sure they never claimed that to start with. Indeed mostly--almost entirely--it's claims about patents that should never have been granted, or really just about lawsuits to try to mess up competition and technical progress just for the sake of disruption (I doubt Oracle actually cares that much about the outcome, it's mostly FUD).
Buy Text Processing in Python
Isn't this the perfect moment for Google to pass to Scala for Java-like development and Go! for the rest of it (critical native components)? To hell with Java the language. After all, what is really important is the JVM and they've already forked that with Dalvik.
"Sum Ergo Cogito"
Sun open sourced Java, and you can easily fork it. You can't call it Java unless it still implements the specification correctly, but the license that Sun released the code under means that you are safe from patent problems.
No, you are only safe from patent problems if Oracle determines that your implementation is fully compatible.
Google's problem is that they did not fork Java, they reimplemented it.
Google didn't reimplement the Java platform, they implemented their own platform and used the Java language. Oracle has no patents on the Java language. And the patents they do have, they could have sued over no matter what virtual machine Google had implemented.
In summary, open source Java is fine, open source almost-Java is not.
There is no "open source Java"; open source principles require the ability to make incompatible forks, and as you correctly pointed out, Oracle doesn't allow that and has the patents to enforce their will.
C is very obviously a low level language.
What exactly do you think is low level about C? I think that you are confusing a lack-of-features like OO, Generics, Reflection, etc.. with 'low level' ..do you think its low level because it can reference memory directly? Really? Is that your metric?
I'm not confusing lack of features (abstractions) with low level - abstractions are exactly what makes a language high level. Yes, C making you reference memory directly makes it low level. High level languages take you far, far away from such interactions.
Call me back when your operating system is written in Java. Oh wait, Sun tried that - another failure.
You're an idiot.
Same language? C# and Javascript have nearly identical syntax
Nearly identical is not identical. At the language level, the language that Google uses is identical to Java, both in terms of syntax and semantics. C# is close to Java, but is clearly a distinct language. JavaScript has vaguely Java-like syntax, but Self-like semantics (while Java has Smalltalk-like semantics).
Some of the same classes? Look at how many other languages have analogous classes in their libraries. It's irresponsible not to provide string utilities, for one.
There is a difference between similar and identical. Google's Java, being the same language as Sun's Java, has namespaces. In these namespaces, there are classes. Android ships with a large number of classes in the java.* namespace, which have identical names and methods to the classes in the java.* namespace.
All vaguely OO languages have some kind of string class. Java has java.String, Java.StringBuffer. Objective-C has NSString and NSMutableString. C++ has std::string. Google's language that you are claiming is not Java has... java.String, Java.StringBuffer. All classes in Google's not-Java-really language inherit from... java.Object.
When two languages have identical syntax, identical semantics, and an identical core standard library, claiming that they are not the same language is a bit difficult. Rather than just wave your hands, maybe you could point to somewhere where Java and Google's language are actually different.
I am TheRaven on Soylent News
I'm not confusing lack of features (abstractions) with low level - abstractions are exactly what makes a language high level. Yes, C making you reference memory directly makes it low level. High level languages take you far, far away from such interactions.
Pointers are an abstraction
Apparently you didnt fucking know this, but C is a programming language defined by a standardized abstract machine which itself was tailored specifically for the purposes of abstracting operating system memory management.
Furthermore, C does not 'make' you reference memory directly. C 'allows' you to reference memory directly.
Did you not realize that BASIC qualifies as 'low level' under your definition of direct memory referencing I guess its PEEK and POKE for the win, eh?
"His name was James Damore."
You misunderstand what I'm getting at. Pointer arithmetic may make an implementation faster, but that doesn't make the algorithm itself any faster. A faster algorithm is one that has a lower speed complexity, not one that simply runs more quickly than another. I'm not saying that pointer arithmetic isn't useful, only that it's superfluous to designing faster algorithms. At best, it's an implementation detail.
File under 'M' for 'Manic ranting'