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."

Comments

!Good

[Warll]

The move may signal eventually fragmentation for Java, with Google conceivably splintering off the Java-like language it uses for Android.

Oracle should use their Java related patents to stop this from happening,

Oh wait...

Re:!Good

[tomhudson]

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.

Re:!Good

[tomhudson]

Java is still a lot slower than native methods - it's also, unfortunately, so inflexible compared to, say, c, that you can't even consider using some algorithms that c programmers use all the time. That's what happens when you can't do pointer math - you lose a whole class of efficient ways to do things. Ditto for the lack of first-class functions, so no function pointers for you.

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.

Re:!Good

[Anonymous Coward]

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.

Re:!Good

[MaggieL]

you can't even consider using some algorithms that c programmers use all the time

Like buffer overruns.

Re:!Good

[Local ID10T]

... 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.

Re:!Good

[tomhudson]

The problem is that the Javanistas won't admit it - that Java sometimes, beyond a certain size, introduces MORE complexity than lower-level languages that are more flexible. To them, this is "utterly impossible" - but what do you expect from someone who is afraid to even attempt memory allocation. It's not that hard - just do like your mother taught you - put things back when you're finished with them.

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.

Re:!Good

[kevinNCSU]

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)

Re:!Good

[gabebear]

Native code is always going to be 'potentially' faster than any interpreted language, but Java has quite a few optimization advantages because it doesn't use pointers. Interpreted has a lot of weak points(like overhead when all your program is doing is just calling native methods), but lack of pointers isn't all bad. http://scribblethink.org/Computer/javaCbenchmark.html

The GP was responding to whether Dalvik is really faster than Java on other phones. A LOT of optimization has gone into the Java VM. Since Android doesn't run Java(which is why they are getting sued), this is difficult. There is a post comparing the Sony Ericsson Xperia X1 and the T-Mobile G1, which have nearly identical hardware specs. In that case, Dalvik was 8x slower. http://groups.google.com/group/android-platform/browse_thread/thread/ede9ba8c787661a1/f155644d757f7bbf?#f155644d757f7bbf

Re:!Good

[Rockoon]

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.

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.

Re:!Good

[tomhudson]

Try such basic stuff as pointer arithmetic.

Re:!Good

[tomhudson]

Java, because you can't use pointer arithmetic, is going to be slower than the same code in c using pointer arithmetic, because a non-pointer solution is always going to be slower, in any language, even c.

The lack of pointers was the only way that Java could be implemented. Another reason was to keep both the class verifier the garbage collector simple. You can't "prove" code that can point to something different during the actual run. Both these restrictions introduce behind-the-scenes overhead, as well as restricting what you, the programmer, can write.

The lack of first-class functions is also another area where you are restricted in what you can code. You can't just have, say, a nice tight loop that executes a function, and calls address+mode*size_of_pointer_to_function - you need to write a switch or if/else. For things like modal parsers, this makes a difference. No one-line while() or for() for YOU! Your code, which fits nicely into the cpu cache, L1 cache, probably won't in Java, so the performance hit will be huge.

Re:!Good

[Anonymous Coward]

That's a technique, not an algorithm.

Re:!Good

[McGiraf]

lol

True, but thats is the bad side of C letting you do whatever you want.

With C you are not constrained, you can do very clever things you cannot do in Java, or incredibly stupid things that Java will prevent.

The same happens when you remove the trainer wheels on a bicycle.

Re:!Good

[squiggleslash]

You don't have to use a switch. What you can do in this instance is create an array of objects, which can be anonymous inner classes, with a named method representing the function you want to call. Something like this (be aware I'm just typing this, I haven't tested it!):

:
:
abstract class switcheroo {
void function_to_call();
}

void setTrafficLight(int lightNo) {
switcheroo[] lightHandlers = new switcheroo[3];

lightHandlers[0] = new switcheroo {
void function_to_call() {
setUpRed();
}
};

lightHandlers[1] = new switcheroo {
void function_to_call() {
setUpAmber();
}
};

lightHandlers[2] = new switcheroo {
void function_to_call() {
setUpGreen();
}
};

lightHandlers[lightNo].function_to_call();
}

Of course, you'd want to optimize this a little more (set up the array before-hand rather than with every call, etc) but the point is you're left with pretty much exactly the same assembled code as you'd have had if you had been using an array of function pointers.

Is it more longwinded? Why yes! But one could also argue that (a) the number of cases you'd actually legitimately want to do the above is small, especially in an environment in which you have an object layer to abstract things and thus would want to split where you make code central, and where you make things data specific, along different lines, (b) it's inherently an unsafe technique.

I can honestly say that in the years I've been doing Java programming, I've never once needed, or wanted, to use an array of function pointers. The way you handle data is entirely different to that of C, you just don't end up needing this.

Re:!Good

[greenbird]

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.

Re:!Good

[Kjella]

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.

Re:!Good

[mario_grgic]

What kind of algorithm can you implement with a pointer, but not with a reference?

Re:!Good

[Yosho]

Ok, so basically your reason why C is better than Java is that if you write perfect code, you never have to worry about memory issues.

Why not just write in FORTRAN? Or Assembly, even?

Re:!Good

[tomhudson]

You use pointer arithmetic to design more efficient algorithms, duh!

Re:!Good

[mark-t]

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.

Re:!Good

[Joce640k]

This is why sensible programmers moved to C++ and use range-checked, auto-growing container objects.

Re:!Good

[Joce640k]

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.

Re:!Good

[dgatwood]

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.

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):

#if DEBUG
object_type *rootObject = this->getRootObject();
for (int i=0; i<100; i++) {
int islockedforwriting = pthread_rwlock_tryrdlock(rootObject->rdwrlock();
assert(islockedforwriting != 0); // We should not be able to obtain a read lock right now.
}
#endif

Re:!Good

[tomhudson]

And THIS is just one exampe of how Java is overly verbose. You still end up creating a bunch of "glue" that's simply not needed with pointers to functions and/or jumps to a function at offset PTR_BASE+(mode*PTR_SIZE);

Just enum RED_LIGHT=0, YELLOW_LIGHT, GREEN_LIGHT then either jump to the offset at LIGHT_FUNCS+light*PTR_SIZE, or if you've created an array of function pointers, set lights[NORTH_SOUTH] = light_funcs[light]; Your code becomes more generic, even though the code for handling a red light may be completely different than the code for a green light, which may, for example, refuse to set itself to green if lights[EAST_WEST] is still green, setting the function lights[NORTH_SOUTH] pointing back to light_funcs[RED_LIGHT], and return, rather than a whole bunch of trys, cases, ifs, and exception handlers.

The best part is that you can now tie this (by using the volatile keyword) into a real-time external process that changes one byte of ram. Set up a thread to check that address every second and you've got your light controller for that street corner.

Need to expand it to 10,000 street corners? Not a problem - your total memory requirements only grew by 2*sizeof(ptr), plus 2 byte for light state (000=both_blinking_red, 001=both_red, 010=nsgreen, 011=ewgreen, 100=nsyellow, 101=ewyellow) and seconds_elapsed (a 13-bit integer - good for more than 2 hours); Even on 64-bit systems, the whole 10,000 light controller (data and code) would fit into well under 200k. On a 16-bit system it could probably be shoe-horned into 64k (in this case it's the pointers that eat up the space on 64-bit systems - 20,000 pointers only take up 40k on 16 bits).

There's no way you'd ever get that to run in 64k under Java - just the run-time takes a LOT more than that.

Re:!Good

[Spewns]

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.

Re:!Good

[tomhudson]

Yes, multi-threaded is harder, but you get used to it, like anything else. And then, like anything else, you get a gut instinct as to where you or someone else screwed up, just by the way the code is reacting.

If it were easy, everyone would be doing it. But the performance benefits of not needing things like reference counts, garbage collectors, etc., make it worth it. After all, you fix the problem once, and reap the benefits the billions of times that code executes.

If we were to truly cost out the cost of inefficient code (energy consumption, increased hardware requirements, etc.) I think we'd pay more attention to optimizing code, and programming languages that allow you to work at a lower level.

Picture a multi-threaded app that is written in language X. It runs fine on a single core, until a certain point, where it now has to use a second core. Everything slows down, because now you have to synchronize across cores - a much slower process, and you pollute the cache a lot more. Even worse if it's across external cpus - time for a rewrite. So an app that was running 500 requests a sec on one core is only able to run 750 on two cores, 900 on 3 cores, 1050 on 4 cores, etc., nowhere near linear scaling.

Now re-implement it in language Y that uses fewer resources, runs quicker out of the box, etc. It runs 1,000 requests a second on one core, 1500 on two cores, 1800 on 3, and 2100 on 4. But since you're now working at a lower level, you can cheat a bit, and you manage to pick up a further 10% speed increase.

So while language X now needs a second quad-core box, and maxes both of those out at less than 2000 requests/sec, language Y is running fine on a single box, and individual requests are still served much quicker from start to finish

Multiply that scenario by a million redundant servers, plus electricity, ac, space, management, etc, to begin to understand what inefficient languages really cost us all. A billion here, a billion there, and soon you're talking real money!

Re:!Good

[tomhudson]

Any algorithm can be execed on any Turing complete language. ANYTHING you can write in C you can write in java and vista versa in terms of an algorithm.

False. You cannot do pointer arithmetic in Java, so algorithms that depend on pointer math must be transformed into a DIFFERENT algorithm.

The end result may be the same for the same input, but the algorithm (the "steps you take to solve the problem") is different.

>blockquote> My java program is over 5x faster than the C one it replaces and it uses less memory for a given problem and it doesn't segfault with bad arguments. Facts just doesn't seem to matter you "C is the fastest" facktards. >/blockquote> Not my fault you can't write decent c code.

BTW - you might want to look at what language your JVM was implemented in. Hint - it wasn't Java. Second hint - it was c.

Re:!Good

[squiggleslash]

As I said above:

1. This would, indeed, compile to almost exactly the same code as C.
2. You wouldn't do it this way in Java, because you'd be thinking about the data differently.

FWIW, the C code wouldn't fit in 64k either, for obvious reasons - if you're talking about 10,000 functions, they'd have to be really tiny to all fit into 24k. The jump table will, in both Java and C, be around 40,000 bytes. For us to get close to a point where the number of functions would result in code under 64k for C, and slightly over for Java, is probably closer to around 1,000 functions than 10,000.

But as I said, there's a reason this type of structure is rarely used in Java - it's not that the above is verbose (everything's verbose in Java! Not because it results in larger code but because it's stricter, forcing programmers to say exactly what they want the more dangerous the code is - and as soon as you start talking about more complicated code structures, you're generally looking at less verbose code on the Java side anyway), it's that you're thinking about the data differently.

The most common use of a jump table in C is to abstract a set of object-dependent functions. In AmigaOS, for example, each library shipped with a jump table. Regardless of how the library was implemented, you always knew that dos.library's Open() function could be called using DOSBASE+16 (not that you would, obviously, every C compiler came with that all wrapped up in a stub for you. BTW, I'm probably wrong on the 16, but...)

In Java, that's already been done for you. How frequently do you think anyone needs a jump table in Java? How much Java code have you seen where a switch() could easily be replaced by a jump table, and do you think in those rare cases the JVM is really writing out 10,000 CMP X,2; BRE HANDLER_FOR_2, CMP X,3; BRE HANDLER_FOR_3; ... type statements, or do you think it'd recognize that optimization anyway in the same way that 99% of C compilers do?

Re:!Good

[greenbird]

Multithreaded programming is hard, and management of access rights to data structures is critical. If you're doing that correctly, then manual memory management adds a negligible amount of complexity to that in most cases, but gives you a significant win in performance. If you're not doing that correctly, then garbage collection merely reduces the risk of some types of errant behavior while simultaneously increasing the likelihood of other types.

You're missing the point. The combination of manual memory management with multi-threaded programming makes for much more subtle and difficult to find bugs. No program or programmer is perfect. There WILL be bugs. The problem is that combination can make them orders of magnitude more difficult to find.

Re:!Good

[tomhudson]

It's just too important and complicated and common to be left to the programmer.

That says more about the sorry state of the "common programmer" than anything else. Memory management wasn't that hard for previous generations of programmers, when did it become such a problem? Oh, right - when schools started replacing c with Java.

It's NOT that complicated, just a bit tedious, and requires a bit of forethought about who "owns" the allocated memory. This is a good thing, because it makes you plan instead of just banging out code and throwing it at the wall.

Re:!Good

[Anonymous Coward]

Manual memory management was a solved problem 10 years ago in C++. The people who claim "buffer overflow" in the same sentence with C++ are those who program in C-with-classes. The RAII-using scoped_ptr is as efficient as manual releasing is, and the reference-counted shared_ptr is often vastly more efficient (and flexible) than an automatic GC. The only place in C++ code that should be doing manual allocation is in custom new/delete operators.

Re:!Good

[greenbird]

Yes, multi-threaded is harder, but you get used to it, like anything else. And then, like anything else, you get a gut instinct as to where you or someone else screwed up, just by the way the code is reacting.

I agree whole heartedly with everything you said. But the quoted above is the key factor. It is harder. Manual memory management is also harder. Those combined makes for a programming environment that is harder than the average code jockey can comprehend. This results in code with very subtle bugs that can be extremely difficult to track down. The point I was trying to make is that C++ is rarely a simpler programming environment than Java. It requires a much better understanding of what's happening at a much lower level to figure out the bugs. I've codded some pretty complex programs in Java including some that required soft realtime monitoring over the internet and I've never encountered a bug that was as difficult to track down as some I've encountered in C or C++. Again I'm not saying Java is the answer in all cases but the majority of the time it's sufficient to get the job done and much cheaper from both a development and a support perspective.

Re:!Good

[tomhudson]

Ok, so basically your reason why C is better than Java is that if you write perfect code, you never have to worry about memory issues.

Why not just write in FORTRAN? Or Assembly, even?

Sure, I'm okay with either.

What you're saying is that Java programmers don't know how to manage memory. Kind of understandable, given the bloated memory footprint of many java applications :-)

Re:!Good

[tomhudson]

this is just so wrong I don't know where to start. I'll start with escape analysis, and end with "why does Fortran code run faster than C". You really are ignorant about compilers and programing. Your C tunnel vision has blinded you from 40 years of R&D.

... and then you do neither.

She has a better response to you "points".

Call me back when your operating system is written in Java. Oh wait, Sun tried that - another failure.

Re:!Good

[Xyrus]

The problem is that the Javanistas won't admit it - that Java sometimes, beyond a certain size, introduces MORE complexity than lower-level languages that are more flexible.

Two things. First you make a mighty big claim about complexity. You're going to need to back that up. If object oriented languages introduce more complexity into an application, then why would anyone use them?

Second, you make the claim the lower level languages are more flexible. True. However, that isn't necessarily a good thing. A language like C gives you endless ways of shooting yourself in the foot, and sometimes it could be months or years before you realize (or worse, someone else) realizes you DID shoot yourself in the foot.

I've programmed in languages ranging from custom assembler to .NET. Languages like Java and .NET help mitigate the risk of shooting yourself in the foot (it is still possible, but it is harder to do). Languages like assembler and C allow you to get more performance, but with an increased risk of bugs. Any software engineer or programmer worth their salt will tell you that you always use the appropriate tool for the job at hand.

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.

Which in a large complex application can become extremely tedious and/or prone to errors. A new programmer coming on board isn't going to know all the nuances of the code base. You're also depending on the comments to be reliable, which may or may not be the case. Then there is the case of multi-threaded and/or parallel applications, which can add a whole other world of hurt when it comes to manual memory management.

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.

Sure, C++ can be less error prone than C. But you're still responsible for the memory management, and memory mismanagement is still a leading source of bugs and vulnerability in applications that use non-managed memory.

It is possible to write leak-resistant (even leak-free) code. It just takes some attention to detail.

No one is saying it isn't, but it takes time and effort to do so. In some cases, a lot of effort. You have to weigh the costs vs. the benefits for your particular application.

But at that point, you have a deterministic 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.

Unless you are the ONLY software running on a system using a basic CPU your program is NOT deterministic. Modern CPUs do all sorts of crazy branch predictions and caching. Modern OS's do all kinds of scheduling and process manipulation. You can take an average but ultimately you are at the mercy of the CPU and OS.

If your using auto-gc languages for the correct domain, then the garbage collecting should have minimal to zero impact on your performance. If you actually know how to write code efficiently in a gc language, then you can reduce it even further. But that requires knowledge about how gc based languages work AND that you're using them in the right domain.

Not every application requires rocketing speed, and not every development project has the budget or schedule to hire a crack team of C/C++ programmers to write "perfect" code that's 100% cross-platform. You use the best tools for the job.

Of course, if all you have is a hammer then I guess everything looks like a nail.

Re:!Good

[Xyrus]

And memory leaks.

Re:!Good

[toriver]

Then write it in C and use "native" in Java to hook to it then. You sound like a C zombie walking around chanting" poooointers..." as if that is the be-all and end-all of language tools.

Java is intended for expressing higher-level problems than C is suited for. As soon as you start writing malloc() and free() calls you are not focusing on the customer's problem but focusing on the computer. But the computer should not be important.

Re:!Good

[tomhudson]

Stack unwinding FTW. It just works!

The problem is that Javanistas will point to their 2,000,000 line program and say "your 200,000 line program is a toy", not realizing that they do less in 2,000,000 lines of code.

Java - the refuge of the "cut-n-paste" BASIC programmer.

Re:!Good

[tomhudson]

No, you have 6 small functions, and the representation of each light is only 2 bytes of light state and time for the pair of lights, and 2 function pointers - one to the current state of the lights going north-south, and one for the current state of the lights going east-west.

On a 16-bit platform, those 2 pointers take a total of 4 bytes, so (2 bytes state + 4 bytes for 2 pointers) * 10,000 = 60,000 bytes.

That leaves just over 5,000 bytes for your libs (a stripped-down c lib can be under 3k since you're not doing any printf, etc.) and code.

The code to byte-shift, as well as increment the counter, can easily fit in 2k - it's just 3 functions - redlight(), yellowlight(), greenlight(). That's why you have the function pointer table. And why the code modifies the jump table when the timer is done for each light, rather than going through a switch statement. This way, you have just one if (++v > max v=base+ptr_size), or something along those lines, to switch the pointer.

So why wouldn't it fit into 64k again?

Now an external process can modify the contents of the polled memory to signal a change to any of the timers, and you're done.

Re:!Good

[tomhudson]

As soon as you start writing malloc() and free() calls you are not focusing on the customer's problem but focusing on the computer. But the computer should not be important.

Is it possible that as soon as you get a language so convoluted that the vast majority of the programmers using it *need* an IDE as a crutch, you've lost the ability to focus on the problem because you're battling the underlying complexity of your design environment?

Re:!Good

[obarthelemy]

Imagine the real-life scenario: you don't have to scale that much, say up to 20 servers. Very few apps actually run on more than that. Factor in the extra costs of buying and running those extra servers.

Now, Imagine indeed switching languague/platforms, buying fewer servers, but having to hire more expensive talent, and more of it.

You need a whole lot of servers before talent comes out less expensive than hardware.

Re:!Good

[obarthelemy]

At one point in your life, you'll realize that maintainability > performance 99.9% of the time.

Re:!Good

[guruevi]

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.

Try ObjectiveC. Works very similar to what you're describing. You have objects with their own memory control passing messages or objects with automatic reference counting and automatic (or manual if you're masochistic) cleanup once you're done.

Re:!Good

[tomhudson]

The talent only needs to do the implementation once - then it can be extended or maintained by lesser luminaries. Contrast that to the extra servers, which will only grow with time because you use bloatware, and are a continuous cost.

Also, the more bloated the code, the less likely it is to be reused, since everyone figures "I can do better than that." And the more bloated the code, the more of a maintenance nightmare it becomes. Both of these also increase your costs - and software maintenance is 90% of your software cost already - a small investment on the front end pays off bigger dividends on the back end.

Just saying - Java has introduced several false economies. A decade ago, it was much easier to find programmers who knew how to manage memory - it was something that you could assume any competent programmer could do. Today? We're back to 1980s-type BASIC skills.

This is not a good thing for the industry, long-term.

Re:!Good

[rtfa-troll]

I'm not going to argue against your comment overall. I agree with the general gist that using a higher level language is often going to be a good strategy. However:

If object oriented languages introduce more complexity into an application, then why would anyone use them?

There are so many good and obvious answers to this that it just isn't an argument

1. because the people deciding are often managers who don't have a clue
2. because they don't know any better. They only know .Net/Java.
3. because, by the time they realise they made a mistake it's too late
4. etc.

The fact is that most software is probably written in Java/.Net nowadays, but most successful software is not. I'm not sure that's because Java is bad, but I guess that it's a sign that someone who thinks to use something different is normally someone who's thinking about the problem properly.

Any software engineer or programmer worth their salt will tell you that you always use the appropriate tool for the job at hand.

again; I agree with your sentiment. However, the "job at hand" for most programmers is normally maintaining something that's already written. That means that "the appropriate tool for the job" is normally the language that the system is already written in.

Re:!Good

[Spewns]

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.

Re:!Good

[16K Ram Pack]

It's very rare that I have to optimise for performance nowadays. I'm not talking about the sensible stuff like putting indexes on tables, but the post-implementation bottlenecks that required you to play around with say, how you were storing data in memory in a program.

That said, I'm going to offload some XML processing needed for my 1st Android development to the server (both for processing speed and to reduce the size of the data packets).

Re:!Good

[chaboud]

Those combined makes for a programming environment that is harder than the average code jockey can comprehend.

This, to me, seems to be a problem with the average code jockey (and what we're willing to accept). We seem to be quite a bit off of the beaten path, though, as this relates to dalvik and java, but I'm happy to run with it.

Those of us who can handle C++ and the trade-off in ease for the performance benefits find that C++ approaches to resource management flow fairly easily. Those who can't handle it will continue to view the trade-off as too great and use other languages.

There are some programmers who will never really properly understand threading and how to craft efficient, well-organized threaded code. For others, it's a fairly approachable problem, and well worth it.

Re:!Good

[ToasterMonkey]

Call me back when your operating system is written in Java. Oh wait, Sun tried that - another failure.

You're an idiot.

Re:!Good

[chaboud]

I've found that coders who have experience handling resource management can easily adjust to garbage-collected environments, but the opposite is rarely true.

Besides, being aware of resource management can afford for quite a bit of room for performance considerations that would otherwise be out of reach in more automatic environments. As coders, the ability to be considerate of allocation is still a relevant ability. It's one that I think we should all have.

Re:!Good

[gabebear]

Java, because you can't use pointer arithmetic, is going to be slower than the same code in c using pointer arithmetic, because a non-pointer solution is always going to be slower, in any language, even c.

That sounds like a stupid blanket statement... Back it up with some numbers.

Re:!Good

[obarthelemy]

I have several issues with what you're saying.

1- You seem to think less qualified people can easily update and extend code that would have been too hard for them to think up in the first place. I'm doubtful.

2- To me, bloatware is software that has too many features, not fat code. Fat code is kinda bad, but not as bad as unmaintainable code.

3- I'm not sure re-use rate for code people don't feel confident they can understand, edit, maintain, is going to be much better than for so-so code they feel more confident with ?

4- Ten years ago, there were much fewer programmers, working on much fewer programs with much smaller feature sets on much fewer platforms. It's like saying 50 years ago, airplane pilots knew how to care for and fix their airplanes, not just fly them, and with much assistance. Yes, things have moved ahead since then. Your point is ?

Re:!Good

[tomhudson]

1- You seem to think less qualified people can easily update and extend code that would have been too hard for them to think up in the first place. I'm doubtful.

When someone else has done the hard work, it makes it easier for everyone else who follows to extend it, esp. if they use good variable names, etc. There's a lot less work, for example, in adding one more parameter to a thread structure than in writing the original thread-handling code.

3- I'm not sure re-use rate for code people don't feel confident they can understand, edit, maintain, is going to be much better than for so-so code they feel more confident with ?

Then maybe either someone else should be looking at the code (not all coders are equal), or better yet, managers should acknowledge that people shouldn't just be expected to quickly modify code with stuff that "looks right, hopefully it won't blow up in a month". Of the two, I'd say the latter is the best solution, the one that programmers would prefer, but also the less likely of the two. We both know why ...

4- Ten years ago, there were much fewer programmers, working on much fewer programs with much smaller feature sets on much fewer platforms. It's like saying 50 years ago, airplane pilots knew how to care for and fix their airplanes, not just fly them, and with much assistance. Yes, things have moved ahead since then. Your point is ?

Operating systems were a lot simpler 10 years ago as well. You don't see them shifting to "managed code" for their cores. The performance just isn't there. Even the JVM is written in c, and the Java spec has gotten a LOT bigger.

If the developers of Java had admitted early on that their approach was off on a few things (no macro pre-processor, no first-class functions, no pointer math, single class inheritance, the option to allow the coder to manage memory, everythingIsAClassItis) we wouldn't be having this discussion. It *could* have even been a "better c++". It would have been relatively easy to offer both an interpreted and an emit native binary code option. It would even have been easier to link java object code with c++ code.

Chalk it up to another missed opportunity. The industry is full of them. Much as I've tried countless times over the years to like Java, for me it just combines the worst of all worlds.

Re:!Good

[dgatwood]

I find that garbage collection actually reduces maintainability significantly. Instead of having well defined points where objects are disposed of (which you can find with a simple grep), you now have objects disappearing (or not disappearing) magically, seemingly at random, whenever any of a million variables gets changed. It's like the difference between counting the number of people on a train and counting the number of people in a city park. The more places people can get in or out, the more intractable the problem.

When GC fails to do the right thing (and it inevitably does if your program gets complex enough) and you end up with a colossal memory leak or an entire object subgraph suddenly disappearing because one piece of code inadvertently used a weak reference where it should have used a strong one, you now have a nightmarishly hard-to-find bug on your hands that makes maintaining manually memory-managed code seem positively simple by comparison.

I've maintained large projects with both GC and manually memory managed schemes. I'll never write a large piece of code in a garbage collected language again except by force. Garbage collection may take away the need to spend extra effort on managing memory in the simple cases, but it takes away control and ease of debugging in the complex cases. In the long run, all successful software becomes complex. Thus in terms of long-term maintenance, garbage collection will always eventually come back to bite you on the rear.

Re:!Good

[pankajmay]

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.

It is so fashionable to berate C++ and reduce it to a glamorous bloated superset. I take exception to your statement, because I usually think people who say this have never been familiar with C++ and its standard libraries.

C++ has a lot of features that make it far more object oriented than C even when you follow paradigms like RAII -- especially relevant to this thread of discussion is that did you know that you can override new and delete operators in C++ and mitigate a lot of problems being discussed here?

Personally a lot of issues arise with strictly imperative/procedural thinking in programming, because it is not exactly amenable to solving all the problems - resource management, freeing up memory pointers, responsibility delegation are just a few issues that are overly complex with imperative paradigms.

Functional programming excels at a lot of issues here -- passing generalized functions to algorithms really solves a lot of issues. And C++ addresses it more effectively than C.

However, C++ does a clumsy job of it and the constructs are so numerous with sideeffects that warrant spending considerable time looking them up. But the fact is that they are there -- which places the language apart from C.

Re:!Good

[DurendalMac]

I don't know why, but that has me giggling endlessly, maybe because BASIC on the Apple IIgs was my first programming language...

Re:!Good

[tomhudson]

In my day to day, methodX is often written by one of my coworkers a hour before I need to use it

Sounds like a formula for generating LOTS of bug fix work, unless they write perfect code the first time out every time. but hey, it it keeps you employed :-)

Of course, if the code is just mostly cut-n-paste with a variable name changed, you have a bigger problem on your hands. But that will also guarantee future employment managing all those lines of code.

Or maybe you simplified it, and they really did test it properly, knew how you were going to use it, etc. This is not to say that IDEs are bad in and of themselves, but that they do tend to get people to think less about the "why" of the code they write, and more about just cranking out lines.

Re:!Good

[Rockoon]

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?

Re:!Good

[SpaghettiPattern]

Java's dying anyway.

Lad, you're completely bonkers. The statement you made clearly shows you haven't got the slightest idea how much Java code there is inside corporate data centres. I've been told COBOL is dead since 20 years and it's still alive and kickin'.

Hardly any language truly dies. For instance, C was considered for business applications and got dumped for that purpose. It's still very much alive.Java will be there longer than you hold for possible.

Re:!Good

[ultranova]

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?

BASIC is low level. The original linenumber-BASIC with GOTO as flow control is pretty much exact fit to assembly with some command renames (GOTO rather than jmp, etc).

Re:!Good

[tomhudson]

Things are in one of 4 states:

1. growing
2. stagnant
3. dying
4. dead

Java is dying. This does not mean that fewer people are using it - the decline will be long, just as it was for COBOL. But it IS past it's peak, simply because it's so bloated that, like the dinosaurs, it can't maneuver as quickly. It's no longer the "cool kid on the block." It's become boring.

It doesn't help that both Sun and Oracle hindered the development of more flexible alternative. Java could have been MUCH better.

Just adding multiple inheritance would have avoided a lot of the current bloat. And not restricting it to "everything is a class", but rather "classes if necessary, but not necessarily classes", would have taken away 90% of the beefs I have with it.

Why do people feel that these two things are such a threat? Or such a "bad thing"? We criticize c++ devs who go class-crazy .. (been there, done that, learned my lesson :-). And multiple inheritance - everyone can use a friend (class) or two.

It's not like I'm asking for operator overloading (though Java DOES overload the "+" operator, so it can be done).

And enums would be nice (though I obtain the same effect by using the c pre-processor when I do write java code, just like I get back my #include and #define - maybe I should write a custom pre-processor that would give me everything I want, fork the java library, and call it good. After all, as long as it's not java, what can Oracle say? :-).

Re:!Good

[badkarmadayaccount]

HW accelarated GC can wipe the floor with the most annaly tuned C app.

Re:!Good

[badkarmadayaccount]

Ever tried to make performance sensitive MThreaded systems under high load? I dare you to build one in ANSI C!

Re:!Good

[tomhudson]

You won't get an argument from me on that score. Too bad you posted anonymously, because what you said is VERY true.

"Thinking time" for a programmer is devalued, even though even carpenters know "measure twice, cut once" saves time and money, and field engineers know to ask the advice of the tradespeople when looking over the blueprints.

But when it comes to building code, it's a different story. Instead, it's "do this - this shouldn't take more than %arbitrary_time minutes" - sure, but you can only get away with that for so long before your code looks as unplanned as it is.

So you end up with undocumented code ("you'll have time to do the documentation later"), code that has corner-cases that are untested, code that duplicates functionality because it's quicker to cut-n-paste to get the boss off your back than it is to try to generalize a block of code for re-use, etc.

OOP was supposed to fix that. When it's not over-used it's great. But of course, like everything else, "if a little is good, a lot must be better."

And putting more priority on adding features, even while the current features don't work right and the code needs a good scrubbing, or worse, "selling the prototype" .. not good.

It's sad.

Re:!Good

[SpaghettiPattern]

Java is dying. This does not mean that fewer people are using it - the decline will be long

Sure. And I've been in the dying status since birth.

It's no longer the "cool kid on the block." It's become boring.

And thanks god for that. Indeed, 10-15 years ago you were considered almost eccentric for using it but nowadays no longer.

I'm in the business of integrating systems and my clients are large institutions with architecture teams that mostly pose restrictions on what you're allowed to do and what not. (Restrictions people might find silly are almost always there for a reason.)

I almost always can use Java and Tomcat to do the job. Almost any API you can think of is around and I don't need to take into consideration the platform I'm running. I always can meet the architectural restrictions. I also can hand over a Java system to a maintenance team and move on. There are loads of Java programmers and they come relatively cheap.
From my applicative and/or utilitarian point of view there's very little that beats this.

Perl -NOTE, I'm a Perl author on CPAN- is OK for slightly complex system stuff but I'd never ever build a system again where I'd have to provide modules from CPAN. OS update will break some code eventually. Migrating to another OS is a nightmare. Sure I get paid for doing these kinds of things but there's more interesting work around. And, if you think Java is old, you'll think Perl has already snuffed it.

C++ is excellent if you intend on never to migrate to a different platform. For my purposes it is hell.

The "newer" kids on the block will not be considered by most of my customers.

You might argue that this converges to undesired and dangerous monoculture but it's too easy criticism. Successful languages depend on businesses willing to use it. One day something truly revolutionary will come along, businesses will start using it and I'll move to it. Don't forget that in the 80ies and mid 90ies the alternatives were fewer than today. Back then we were heading away from COBOL towards C -I mourn the poor beggars that had to implement business applications in C- and now we're heading away from COBOL towards Java.

Re:!Good

[tomhudson]

HW accelarated (sic) GC can wipe the floor with the most annaly (sic) tuned C app.

Garbage collection is for people who need a safety net.

Smart pointers are the usual means for c++ programmers to "manage garbage collection", but they're not the optimal solution, in part because they're not actually smart (circular references, etc., so you no need weak smart pointers, blah blah blah).

Smart|weak pointers are not needed. Proper design spells out who allocates what, who owns it, and who frees it. Anything else is laziness on the part of the programmer, or a response to management's insistence on not allowing enough "thinking time" in the process.

So, with no garbage collection and no reference counting overhead, where's c's disadvantage? Right, there is none.

Re:!Good

[tomhudson]

Ever tried to make performance sensitive MThreaded systems under high load? I dare you to build one in ANSI C!

Yes - 1000 connections a second, running for months at a time, 400 threads launched at startup, none EVER killed to reclaim memory (unlike most servers) because we wanted to avoid the overhead of killing threads and spawning new ones. The boxes it ran on were old 800mhz dual-core BSD with 2 gig. They were tested and ran fine on newer boxes with a half-gig of ram (though they've been upgraded in the last year to 2ghz/16gig ram during a change of co-lo because it's cheap, so why not?).

A second one, 100 threads at startup, same deal except that it could expand the thread pool as required without limit. Again, no respawning of threads to claim back leaking memory.

It's possible to write leak-proof c/c++ code, without smart pointers or reference counting or resorting to killing off threads to "fix" a memory leak.

Third one, same deal as the second. They all talk to each other, two of them talk to the outside world, and everything is hunky-dory. To the rest of the world, they look like ordinary web servers (until you try to look at the server signature - there is none). They load their modules at start time (each one has a different set of modules), and do things like parse out and generate xml, combine queries from multiple sources so that they can hit the database with one big query instead of hundreds of smaller ones, then split the results back to the individual threads as required - saves a LOT of overhead.

All 3, plus the db, on that same lowly 800mhz dual-core.

So yes, it's possible, and I've already done it. No need to dare me.

Re:!Good

[tomhudson]

I'd like to see the"something newer." Java should have been it, but it was crippled from the get-go because Sun wanted control. Picture java with multiple inheritance, operator overloading (java already overloads all the math operators, so why can't we?), naked structs and enums (we can manage our own "primitives", honest!), and a pre-procesor. A "better c++".

We don't need everything to be a class or wrapped in a class.

Re:!Good

[dup_account]

Nothing like finding a boundary case and using it to declare the norm...

I know everyone who isn't developing OS's or whatever are morons, but in reality, most people have never, and will never run into what you are talking about.

You should be advocating something like Actors or such as the proper solution for 99.9999% of development.

I know I worked on a mission critical, realtime, multithread system, in C. And we didn't use any dynamic allocation. Everything was predeclared arrays. And why? Because it avoided all the BS that you are promoting. Rather than showing how 1337 we were, we used a simple model that was super easy to manage. So eat that.

Re:!Good

[dup_account]

Oh, I forgot... Learn how things, like SunSpot, actually work before you poo poo them. There are cases where it's statistical optimization kicks other environment's ass. But that's no fun, now is it? Oh yeh, if you don't like the syntax of Java, use something like Groovy, Scala, or whatever. Get the best of both worlds :)

Re:!Good

[dup_account]

Wow, you must write really bad code if the garbage collector can't keep track of what you are doing.... You should probably re-analyze your architecture.

Re:!Good

[tomhudson]

Great. What I think the javanistas don't get is that I'm NOT advocating switching everything away from java, but rather fixing the problems with the language. Sun made some serious mistakes in keeping it so locked in for so long. Top of the list would be to add multiple inheritance and get rid of interfaces (cue the "OMG BURN THE EVIL CLUELESS B*TCH" crowd).

Re:!Good

[badkarmadayaccount]

free() still has overhead. It needs to be handled in the same thread, usually. On high load SMP systems, this is unacceptable. GC CPU overhead is a few %, usually, and can be separated in its own thread[s]. The mutator thread use all their CPU time productively. Smart|weak pointers are usually a half assed tool set build your own in app GC, or at least attempt to. But they are in no way representative of modern GC tech. Maintainability in multithreaded enviroments suffers, and I won't even talk about cross-process shared memory objects.
Did I mention that a typing system is also for people who need safety nets, same goes for control structures and code separation into functions. So what's ASMs' disadvantage? Right, there is none.

Re:!Good

[badkarmadayaccount]

Sorry about that, but that requires a modicum of skill, which you apparently have, but sadly, that doesn't apply to most developers. Keep up the good work!

Re:!Good

[tomhudson]

Your comments point out one of the advantages of using c instead of c++ (or using c++ but not always creating objects to encapsulate code and data). Allocate a chunk of ram (enough for your data) in one shot, and whenever you need a new data structure, just stick it somewhere in there and point to the head. It makes for a much quicker "fake tree" than actually allocating objects to represent each node, and you don't ever have to free anything until you exit the program, then you just free that one memory structure. Need to grow it past your existing boundary? You can either use an array approach (allocate another chunk for another 100 data structs) or realloc (or realloc, and if it fails to grow the chunk because of fragmentation, then fall back to the array approach).

That's a lot quicker than the usual approach of creating objects for each node (and it makes it a lot quicker to do a search on un-indexed data)

All that being said, I think that people are missing the real point - Java can and should be improved. The original concept was good, but the implementation was always uninspiring. There were some design mistakes that "looked good at the time", but single inheritance was a serious blunder. Sun kept everything so "don't you dare fork this" that nobody came up with a proper mechanism for multiple inheritance. Just like it would be nice to have structs (so we can define our own "primitive data types" if we want and get the same performance advantage as with Java primitives), and, seeing as how Sun overloaded all the mathematical operators anyway (they work on both primitive types and objects, and + also works on strings), why can't we be trusted with the same ability? We're not dummies.

They could have called it Java++ or Java.NET or J# or JavaXT or JavaNG or Java 2.0 or Mocha or Avaj or Squirrel (squirrels like Oak), or whatever, and it would have been a much more flexible, expressive language. Then you wouldn't have me PMSing about it :-)

Re:!Good

[tomhudson]

When I first attacked the problem, I had never written threaded c code before, and never written network code, nor had I used the c api with mysql. However, I knew that, given a few days, I'd get the hang of it - after all, it's all written with a certain logic behind it, so there are only a few ways it COULD work, and knowing the theory behind it all, it wasn't that hard.

I would say that those developers who would sink in such a problem could still be trusted with an improved Java, one that is more expressive. Give us multiple inheritance, structs and typedefs so we can make our own primitives, and (since Sun overloaded the math operators anyway so they work on both primitives and objects) operator overloading.

Sure, some programmers will screw it up, but most won't. And we won't have the inevitable code bloat from single inheritance and the need to wrap everything into the current Java model.

Is that too much to ask? Don't Java programmers deserve the best language possible? Wouldn't it be nice not to have me ranting about it? :-)

I'm not the enemy here. Sun messed up. Ever since Java first came out, I *wanted* it to succeed - but it's not done right. It suffers from a restrictive programming model, a too-rigid, artificially constrained class hierarchy, and the whole "lets bolt on some more sh*te in the next release so we have something else to talk about."

Will I use Java. Sure. Do I want it to be better? Of course. Do I think Oracle is right? Absolutely not. Java needs a fork - badly. And not dalvik. Dalvik doesn't attack the real issues - what was a great idea needs to be scrubbed down, stripped to its core, reinforced with new ways of doing things, and then make its way into the world as what it could have been.

Re:!Good

[SpaghettiPattern]

Picture java with multiple inheritance, operator overloading (java already overloads all the math operators, so why can't we?), naked structs and enums (we can manage our own "primitives", honest!), and a pre-procesor. A "better c++".

Coming from Perl where you had to grow your own OO, multiple inheritance has been the thing I missed. Not too much, but still missed it. Time passed, my brain grew a bit older and I realised to my horror that some application programmers simply never will grasp the practical side of inheritance -let alone multiple inheritance- but will arrive in influential positions. In a way it's a blessing that specifically to these idiots multiple inheritance isn't available.

Then came the shifting away from inheritance and towards interfaces and delegation. My only objection to delegation is that when you have large amounts of methods the code bloats and you get into maintenance hell.

I can do without overloading operators, enums and structs. Sure, I'd like -for instance- a Perl-like pattern matching. But I'm perfectly OK with writing a bit of extra code which will be intelligible by mortals.

The spooky thing is that I and many others almost have surrendered to a technology that does 80% of what's desired.

Re:!Good

[tomhudson]

I don't use operator overloading that much - mostly ++, --, + and -. They're a syntactic sugar that makes code pretty easy to understand, and it would be nice to have them in all languages.

There are definitely people who will never understand inheritance unless it involves a dead body and a will. And then there are those who think that everything has to be a derived class - they don't grok aggregation - what can you do? People are, for the most part, human.

Re:!Good

[lucian1900]

Java is indeed badly placed abstraction-level wise. It's too high-level to make stuff fast, but also to inflexible to make stuff easy. Python + C has worked very well for me (and others). Ruby/Lua/etc. have similar recommendations.

Loss of confidence

[Duncan J Murray]

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?

Re:Loss of confidence

[The Snowman]

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.

No, we are seeing a loss of confidence in Oracle. Unfortunately, Oracle now owns Java. That means its future is a little foggy. Oracle has a serious hard-on for Java, which you can see because it is the only major database I know of that allows you to use Java in place of PL/SQL. Disclaimer: I haven't actually done this, but I did read about it while googling some issues I was having with an Oracle database.

So where to next?

I think there is room for two cross-platform environments such as .NET and Java. Right now, those are the players. I don't see the F/OSS community putting all their eggs in Microsoft's basket, even if people do use Mono to some extent. If Oracle succeeds in making Java their pool boy and effectively neutering OSS implementations of the language and JFC, another environment will need to rise to to the occasion. I think it would be a community effort to some degree, but driven largely by Google. I could see them forking Java and realizing that due to trademark and patent concerns they would need to make large changes, so they would make major changes, add a bunch of stuff, and turn it into one hell of a platform for mobile and network development. That was Java's original goal, but it has since bloated up well beyond that and I do mean bloat, not grow. Why do we need a total of three implementations of core JFC classes to do stuff like "read a JPEG," and two of them either don't work at all or only work if you drink unicorn blood while coding? Why are there two GUI implementations, and the one that makes sense is still a zombie built on top of decaying pieces of the AWT corpse?

Sun had so many opportunities to grow the JFC, add value, etc. but due to their intense fear of breaking backwards compatibility, they just layered more and more band-aids and duct tape on top of each other. At some point you need to do it right with new implementations and say "upgrade to version X, and deprecated crap is being removed. You are now warned."

Also, Java EE needs to be merged into Java SE. There should be two Javas. One for memory-constrained devices (embedded), and one for everywhere else. Java EE has been a pain in my ass for some time. Java doesn't need the extra complexity.

Re:Loss of confidence

[Haxamanish]

Oracle has a serious hard-on for Java, which you can see because it is the only major database I know of that allows you to use Java in place of PL/SQL.

Most databases have similar features, for example Sybase ASE & PostgreSQL.

Re:Loss of confidence

[pionzypher]

Trying not to be alarmist as this looks like a pretty specific case and while Sun was content to look the other way while Oracle isn't. It probably wouldn't hurt to discuss possible ports/alternatives. OO has always been more than good enough and the ubiquity given by java meant no gtk/qt squabbles. How would things go if Oracle decided to stop spending any resources on it? The license is LGPL. What about patents/CRs? Could someone fork oo or re-implement in another language without legally running afoul?

And no, being a corner case myself; google docs is not the answer.

Re:Loss of confidence

[TheRaven64]

Ximian, now Novell, did fork OO.o. You can get their fork at http://www.go-oo.org/. The only reason that Sun maintained control over OO.o was that they provided most of the code. Last statistics I saw for OO.o contributions were around 80% Sun, 15% Novell, 5% everyone else. If Oracle doesn't keep up the contribution rate, then other forks will overtake theirs and be regarded as the main version. A lot of Linux distributions already include the Novell fork, rather than the main branch, as their OpenOffice.org package.

Re:Loss of confidence

[pionzypher]

Good info, thanks all for clearing that up for me.

Re:Loss of confidence

[thePowerOfGrayskull]

We are? What are the indications? The fact that Google has been sued for making a Java implementation that does not conform to the Java specification, and yet continues to call it Java?

It'll probably get me modded down, but I don't see this as a Bad Thing. When it comes to core Java systems (excluding GUI) it *is* write once run anywhere as long as you use the standard packages. Not only will it run on any JVM, it will also run in a predictable manner on any JVM (and I think this is one place where Google changes things - the behavior at execution time in some cases). I don't want a trusted vendor such as Google pushing a JVM implementation that is not compliant, yet still continuing to call it Java. Right now, when someone applies for a job as a senior Java developer, everyone knows what it means. When the JVM implementation is no longer standardized, developers start learning implementations instead of the platform -- quite possibly without knowing it.

If use a Java syntax with a custom JVM but called it something other than Java, I don't think Oracle would have complained.

Re:Loss of confidence

[gbjbaanb]

they just layered more and more band-aids and duct tape on top of each other.

I think you're giving the argument why there's a general loss of confidence in Java. Google could (and probably will)
  do a lot better with a language that looks "quite a lot like" Java, yet isn't, in much the same way Microsoft did with C#. I'll be happy to see Java die off and be replaced with better. My biggest problem is that there will be several 'evolutionary' new languages instead of 1, but then, at the moment proprietary lock-in seems to be back with us again.

Re:Loss of confidence

[Anonymous Coward]

Where have the ever called it Java?
The platform isn't called Java, the VM isn't called Java, and the language only says "Java like".

Re:Loss of confidence

[thePowerOfGrayskull]

http://developer.android.com/guide/topics/fundamentals.html

Re:Loss of confidence

[Anonymous Coward]

Java the programming language =/= Java the platform. A Java platform can attempt to run Java bytecode, which Dalvik can't. If you can't see the difference, then I question your status as a programmer. It's like saying a C language implementation that compiles to interpreted bytecode for a video game is equivalent to C itself.

Re:Loss of confidence

[jonadab]

> much like the loss of confidence in mono

To my knowledge, there was only really ever one person who had confidence in Mono in the first place, and that was the lead developer. Nobody rational ever wanted anything to do with that nightmare. Embrace Microsoft's proprietary design, be extended into incompatibility at their whim, and get extinguished whenever they feel like it? No thanks.

Mono is a classic textbook example of "solution in search of a problem". Everything *useful* that .Net provides was already present several years earlier in other open-source development platforms. The *only* things that .Net ever offered us were lock-in and integration (with Microsoft's platform strategy), and if we wanted those things we'd be using Microsoft's own implementation, not Mono.

The patent problems are just the gravy on the cake. The real issue with Mono is that we Do Not Want It.

Re:Loss of confidence

[mehemiah]

If that expires, there's KOffice. One day Nokia will actually invest in a linux mobile platform. On that day, they'll port KOffice to a mobile platform.

Re:Loss of confidence

[jeffmen44]

So where to next?

I don't understand why Parrot (www.parrot.org) has not gained more traction yet. It's a vm specifically designed for dynamic languages.

The project seem quite active, it looks like the perfect alternative to all these copyright-ridden platform.

Re:Loss of confidence

[Bazouel]

Depending on your definition of what is a "major" database, you may want to add PostgreSQL to your list.

From their site (http://www.postgresql.org/about/)

"PostgreSQL runs stored procedures in more than a dozen programming languages, including Java, Perl, Python, Ruby, Tcl, C/C++, and its own PL/pgSQL, which is similar to Oracle's PL/SQL. Included with its standard function library are hundreds of built-in functions that range from basic math and string operations to cryptography and Oracle compatibility. Triggers and stored procedures can be written in C and loaded into the database as a library, allowing great flexibility in extending its capabilities. Similarly, PostgreSQL includes a framework that allows developers to define and create their own custom data types along with supporting functions and operators that define their behavior. As a result, a host of advanced data types have been created that range from geometric and spatial primitives to network addresses to even ISBN/ISSN (International Standard Book Number/International Standard Serial Number) data types, all of which can be optionally added to the system."

Re:Loss of confidence

[slack_justyb]

Absolutely correct. Java still has a few advantages over dotNET within the FOSS community. Neither platform is without some darksides but I would hope that everyone was waking up and understanding that nothing is without a darkside (glibc?). That being said, Java has fallen into the hands of a bunch of pricks known as Oracle. I think we all pinned it correctly when everyone said that Java was being handed over to the only other company that makes MS look good, The other being Apple (that's right I said it! Apple is pure evil, they make Satan look like the f'ing Pope!)

At any rate, Oracle could, most likely, screw us all for future versions of Java and start suing the pants off the OpenJDK community at any given time. The only safety net that we've got is that Sun GPL a lot of code and we can fall back to that. MS hasn't released a single thread open or GPL a single thing. There's nothing to fall back on if MS should screw their promise. However, Oracle is most likely to take a scorched Earth approach when it comes to lawsuits. So as we may have some safety net with Java, will pay for that safety by dealing with one of the most insane companies on Earth, aside from Monsanto, Haliburton and Apple (yeah I really hate Apple that much).

So I wouldn't be sitting there saying Mono is safe. It's not, but maybe the benefits out weigh the risk. Maybe not.
That's not to say Java is safe either. It's in the hands of a bunch of assholes right now but you do get some GPL protection. Maybe that's worth something to you, maybe not.

Either way you slice it we're all screwed might as well use Python.

Re:Loss of confidence

[g4b]

they make Satan look like the [...] Pope!

"Fry, because of this joke, the pope has to be a major movie star and beauty model since 2142."

Re:Loss of confidence

[The Snowman]

they just layered more and more band-aids and duct tape on top of each other.

I think you're giving the argument why there's a general loss of confidence in Java. Google could (and probably will) do a lot better with a language that looks "quite a lot like" Java, yet isn't, in much the same way Microsoft did with C#. I'll be happy to see Java die off and be replaced with better. My biggest problem is that there will be several 'evolutionary' new languages instead of 1, but then, at the moment proprietary lock-in seems to be back with us again.

I agree, I think one of the best things for Java would be for Oracle to drive it into the ground while Google or someone else creates a Java-alike language. Ideally it would get rid of a lot of the baggage that Java has been carrying around for more than ten years, while adding new, good features like I know Google would.

Re:Loss of confidence

[The Snowman]

Depending on your definition of what is a "major" database, you may want to add PostgreSQL to your list.

Thanks. I have several databases installed and I use them, but I'm not much of a DBA. I just use them for tables, and I write SQL (or I don't, and use an ORM library). Regardless, my original statement of how Oracle has wood for Java still holds. They seem to be betting their future on integrating it into their products and services. Hell, they bought Sun, a broken husk of a company, for way too much money just to own Java.

Re:Loss of confidence

[The Snowman]

I feel dirty for saying it, but I trust Microsoft more than Oracle. Oracle pretends to be your friend, then backstabs you and leaves you with a huge bill. You already know Microsoft is out to get you.

Lately, I think Microsoft is actually producing better software, too. SQL Server has increased tremendously, Visual Studio is top-notch, Windows 7 I hear is very good, etc. Sure, Office (especially Outlook) is ugly and has warts, but overall, they're doing better than they were ten years ago.

I installed Oracle on my system at work to use for development. A single database instance consumes 250MB of RAM. Seriously? SQL Server takes a quarter of that and doesn't impact performance much. SQL Server is able to comprehend that it is on a development machine, not a server. Oracle immediately goes into "rape the computer" mode as soon as it installs. It is almost as evil as SAP.

Re:Loss of confidence

[gtall]

Oracle may have a stiffy for Java but it hasn't helped their applications. I have to use one of those bastard children of King Larry at work. There are error messages that make no sense to earthlings, error messages where there are no errors, fields that make no sense. Oracle wants to be producer of business software. Fine, it helps if you actually understand how to build user interfaces that are not fetid piles of steaming dingo kidneys. And it also helps if the back end is properly threaded so changes in one place get properly riffled through to the rest of the system.

Best thing for us is for Oracle shoot itself in the head and disband the alleged company.

Re:Loss of confidence

[a.damnjan]

DB2 and Informix also allow for Java stored procedures.

Re:Can't they technically fork it?

[The Snowman]

I mean, they (Sun) open-sourced a huge chunk of it did they not?

It might mean having to remake some of the libraries, but hey, anything away from Oracles grip, right?
As great as they are with their services, they can be complete asses at times.

Sun did open source Java, and did wind up rewriting some of the native libraries to make it possible. What would happen, however, is renaming it due to trademarks now owned by Oracle. That brings up questions such as would Google need to rename portions of the code, such as package names? The entire JFC exists in the java.* and javax.* packages. What about the sun.* classes that are used under the covers? Those would be easier, since developers aren't supposed to use them directly.

I think "open source Java" is a reality, but forking the project is not as easy as it sounds.

I'm glad

[airfoobar]

The similarity of android's dev language with Java is only superficial. It's not really Java by a long way.

Now that Oracle's Java is showing its true colours and proving it's not really open source, I see no reason for Google (or any other company that backs open source) to support it.

This will lead to Java's death, and that's a good thing because it's WAY over-due.

Re:I'm glad

[leenks]

I've never got the whole "death to java" thing - can you explain why you think its demise is way over due?

Re:I'm glad

[Billly Gates]

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.

Re:I'm glad

[FuckingNickName]

So was it a good thing or a bad thing when Microsoft did a Google (or rather...) with their version of Java?

Re:I'm glad

[TheRaven64]

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?

Re:I'm glad

[Joce640k]

There's nothing inherently wrong with Java

So where are all the desktop applications...?

Re:I'm glad

[ChunderDownunder]

Think in-house corporate applications all over the world. Do a job search for 'swing'.

Re:I'm glad

[airfoobar]

What I want doesn't really matter. The fact is, Java is a very ugly programming language that has been chopped up, extended, distended, designed, redesigned and bloated over the many years it's been around... I'm by no means a Microsoft fanboi, but even C# is a nicer language to use, though tbh not that much nicer. What we need is a new standard, hopefully one that is really open source and comes with no strings attached.

Re:I'm glad

[tomhath]

Java isn't a bad language. Sun couldn't decide what it should be used for (embedded? servlet? applet? desktop? enterprise?). It eventually became the enterprise programming language of choice, but that makes it unsuitable for its original purpose as an embedded language, or pretty much anything else for that matter. Everything about Java is very, very heavy weight - platform, process, skill set, everything.

Re:I'm glad

[nurb432]

It wont actually die, it will just become an in-house language for oracle application development.

Re:I'm glad

[dmesg0]

... It's been (mumble) years now but I'm still not using a single Java application for anything important (I think I've only ever installed one Java program on my machine), and neither is anybody else I know.

I'm not using motorcycles and neither is anybody else I know. Does it mean motorcycles are dead?

(Sorry for the car analogy)

Re:I'm glad

[icebraining]

You can use the JVM with other languages... Scala, Groovy, Clojure, Python, Ruby and more.

"Java" doesn't mean only the language, there's also the platform.

Re:I'm glad

[airfoobar]

Don't get me started on the platform.

Re:I'm glad

[JamesP]

Java's death means .NET and Windows in the server arena. Do you really want that?

BS

Still, less servers? Less people using Java?! TOUGH for Oracle.

Which portals?! Which apps?!

This is truly horrible and no php or perl can not just replace it for mission critical servers

True. But a mix of tech can. I just hope we don't have to go back to C++

Re:I'm glad

[John Hasler]

Oracle is sueing for patent infringement, not trademark infringement.

Re:I'm glad

[gabebear]

Most of Oracle's desktop tools were already Java before this purchase. I also use JEdit and Vuze regularly.

Re:I'm glad

[rxan]

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.

Re:I'm glad

[thePowerOfGrayskull]

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.

Re:I'm glad

[ScrewMaster]

Don't get me started on the platform.

Okay, I'm game. What's wrong with the platform?

Re:I'm glad

[hedwards]

Just because it's not the greatest language doesn't mean there's something wrong with it. Java does what it was designed to do quite well, it's just that any time you do cross platform via a virtual machine you're going to have to give up a bit in terms of performance, which is why developers avoid it when they can. However that's a bit like saying that a motorcycle is pointless because you can't drive from Burbank to Honolulu.

Re:I'm glad

[bill_mcgonigle]

It's funny how Java and dalvik are more compatible than different vendors' implementations of C++ when I was in college. Heck, even C or Pascal in the 80's.

Re:I'm glad

[squiggleslash]

It would've been incredibly irresponsible of Oracle to allow Google to create a wholly incompatible "Java" under the Java name

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.

Re:I'm glad

[jojo78]

In summary, open source Java is fine, open source almost-Java is not.

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?

Re:I'm glad

[jojo78]

Opps; forgot to add that those are two posts from you on this.

Re:I'm glad

[hedwards]

Umm, dude, they already are doing it. Android uses .dex files which won't run on the standard runtime environment and it won't run the standard class files which all the other platforms support. Yet they claim that the applications are programmed using the Java programming language

Perhaps if you did some research you'd see what the problem is. You can't claim to allow use of the Java programming language and not follow the rules of the company that owns the rights to it. Google borrowed the trademark and the code and failed to live up to the agreement, I'm not sure how this could possibly be grey area.

Re:I'm glad

[squiggleslash]

Umm, dude, they already are doing it. Windows uses .exe files which won't run on the Unix environment and it won't run the standard Unix ELF and a.out files which all the other Unix platforms support. Yet they claim that the applications are programmed using the C programming language

Your point being what exactly?

You program Android applications in the Java programming language. That doesn't make it a Java platform. And if you meant to imply that every implementation of the Java language has been designed to compile into J2 bytecode running on a JVM, then you should look up J# and GCJ, which compile to CLR and CPU code respectively. (GCJ offers the option of compiling to J2 bytecode, but it can also compile to CPU code.) Neither are "Java platforms", although GCJ can form part of one, if anyone ever finishes GNU Classpath.

Re:I'm glad

[toriver]

Okay, I'm game. What's wrong with the platform?

Perhaps he prefers register-based VMs over stack-based ones and mistakenly thinks that has to be his religion?

Re:I'm glad

[Bent Mind]

It would've been incredibly irresponsible of Oracle to allow Google to create a wholly incompatible "Java" under the Java name. ... this is more like horning in on somebody else's trademark

This is the part I really don't understand. My understanding, and I could be wrong, is that Oracle is going after Google for patent, not trademark violations. From what I can see, this has nothing to do with any trademarks being used inappropriately. Rather, it has to do with Google implementing a solution based on the published Java specifications. I haven't read the license that those specifications are published under. However, I'd guess that they do not grant license to freely use the specifications to generate code that could compete with Java.

So I'm not sure where all the discussion about trademark violation is coming from. Did Oracle claim trademark, as well as patent, violations? As to the future viability of Java, I'm not sure that any of this will really have an impact. So far, it only seems to matter if you want to reimplement Java. You can make the case that several embedded device manufactures do want to reimpliment Java, because of hardware limitations. It will certainly impact those interests. It may come about that those interests will create the next popular language that meets their needs, rather than use Java. However, I do not see it having an impact on Java, where it is commonly used today.

A little off topic, but I do find the cell-phone environment interesting. Everybody seems to want to exclude cell-phones from general computing. It is fascinating to watch all of these big companies fighting over who can do what on these little devices. It is very similar to the way modern warfare works. Everybody is afraid of the big patent war, much like the cold war's nukes. However, the players still want to test out their war-craft. So they pick small targets (cell phones or 3rd world countries) to do their battle.

Re:I'm glad

[Blakey Rat]

Java's death means .NET and Windows in the server arena. Do you really want that?

I hate to break this to you, but they're already in there.

You are right, however, that Java is basically the biggest threat to aspx/.net and Windows in the enterprise space right now.

Re:I'm glad

[Dog-Cow]

This is wrong in so many little ways.

Re:I'm glad

[TheRaven64]

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.

Re:I'm glad

[mjwx]

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.

Because no one would use JavaME for Android when Dalvik is faster and better supported. Secondly, Oracle dont want to do that as they would give up their chance to demand a piece of a very lucrative Android pie that Google is making. Oracle does not want to kill Android or Dalvik, they want to monetise Java and you cant do that when no one is using it so they are trying to put just enough fear into everyone else that they'll pay up without a fight.

Good idea from an evil corporation POV, but Ellison is a moron for going after Google first. Better targets without the will to fight that would help "legitimise" (sarcastic air quotes) future claims.

Re:I'm glad

[QuantumBeep]

Javascript, not Java.

Unintended consequences

[k2r]

> Java's death means .NET and Windows in the server arena.

That's an interesting theory and I agree with it.
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 .NET/Windows on the long run to avoid Java?

Re:Can't they technically fork it?

[TheRaven64]

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.

Java won't die anytime soon.

[Pawnn]

It's still huge in Big Business, where COBOL also remains alive and well.

From what I've seen, it's still largely popular as a web application language for the server-side. Usually an alternative to .NET.

Re:Java won't die anytime soon.

[tomhudson]

Not for long - by 2020 it will be the New COBOL.

Php became the #1 web server language in 2002 - and that hasn't changed since, and isn't likely to. Most web sites don't use jsp/struts/spring/jsf

We call it a LAMP (or WAMP) stack for a reason.

Re:Java won't die anytime soon.

[DragonWriter]

Php became the #1 web server language in 2002 [lwn.net] - and that hasn't changed since, and isn't likely to.

The article you link says it became the number one server side scripting language in 2002. While there isn't a really clear boundary of what is and isn't a "scripting" language, Java isn't included in any of the definitions generally used for that category, so in a discussion of Java, PHP's position among "scripting" languages -- server side or otherwise -- is pretty much irrelevant.

Re:Java won't die anytime soon.

[thePowerOfGrayskull]

This was a great troll - I almost fell for it :D

Re:Java won't die anytime soon.

[tomhudson]

Java is an interpreted scripting language. It's also nowhere near number one - most hosting providers don't even offer it.

And before we get into *that* argument again ... Java is no more compiled than converting a word doc to a pdf is "compiling" it. You cannot execute the resulting class files directly - they need to be interpreted by the run-time (originally, they were supposed to be interpreted by a special "Java chip" - "write once, run anywhere" was the exact opposite of the original design goals).

If Sun had had any brains, they would have fixed the slowness of Java by including the ability to compile down to native code. Then they could have arguably had the best of both worlds.

But what do you expect from a project that changed its goals so many times, even in the early years?

Re:Java won't die anytime soon.

[TheTrueScotsman]

Yea, and I don't see Cobol vanishing either (we used to joke about this in the 80s for god's sake).

You really don't have a clue about Java and where it's used. You've got kind of a 90s mindset stuck in the marketing speak of 'Java taking over the desktop' and 'write once run anywhere'.

Well, it didn't take over the desktop; but it did take over the server. Java is huge in corporate environments (not rinky-dinky mom-and-pop stuff php stuff) and is essentially de rigueur in any banking, media or business information back-ends or middleware.

It actually does fulfill the 'write once, run anywhere' promise perfectly, as long as we're talking about the two dominant OSes in current business environments: Linux and Windows Server 2003/2008 (the only two that matter, surely). Due to the excellent JVM, it regularly hits C-like speeds (although I must admit memory usage can somewhat larger than C).

Currently I'm writing Java software which handles hundreds of separate disk partitions to synthesize a file system totalling several hundred TB. It also issues parallel programming jobs onto hundred of servers. The nuances of jsp/struts/spring/jsf (does anyone still use that stuff?) don't really seem so important.

Re:Java won't die anytime soon.

[rsborg]

The article you link says it became the number one server side scripting language in 2002.

Most of the times J2EE involves using JSP, the Java scripting equivalent of PHP. I've worked on many Java environments in the enterprise, and I've never seen a Java web server without JSP of some sort. PHP displacing JSP and ASP speaks volumes... I doubt those environments are replacing their JSP/Java with PHP/Java.

Re:Java won't die anytime soon.

[tomhudson]

Well, it didn't take over the desktop; but it did take over the server

The servers that it did take over are now directly threatened (as are the database servers that they communicate with via java) by map-reduce and nosql. Much more scalable, no dependence on Oracle for anything, runs fine on commodity hardware, much easier to synchronize as well as build in transaction isolation and rollback.

10 years. That's an eternity in internet time, but not in human time, and the continued growth of data stores and rising energy costs make it not only possible, but inevitable.

Re:Java won't die anytime soon.

[Glock27]

Java is an interpreted scripting language. It's also nowhere near number one - most hosting providers don't even offer it.

And before we get into *that* argument again ... Java is no more compiled than converting a word doc to a pdf is "compiling" it.

Java source is compiled to either native object format, or bytecode. The Gnu gcj compiler is an example of a "native" Java compiler. There are also a few commercial compilers that do the same thing.

You cannot execute the resulting class files directly - they need to be interpreted by the run-time (originally, they were supposed to be interpreted by a special "Java chip" - "write once, run anywhere" was the exact opposite of the original design goals).

You should explain why the original versions of Java had a VM, and why the "Java chip" never went anywhere (hint: there were implementations, but they didn't really offer anything compelling).

If Sun had had any brains, they would have fixed the slowness of Java by including the ability to compile down to native code. Then they could have arguably had the best of both worlds.

I guess you're too uninformed to know that one of the big reasons gcj hasn't taken off, is because the HotSpot type VMs outperform it a lot of the time? If native compilation were that great, some of the other Java entities might be more interested in it.

There really are optimization opportunities that are better exploited at runtime.

But what do you expect from a project that changed its goals so many times, even in the early years?

I'd say rather that Java has attempted to become a general purpose language, which implicitly means it has many goals. How well it's accomplished that is of course arguable.

It has been the most successful and important language in recent years though, without a doubt. C# is a fine example of "imitation is the sincerest form of flattery".

There are valid criticisms of Java, for instance it's hard to make a small implementation given some of the dependencies of Object and Exception, but your criticisms don't fall into the "valid" category.

Re:Java won't die anytime soon.

[tomhudson]

Try again - the JIT has to interpret your class file when it runs it. Java is STILL a scripting language.

Really. Your JIT is not able to run the class file directly either, btw. Yes, after it interprets it, it saves a copy to cache, but that's it. The JIT STILL has to interpret your class file first.

1970 called, They want you to go back in time and learn how to read.

Re:Java won't die anytime soon.

[Belial6]

The fact that compiled code can be run in an interpreted emulator doesn't mean that it isn't compiled. The JVM is an emulator, just as Vice, Snes9x, and MAME are emulators. Throwing some enterprise speak at it doesn't change what it fundamentally is.

Yes, Sun hoped they could get everyone moved to their processor. Yes, they had a very good plan on how to pull it off. The plan? Get past the software library/user count chicken and egg problem by writing emulators for every platform. This way developers would write software for it given that every user is a potential customer. Then when they got critical mass, they could release their native processor and pull everyone over. The fatal flaws in that plan was that the emulators were terribly incompatible. There was no reference design to point to so that when they behaved differently from each other, one could point to the reference and say that if it didn't behave like that, it was wrong. And the biggest flaw was that the Java processor couldn't run native Java code as fast as an x86 emulator could emulate it. It would be much like trying to compare a C64 to Vice. The real hardware would be hopelessly out paced by a modern x86 machine emulating it.

The definition of 'scripting language' is pretty much pointless. It is like trying to define 'crappy music'. What the definition is, and what specific instances falls into it change from person to person. There are many instances that the vast majority of people agree on, but even then you will get some people coming out of the woodwork to argue it. You claiming that Java is a scripting language being a very good example.

Re:Java won't die anytime soon.

[toriver]

For a long-running Java program, 99% of the time is spent running native code (JIT compilation leads to native code in case you has misunderstood something.) Compile-ahead and Just-in-time are just different times that translation to native happens. Do you really think that JIT is a slow process?

Re:Java won't die anytime soon.

[tomhudson]

Not quite ... from the description>:

Compiled applications are linked with the GCJ runtime, libgcj, which provides the core class libraries, a garbage collector, and a bytecode interpreter

In other words, it's still interpreted at runtime. Your class files weren't magically compiled at "compile time" to native code. It's the same as old dBase apps that you could make into executables via a compile step - it didn't compile the .dbo file, but rather bundled a copy of the dbase runtime with your code, then set the runtime's start point to the first line of your code.

Re:Java won't die anytime soon.

[toriver]

Running Java in a current VM: the bytecodes are translated into native code by Hotspot (or JRockit) and the native code is what is actually running. But unlike traditional "pre"-compilation the translation happens at runtime because that is when you have the necessary information about that particular computer, thus making it more likely the native code can be optimized.

"Sun hoped they could get everyone moved to their processor."

"Their" processor is the SPARC, the Java bytecode CPU was just a toy.

Re:Java won't die anytime soon.

[node 3]

Java is an interpreted scripting language.

Wow, your ignorance of Java is astonishing.

Java is no more compiled than converting a word doc to a pdf is "compiling" it. You cannot execute the resulting class files directly

It's compiled for the virtual machine. Your choice of PDF as an example is rather interesting. Had you instead chosen PostScript, you'd have had greybeards provide countless counterexamples.

But no matter how you want to look at it, it's absurd to maintain that Java isn't compiled.

Re:Java won't die anytime soon.

[sadboyzz]

From http://gcc.gnu.org/java/

GCJ is a portable, optimizing, ahead-of-time compiler for the Java Programming Language. It can compile Java source code to Java bytecode (class files) or directly to native machine code, and Java bytecode to native machine code.

And why do people get so emotional about programming languages?

Re:Java won't die anytime soon.

[node 3]

Try again - the JIT has to interpret your class file when it runs it. Java is STILL a scripting language.

Interpreted/scripting is going from a high-level language to machine code each and every time it runs. Java bytecode is neither a scripting language, nor is it a high-level language.

By your logic, C is a scripting language. Or running non-native binaries (such as PPC programs on an Intel Mac via Rosetta, running Windows programs via Wine on Linux, or even using a DirectX to OpenGL translation layer to port a game from Windows) is interpreted and/or scripting.

Google for "javac". You might learn something.

Re:Java won't die anytime soon.

[KarmaMB84]

Java is a compiled into an intermediate form just like any other compiled language. The key difference is the JIT transforms it into native code at runtime rather than an additional compilation stage translating the intermediate form produced by a C or C++ compiler into native code.

Re:Java won't die anytime soon.

[tomhudson]

I know that the JIT caches native opcodes. However, this also often prevents your code from fitting into the L1 cache, so it's going to run slower. After all, the JIT still has to do a lookup into it's own opcode cache each time. It's not magic pixie dust.

Its the same reason there's an optimum size for a disk cache, and making it too big results in slower, not faster, operation. So even long-running processes might have to dump some of the cached opcodes if they want to keep the cache size reasonable.

Throw in the garbage collector, which also isn't as free as unwinding the stack, and you're always going to have a penalty at some point.

Re:Java won't die anytime soon.

[tomhudson]

Java is interpreted by the JIT, which has to first compile it. That makes Java an interpreted language. Or did you forget about the JIT? The just-in-time compiler. It compiles your script ... oops "compiled" class file.

Your "class" file is not compiled code, or you wouldn't need a JIT.

Re:Java won't die anytime soon.

[tomhudson]

I'd agree with you that running a binary on a non-native platform via an emulator is the semantic equivalent of scripting - in both cases, the output has to be passed through an interpreter, and this brings along all the problems of any interpreter.

That being the case, what's your point again? Java is interpreted at runtime, the same as any scripting language, the same as a non-native binary. Neither the non-native binary nor java class files are compiled for the platform. They both are just sources of bytes for the interpreter. Neither one is "compiled" as far as the platform is concerned.

Re:Java won't die anytime soon.

[tomhudson]

And that intermediate form still requires interpretation. The .class file is no more "compiled" for the host platform than the original .java files were.

Call it what you want, but don't call it compiled - even the JIT is a just-in-time compiler - so the source .class files obviously aren't compiled.

Re:Java won't die anytime soon.

[tomhudson]

Most php code can be translated into c, then compiled into a native loadable module, and the footprint is pretty small. If you really need to, you can also port the code into it's on server process and have it process requests at native code speeds - no php run-time library required, just a bunch of c statements. You simply can't do that with java. You'll always have more overhead, even if you make your app into a java server.

Re:Java won't die anytime soon.

[Belial6]

Yes, current Java VMs are JIT emulators. Sun implemented that soon after the retro console scene showed how well it worked with console emulators. I don't know if you are trying to claim (or not) that Java isn't compiled because they used enterprise speak and called their machine code (you know the code that a machine understands that is frequently divided up into one byte segments, each defining an action for the hardware) byte code. Or, if you making the argument that because a JIT emulator has been created, that the code that still would run just fine in a non-JIT emulator somehow stops being compiled. If you are making that argument, you are wrong, and confused by enterprise speak.

"Their" processor is the SPARC, the Java bytecode CPU was just a toy.

Any processor they make is "Their" processor. Your 'toy' comment is reminiscent of comments made by the CEO of DEC concerning PCs not long before their fall. It is ridiculous.

Re:Java won't die anytime soon.

[Abcd1234]

Wow, you didn't even bother to read the rest of the fucking *sentence*, did you? Here, let's quote the whole thing:

Compiled applications are linked with the GCJ runtime, libgcj, which provides the core class libraries, a garbage collector, and a bytecode interpreter. libgcj can dynamically load and interpret class files, resulting in mixed compiled/interpreted applications.

So why do they include an "interpreter"? Because then your *compiled* Java application can dynamically load and call into traditional bytecode that wasn't compiled with gcj (eg, libraries in JARs, etc). But the application itself is very much a compiled, binary program, just like any other executable.

Re:Java won't die anytime soon.

[Belial6]

JIT is a specific technique used in emulators. Java bytecode will work just fine in a non-JIT Java VM. In fact it wasn't until the video game console emulators started using JIT in their emulators that Sun started using it in Java. Before you can use your class, you must run your source through a compiler. That would be javac. the 'c' stands for 'compiler'.

Of course, the whole argument is ridiculous because all a compiler does is rearrange code to a format that can be better understood. What this means is that whether something is 'compiled' (better described as run native) or interpreted is not an attribute of the code itself, but of the environment that it is run in any specific instance. A processor could be made that ran GW-Basic code directly, and a compiler could be written that compiled 6502 Machine code into GW-Basic. That wouldn't change the nature of 6502 Machine code or GW-Basic.

Your "class" file is not compiled code, or you wouldn't need a JIT.

To be clear. your "class" file does NOT need a JIT enabled emulator. JIT was added to the Java emulator well after it's release.

Re:Java won't die anytime soon.

[tomhudson]

Of course, the whole argument is ridiculous because all a compiler does is rearrange code to a format that can be better understood

Javac never produces object code that can be run on any target cpu. Hence it is not a compiler.

A real compiler replaces source code instructions with assembly language for the host platform. The linker then takes the object files and links them together with your startup library, which is more object code, and patches the result so that the first instruction that is executed after your startup lib initialization is main().

Sure, the class files don't need a JIT, but they do need an interpreter at somepoint after they are loaded in the JVM and before they are run. And to those who try to claim that you can also make a stand-alone executable with gcj, gcj is still not feature-complete - for JDK 1.1 Not even support for the old AWT. And obviously no Swing. So unless you want to relive the glory days of pre-mouse DOS to re-implement obsolete programs, gcj is not going to cut it either.

Re:Java won't die anytime soon.

[toriver]

What is this "JIT emulator" you hamper on about? JIT compilation turns code into native code much like GCC does, except at runtime, in a dynamic way so that it can change the native representation if runtime analysis shows that code flow indicates a different translation would be better. What do you feel is "emulated"? are Perl or Python bytecodes also "emulating" something?

(Are you seriously believing that Sun looked at console emulators? The idea of virtual machines is WAY older than that hobby. Think UCSD p-code that e.g. Microsoft has used, the WAM that was used for Prolog etc. Portability is a far more relevant reason for using a virtual machine than "emulation" of existing CPUs that console emulators focus on.)

One difference to ahead-of-time compilation like you most often use for C/C++ and others is the use of this intermediate representation as byte codes. They are instructions for a virtual stack-based machine, for which there is an implementation that can run (slower) if necessary (since JIT compilation was added later). When running, the generated native code can be better optimized for the actual processor's features instead of assumptions made by a C programmer's architecture settings and other compiler tunings.

And the "toy" comment was because those processors are not exactly going to dominate the market any time soon. After Hotspot and JRockit made JIT-ed code faster they mostly died.

Re:Java won't die anytime soon.

[Mongoose Disciple]

I suspect you don't do a lot of Big Business work. Internal systems for Fortune 500 companies, stuff like that.

The choices there are basically Java or .NET. It's not that people aren't choosing PHP for those kinds of projects, it's that it's never even seriously considered.

Granted, there are a lot of other markets or segments where other technologies are reigning or ascendant. In that space, not so much.

Re:Java won't die anytime soon.

[ToasterMonkey]

Throw in the garbage collector, which also isn't as free as unwinding the stack

malloc/free aren't as free as the stack either, what is your point?
Poo on your stack based programming too, real men don't need stacks, it's much faster that way.

Ok, lets both just sit back in our armchairs and relax bro. Most Java developers at this stage in the game are doing enterprise software development, and the idea of only using the stack makes you sound like a tard.

smaller active resident set size vs. processors designed with more cache
Guess which way the tides are moving?

Re:Java won't die anytime soon.

[Belial6]

Most of your post is simply inherent ranting. The final paragraph though, links to a page showing that Java IS native compiled code. You obviously are either well aware of it, or just linked to things you don't understand. Of course the native processors will not be dominating the market. The x86 can emulate them faster than they can run natively. Sun didn't expect that to be the case when they made Java. The fact that the processors failed in the market don't prove that Java is interpreted by nature, but their existence at all shows exactly the opposite.

Re:Java won't die anytime soon.

[Belial6]

You are wrong. Sun produced processors that ran Java natively. You do NOT need a JVM at all to run Java byte code. You just need one of the processors that the compiled code was designed to run on. The fact that the processor can be emulated faster than the real hardware does not change whether Java is compiled or not.

Re:Java won't die anytime soon.

[tomhudson]

Sun produced processors that ran Java natively.

No, they didn't.

Sun signed licensing deals with other manufacturers to produce "java chips" to run picoJava, not Java. picoJava doesn't pass Sun's own Java conformance tests. Nice try, though. I'll give you 1 point for the attempt, and take away 2 for being wrong with the facts.

Re:Java won't die anytime soon.

[toriver]

*sigh* You are stuck in the past. Yes, Java is compiled, but to keep focusing on the mostly unused processors is counter-productive. Currently the compiled Java code in most cases works as an intermediate form between source and native, like for CLR and other virtual machines.

Where is your documentation that Sun was more inspired by console emulation than other virtual machine science, well known at the time?

Also the is JIT and emulation, but there is no such thing as "JIT emulator" - that would be something that emulates a JIT... the JRE can be coerced into not using JIT and just interpret; for some tasks that has been shown not to impede execution speed in a significant manner since the JIT translation adds a small overhead.

Re:Java won't die anytime soon.

[tomhudson]

You could pick a better metric, like hosting costs paid or requests processed, and Java would come out way significantly ahead of PHP

Dream on. php serves up more page views than java. You might want to try again.

Facebook srve up 1% of all internet traffic, and they use a customized version of php. youtube? No java. Google? Don't make me laugh. Yahoo? Yahoo converted to php years ago.

The fact is that php does scale at least as well as java, and requires less hardware to do it. You just have to know what you're doing.

Also, your argument is the one that is disingenuous. It is not machine code. Even the picojava chip can't execute it directly. It's an intermediate representation of the program. But keep telling yourself that java is the be-all and end-all. It's not. It *could* have been, but between the mistakes in the original design, and Sun's refusal to allow people to ship variants that could have addressed some of those problems, it's not.

This is more a testament to why Sun eventually went bye-bye than it is a criticism of Java per se. The reason that c has so much staying power is two-fold - the committee in charge makes sure that it stays as simple as possible, and anyone is free to add to it. So no such stupidity as "everything is a class." Anyone using c++ learned that is a mistake within a few months - a lesson I learned the hard way back in 1991. Classes when necessary, but not necessarily classes, because theory and practice are not the same.

The other mistakes were the single-inheritance model (really dumb move there - all single-inheritance models end up with either duplicate code or weird work-arounds - or both), and the lack of a pre-processor.

The idea was good. The implementation is flawed. If they had addressed these issues, instead of bolting on more and more garbage to patch over their earlier mistakes, it would be a different story. This was an opportunity lost. Someone else will eventually come up with a better alternative.

Re:Java won't die anytime soon.

[ultranova]

I know that the JIT caches native opcodes. However, this also often prevents your code from fitting into the L1 cache, so it's going to run slower. After all, the JIT still has to do a lookup into it's own opcode cache each time. It's not magic pixie dust.

This is complete rubbish, you know. JIT means that the runtime environment includes a compiler, which complaisn the program to machine code as it is being run. This has disadvantages - the compiler naturally takes some time to run, and increases runtime size - and advantages: the JIT compiler can inline library routines, and profile and recompile performance-critical parts of the program as it's being run. However, the resulting compiled program is no different than if the compilation had been done beforehand; the machine code is simply never saved to a disk.

So no, JIT - of Java or anything else - doesn't cache native opcodes, it compiles parts of the program into native code that can be run without emulation, just like any other compiler. And JIT pretty much is magical pixie dust :). Seriously, try running something like pcsx2 (Playstation 2 emulator) on a modern PC and turning JIT on and off.

Re:Java won't die anytime soon.

[tomhudson]

As I said, and as you quoted:

The JIT still has to do a lookup into it's own opcode cache each time. It's not magic pixie dust.

Frequently-accessed code is optimized. That optimized code is saved - otherwise it would have to be re-interpreted. Where do you think it saves it - in Neverland? You might not call it a cache - yuo may prefer the term lookup table, or whatever. A smarter way to do it would be to replace the un-optimized code directly, but that would lead to problems with size when the optimized version doesn't fit in the same space. It's called caching. It's (part of) what JITs do.

JIT compilers represent a hybrid approach, with translation occurring continuously, as with interpreters, but with caching of translated code to minimize performance degradation. It also offers other advantages over statically compiled code at development time, such as handling of late-bound data types and the ability to enforce security guarantees.

Want to try it without a cache?

Re:Java won't die anytime soon.

[ultranova]

Frequently-accessed code is optimized. That optimized code is saved - otherwise it would have to be re-interpreted. Where do you think it saves it - in Neverland? You might not call it a cache - yuo may prefer the term lookup table, or whatever.

So, do you call the executable file a C++ compiler spits out a cache? What if you run it before it has a chance to leave the disk cache?

A smarter way to do it would be to replace the un-optimized code directly, but that would lead to problems with size when the optimized version doesn't fit in the same space.

Is there a point in storing raw bytecode sequentially? It would make more sense to keep it in a tree - storing each function as a separate leaf, for example - and replace them one by one as the compilation proceeds. In fact, you could keep both the original bytecode and the new compiled version in separate leaves.

Want to try it without a cache?

Want to explain what any of this has to do with your earlier statement:

However, this also often prevents your code from fitting into the L1 cache, so it's going to run slower. After all, the JIT still has to do a lookup into it's own opcode cache each time.

JIT stores the machine code it produces in a continuous memory region, just as if it had been pre-compiled into a file and loaded from there. The only way your statement makes any sense is if you don't understand this, and are imagining some kind of hashtable with virtual machine opcodes as keys and native code snippets as values.

However, your real beef with Java seems to be that it allows normal people to write programs, rather than requiring Manly Men Manually Managing Memory. Oh, and you also think that pointer arithmetic makes algorithms fundamentally different. Troll on, bro :).

Re:Java won't die anytime soon.

[tomhudson]

Memory management is something that can be taught pretty quickly. It boils down to always knowing who owns what, same as the real world.

The reasons why people screw it up are simple -

1. they don't do enough of it to make it second nature, but after a while it's like riding a bicycle.
2. they're rushed to "get it out the door"

That second one applies to more than just memory management - it's the bane of all developers, no matter what your language.

However, my beef with java isn't with memory allocation, but with the way that the language was dumbed down. Every mathematical operator is overloaded in Java, but coders aren't allowed to do the same. Enums and structs are gone, because programmers can't be trusted with them - make them wrap it in an object and and eliminate bugs (didn't work ...) Multiple inheritance was too hard for them to implement, so we got stuck with single inheritance - this is probably my biggest beef.

All these show a disdain for the learning skills of programmers. We're not dummies, and we should be given tools that are MORE, not less, expressive.

Re:Java won't die anytime soon.

[ultranova]

Memory management is something that can be taught pretty quickly. It boils down to always knowing who owns what, same as the real world.

And just like in real world, what is simple in theory can require volumes of legalese, hordes of lawyers, months of time, and a gun-wielding authority to solve in practice ;(.

And that's assuming that the program has been well-defined to start with. Not all of them are, nor can all of them be. Requirements change midway, and maybe what you were doing was experimental to begin with. Maybe the design plan itself was suitably complex for it to be possible for different people to interpret it differently. All of these problems are solvable, but solving them takes time and energy, so why not use a solution that takes care of the problem automatically whenever possible?

they don't do enough of it to make it second nature, but after a while it's like riding a bicycle.

You take off the training wheels, get overconfident, and crash horribly ?-)

Good analogy :).

However, my beef with java isn't with memory allocation, but with the way that the language was dumbed down. Every mathematical operator is overloaded in Java, but coders aren't allowed to do the same.

Operator overloading really isn't feasible unless you add the requirement that every piece of code using a template or other overloadable entity must be recompiled every time said template chances. The alternative might be to solve overloading at runtime, but that of course slows both JIT and interpreter down.

Enums and structs are gone, because programmers can't be trusted with them - make them wrap it in an object and and eliminate bugs (didn't work ...)

Newer Java versions have enums.

All these show a disdain for the learning skills of programmers. We're not dummies, and we should be given tools that are MORE, not less, expressive.

I hate to point this out, but the average programmer is a dummy, and even the non-dummy ones still make stupid mistakes. The world is full of buggy programs that bear testament to this. And most of those bugs have to do with memory management, because it is a simple yet tedious task where any mistake or lapse of attention will likely results in a disaster sooner or later.

Like it or not, there is a reason why managed languages are gaining favour.

Re:Java won't die anytime soon.

[tomhudson]

hordes of lawyers,

lawyers have nothing to do with memory management.

they don't do enough of it to make it second nature, but after a while it's like riding a bicycle.

You take off the training wheels, get overconfident, and crash horribly ?-)

For bicycles, I hadn't ridden on in 2 decades, but I bought one this summer - it was literally "like riding a bicycle", you never forget. And I never had training wheels when I was learning how to ride, so I had plenty of incentive to learn quickly - scraped knees and all.

Operator overloading really isn't feasible unless you add the requirement that every piece of code using a template or other overloadable entity must be recompiled every time said template chances.

You don't use templates to overload operators. It's all resolved at compile time.

I hate to point this out, but the average programmer is a dummy, and even the non-dummy ones still make stupid mistakes. The world is full of buggy programs that bear testament to this. And most of those bugs have to do with memory management, because it is a simple yet tedious task where any mistake or lapse of attention will likely results in a disaster sooner or later. Like it or not, there is a reason why managed languages are gaining favour.

They're gaining in favour with dummies - as your reply points out. Most bugs are not memory allocation - there are plenty of buggy "managed code" programs out there.

Re:Java won't die anytime soon.

[QuantumBeep]

If it runs on a computer, it is compiled eventually. I propose that JIT compilation be considered a "half-way" mark between interpreted code and compiled code.

Re:Java won't die anytime soon.

[tomhudson]

I can buy into that.

Re:Java won't die anytime soon.

[Everything Else Was]

Wow, your ignorance of Java is astonishing.

I think it's not only ignorance, but outright prejudice against Java. Look at her profile.

Re:Can't they technically fork it?

[dna_(c)(tm)(r)]

The entire JFC exists in the java.* and javax.* packages.

JFC is mostly a synonym of Swing. What you mean is that the standard libraries (mostly java.*) and extended libraries (javax.*) can not be expanded by anyone except Oracle/Sun/JCP.

Concerning the sun.* packages: these are VM specific implementations - nobody should be using them directly.

Lose-lose situation

[slasho81]

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?

Re:Lose-lose situation

[jaylen]

While the reputation of Oracle might mean something to yourself, myself or others on slashdot, the average joe on the streets of the world do not give a rats backend as to the "reputation" of Oracle.

All they care about is how well their phones work. Ergo, Oracle has very little to lose, since they already have inhouse lawyers anyway, and potentially something nice to gain; a nice chunk of leverage to be used in discussions with Google.

Re:Lose-lose situation

[tmmagee]

Having a good reputation among the slashdot crowd may be more important than you think. Oracle's name is quickly becoming mud in the minds of of a lot of developers, and while in the short term that may mean little to them, it will probably bite them in the ass down the road. Developers may not make purchasing decisions for the kinds of large companies that purchase Oracle's products, but they make do make technical ones, and they also advise the people who make those purchasing decisions.

Re:Lose-lose situation

[John Hasler]

Can Oracle's reputation get any worse?

Re:Lose-lose situation

[swillden]

While the reputation of Oracle might mean something to yourself, myself or others on slashdot, the average joe on the streets of the world do not give a rats backend as to the "reputation" of Oracle.

All they care about is how well their phones work. Ergo, Oracle has very little to lose, since they already have inhouse lawyers anyway, and potentially something nice to gain; a nice chunk of leverage to be used in discussions with Google.

It's not the risk of pissing of slashdotters that Oracle should be concerned about. It's the possibility of pissing off other major players in the enterprise Java space. Should Google decide to move forward with going their own way with a new Java-like language, that's of moderate concern to Oracle. Should folks like IBM decide to collaborate with Google on that, and should some of the major open source projects that are Java-heavy (e.g. Apache) decide to move as well, Oracle may find itself holding rights in a language that no one else cares about.

All of that assumes that Google et al can work around or invalidate the patents Oracle holds. I'll bet that's not too hard, though. There's very little in Java that's actually novel, so I suspect that it wouldn't be hard to find prior art to invalidate Oracle's patents. Also, if IBM pitches in and brings its patent arsenal into play, Oracle could be forced into giving up its patent claims even without Google having to go to the effort of invalidating them.

Re:Lose-lose situation

[Rockoon]

Having a good reputation among the slashdot crowd may be more important than you think. Oracle's name is quickly becoming mud in the minds of of a lot of developers, and while in the short term that may mean little to them, it will probably bite them in the ass down the road.

Developers dont make decisions about the use of Oracle's money stream products, of which Java is not among them.

Its the IT guys that make those decisions, and they pick Oracle because Oracles solutions are some of the best in the business. Oracle's revenue stream is in the same league as Google, Microsoft, Apple, IBM, Cisco, etc.. not a household name like some of them, but their revenue stream is testimonial to the quality of their products and the loyalty of those who do make purchasing decisions relevant to Oracle.

Oracle did not buy Sun for Java. Java was just a bonus. Sun was a direct competitor with some unique IP in the storage solutions space that Oracle was and will continue to be the #1 player in. You see Sun Server prominent on that products/services page, while Java is relegated to only footnote status in the "Related Technologies" section.

Java is a fine language for what its primarily used for, and Oracle certainly uses a lot of Java code, but they barely marketing Java itself. They couldn't give a rats ass as to what developers feel about Java. They sell solutions, not platforms.

Re:Lose-lose situation

[bill_mcgonigle]

Am I missing some great strategic outcome Oracle is hoping for?

Yes, they need Google patents for their database product to not become obsolete in the next few years. Buying Sun got them two things - a) hardware fast enough to get them over the gap b) leverage for patent cross-licensing agreements.

This is a [software] patent (government) problem.

Re:Lose-lose situation

[hedwards]

As opposed to the guys that developed what is now known as ECMAscript and failed to demand that the various developers purporting to implement it did so in a compatible way? Trust me it's far more harmful for them to allow Google and others to claim to support the Java programming language, and then do so to the most minimalistic extent possible. You can't take class files and run them on Android devices and you can't take .dex files from Android and run them on the standard runtime environments which means that at best you're going to get confusion and splintering.

Ultimately, one of the most damaging things that a platform can suffer is incompatibility and unnecessary complication. While more pronounced in the world of consoles where winners and losers were often times just a function of the quality and ease of access of dev tools, it applies here as well.

Re:Lose-lose situation

[Sir Homer]

The "average Joe" doesn't give a dime to Oracle. It's the IT/software professionals that give millions of dollars of their departmental budgets to Oracle. The kind with an anti-Microsoft slant are even more likely to be doing this.

Ergo, Oracle should be VERY concerned of the opinion on Slashdot.

Re:Lose-lose situation

[firewrought]

[Oracle's] revenue stream is testimonial to the quality of their products.

Technical quality does not equate to market dominance. They may or may not have been ahead of the curve at one time, but now CIO's seem to buy Oracle just because there's a stigma if you don't. That's an effect of market saturation.

What I can say is that, as a developer, Oracle is extremely clunky. Clunky extensions to SQL. Clunky permissions handling. Clunky name resolution. Clunky client installation. Clunky developer/admin tools. Crap loads of painful clunkiness that constantly interrupt real development with unnecessary confusion and complexity.

They couldn't give a rats ass as to what developers feel about Java.

Apparently, they don't give a rat's ass as to what developers feel at all... and that makes Java's future look even bleaker.

Re:Lose-lose situation

[andre1s]

Dah it's called job security :)

Re:Lose-lose situation

[toriver]

That was a lot of "what ifs". Oracle going after Google over Android does not mean a slightest bit for me as a developer in desktop and enterprise Java since we use conforming implementations to run the code. So Oracle are not concerned because Google are not trying to "attack" enterprise or desktop Java which are where IBM et al operate.

Why should Google succeed with a Java alternative more than the existing alternatives (Microsoft's .Net, Ruby/Rails, etc.)? It will just be one more option, and the majority have selected Java or .Net - or both.

Re:Lose-lose situation

[fabs64]

I'm a developer, I've been asked for advice on things like what database to purchase on numerous occasions, I also am obviously involved in discussions like "which databases should we support?". I imagine most developers are the same.

Re:Lose-lose situation

[SolitaryMan]

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?

I don't think Oracle is going to lose any reputation, because the way they are behaving right now is exactly how they have earned their "current" reputation. It is exactly what their shareholders expect of them, so while they do act like jerks, if will be foolish for them to act otherwise.

Well, if Josh Bloch said it...

[wzzzzrd]

Well, if Josh Bloch said it, then it must be true.

No, seriously. Bloch is one of the few smart public figures in Software Development who, like everyone else, sticks to his agenda, but, unlike everyone else, is very open about his agenda. Besides, he's one of the most entertaining public speakers: Example. If you haven't already watched it, you should.

Now, since I did as you told me, gimme teh darn 500$, please.

Re:Can't they technically fork it?

[Anonymous Coward]

> 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.

But its already been done!

[Old-Claimjumper]

The whole point of Microsoft developing .net was Microsoft trying to embrace-extend Java with Microsoft-only bits and Sun suing Microsoft over use of the name
"Java". Microsoft took their marbles and went off to play in their own yard creating .net.

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.

But Java has already been forked into "real-java" vs ".net/mono/etc". If this suit were being done in some dream world where a still-existing Sun were suing Microsoft over the Java-like structure of .net, then I think the perception would be quite different than Oracle vs Google. the real question here is how much control software patents give over a language.

Re:But its already been done!

[Bill, Shooter of Bul]

Yeah, you try suing a company with as large of a patent portfolio as Microsoft over a language. See how well that goes. Google on the other hand, has much less of a history in Programming languages. So any lawsuit is less likely to end up biting them back.

Re:But its already been done!

[thePowerOfGrayskull]

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?

Re:But its already been done!

[squiggleslash]

The part you quote no more suggests that Android is Java than the references to Eclipse in the documentation suggest that Android is Eclipse.

Google are saying that you can use the language part of Java, known as the "Java Language", to develop applications for Android. The issue here is that the same word, Java, is used for both Sun's language and Sun's platform, and you're interpreting the comment as meaning the latter.

Substitute C for Java in the part you quote, and pretend it's Microsoft's documentation, like so:

Windows applications are written in the C programming language. The compiled C code - along with any data and resource files required by the application - is bundled by the InstallShield tool into a Windows installation package, an archive file marked by a .exe suffix.

and you see why the distinction matters. In the above, because "C" and "Unix" are the not the same word, there's no ambiguity.

Now, there are essentially two groups of people, people who run Android, who are never given any impression that Android is a Java platform and would never dream of trying to install a .jar file, and people who develop for it, who will, necessarily, get to the point that they're shipping Dalvik VM bytecode packaged in .apk files, and will be aware that they're programming in the language itself, with only some library functions being the same, who are also aware from the point it matters that Android is not the Java platform.

So who is being fooled here? Is Google really, in any practical way, either convincing, or trying to convince, people that Android is an implementation of the Java platform? You've quoted a sentence that could be read as ambiguous, but given the context, and given that people who read it will also be reading the information Google has provided that makes it clear that Google are only talking about the language, can you see anything that would be read by anyone else that would make them think "Sure, I can write for J2ME and it'll work under Android", or "I have this cool MIDP app, I'll buy an Android phone because I know it'll run it"

I don't think Oracle thinks anyone is under the impression that Android is the Java platform (well, aside from the people who think Mac OS X is a Windows platform, etc), I think this is a basic case of bullying. I think if Oracle was being honest and fair here, they'd ship a JVM for Android. But this is a power game, not a case where they're trying to "protect Java" or anything else.

Re:But its already been done!

[John Hasler]

> So where do you see that they're not calling it Java?

Where do you see that Google is selling anything called Java? A trademark is not a copyright. Oracle would certainly be alleging trademark infringement if they thought that they stood any chance of convincing the court that their trademark was being infringed. As far as I can tell they are not.

Re:But its already been done!

[VGPowerlord]

Google are saying that you can use the language part of Java, known as the "Java Language", to develop applications for Android. The issue here is that the same word, Java, is used for both Sun's language and Sun's platform, and you're interpreting the comment as meaning the latter.

It really depends on how it's interpreted.

At the current moment, there's no way to create an Android application without having Java .class files, because there is no native Android compiler... the one they have converts already-compiled Java .class files into a .dex. Which, unfortunately, trashes the distinction you made, as you're no longer dealing with just the Java platform, but compiled Java language files.

In addition to that the Android SDK requires you to download one or more platform SDKs, which each include a file named android.jar, which contains a bunch of Java class files across several namespaces, including java.lang (the "root" namespace for Java).

Re:But its already been done!

[John Hasler]

None of that matters. Basically, as long as Google is not using the mark "JAVA" to sell anything they are not infringing Oracle's trademark. It's perfectly legal to use someone else's "trademarked" word, as long as you don't confuse the public as to what they are buying or act in a way that would "dilute" the mark.

Re:But its already been done!

[peppepz]

None of that matters. Basically, as long as Google is not using the mark "JAVA" to sell anything they are not infringing Oracle's trademark.

Yes but what about copyright? Google is using APIs and a language developed by (...) Oracle, and their copyright grant explicitly states that clean room implementations are allowed only if they do not constitute either a superset or a subset of the specification. Which is exactly what Google is doing instead.

[Not that I approve Oracle's behaviour, I think they're severely damaging the image of Java with this lawsuit.]

Re:But its already been done!

[TheSunborn]

The state of the law is currently that you can't copyright an api so anyone is free to reimplement the methods in any class library as long as the reimplementation don't include any code from the original implementation. This is also the reason that wine(The implementation of most of the windows api for linux) is legal.

The only way to stop anyone from implementing a specific api is if you have a patent which is needed to do any implementation. This is most likely the reason that Sun is suing for patents, and not copyright. Google have not made any copy of code owed by sun.

Re:But its already been done!

[peppepz]

The state of the law is currently that you can't copyright an api so anyone is free to reimplement the methods in any class library as long as the reimplementation don't include any code from the original implementation.

That's music to my ears.

This is most likely the reason that Sun is suing for patents, and not copyright. Google have not made any copy of code owed by sun.

Are you sure? I hear that Sun is suing for copyright, too. (A source).

Re:But its already been done!

[thePowerOfGrayskull]

Do you think that if Google didn't call this Java (or more accurately market it as being programmable in Java) that Oracle would be suing at all? Similarly if they had a compliant JVM implementation, I suspect we'd see no law suit.

Re:But its already been done!

[TheSunborn]

Hmm, you are right. Oracle are also claiming that Google copied some of their code and included it with Android. But I could not find any description of exactly what code that would be.

Re:I'm glad - jEdit.

[MadMaverick9]

jEdit is one that works well for me ... and I am sure there more java apps.

Re:hippies

[chichilalescu]

hippies happen

For bunnies sakes ...

[jotaeleemeese]

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.

Re:For bunnies sakes ...

[Joce640k]

They're just as likely to be using COBOL but most people regard that as 'dead'.

Re:For bunnies sakes ...

[dargaud]

Do you have a bank account?

Most likely the back office operations are using Java in one way or another.

Yeah, and also the client-side app... which contains very interesting passwords if you decompile it. Like database passwords.

Re:Can't they technically fork it?

[segin]

So wouldn't Google's best option be for them to just implement the missing classes?

Re:Can't they technically fork it?

[naasking]

Dalvik still wouldn't run JVM bytecodes, so I don't think it would a conforming implementation regardless. I haven't read the spec however, so I don't know if the bytecode is specified there or separately.

Re:Only people in small jobs ....

[ScrewMaster]

... keep saying that Java is dying.

People that have not worked in places where millions are handled by the hour should keep their opinions about coporate grade technologies to their good old selves.

Not at all. The promise of Java is that it would be useful in everything from cell phones to set-top boxes to mainframes, and to an extent that has happened (Android runs a form of Java, and so do some set-top-boxes.) But, in the same way the Cobol is dead outside of a few specific (if important) market sectors, Java is likewise being marginalized. That's what usually happens to anyone or anything espousing the mantra of "one-size-fits-all". Now, I don't understand what Oracle's game is, just yet, but I'm guessing it doesn't have much to do with Java running outside their own playpen. In any event, Oracle isn't a particularly nice corporate citizen, so I suspect that whichever way Ellison decides to jump, a lot of people aren't going to like it.

Re:Only people in small jobs ....

[tomhudson]

Java will eventually lose ground there as well for several reasons:

1. energy and speed considerations - runtimes like dalvik offer a 50% speed boost. Native apps offer many times that in some circumstances.
2. bloat management - the cost of bloat is becoming more apparent as Java fails to scale on the developer side because of early design mistakes.
3. heterogenous data - Java doesn't do so well there, with the "there's a class for that" model.

#2 is currently the big issue. Once a Java project passes a certain complexity, any "it's simpler in Java" advantage is lost, and the Java language and development environment become a boat anchor.

Re:Can't they technically fork it?

[stepheneb]

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:

• an alternative open source Java is quite difficult because the of the costs of certification
• use the open source Java codebase for anything else and Oracle can sue you for patent violations
• contributing to Oracle's existing OpenJDK codebase is fine

Yes, you're missing something

[Lysol]

For Slashdot readers this seems to be about Java the language (as created by Sun), Oracle & Google the companies, and Android the 'upstart'. However to Oracle customers (for which there are tons), none of this means anything because they are completely indemnified in anything relating to Java. They (Oracle clients and developers) are also neck deep in Java for many big Oracle products, so why should they care much about Google's Java-like language for a phone? Oracle is big enterprise and its users/developers are behind ERP, sales, db & inventory systems, etc - huge enterprise (not consumer so much) investments. I don't think most people using Oracle products are gonna notice anything unusual going on because this affects Android only - this does not affect Google server products, although if Oracle wins, then what's Google to do with all that Java server code? Anyway, think the Sun/M$ Java shenans that went on a decade ago. I'm sure Oracle is viewing this in a similar way.

Google has the most to loose, obviously. They will either have to obey and license the patents they are infringing on (and possibly change big portions of their code to be compliant) or switch out to a new language.

Re:Python

[xmorg]

Build a browser plugin that runs python and pygame from the server (so users don't have down download anything except the plugin), and lets talk :D

Hey Im totally for it!

Google built VM allegedly infring'g Oracle patents

[mmacdona86]

That's the whole case. There's no Java license or trademark involved.

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.

Troll? Really?

[Abcd1234]

How the hell is the OP a troll? Or did some fucking idiot mod once again misread "troll" as "I don't like what you're saying!"?

Re:Can't they technically fork it?

[PybusJ]

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.

Sorry I let a mod point expire yesterday

[mikestew]

Wish I still had that mod point that expired yesterday so I could counteract the idiot that modded this "troll". I neither agree nor disagree, but this hardly qualifies as trolling.

Re:Can't they technically fork it?

[mehemiah]

That's odd. I'm an open source developer and it makes sense to me. Lets hear RMS's take.

I was confused when they bought Sun...

[Joce640k]

I don't know what they hope to achieve with this but maybe this lawsuit is connected with the purchase, ie. they planned it from the beginning.

Re:Google built VM allegedly infring'g Oracle pate

[Lulu of the Lotus-Ea]

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).

Time to ditch Java (the language)?

[Kensai7]

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.

Re:Time to ditch Java (the language)?

[John Hasler]

After all, what is really important is the JVM and they've already forked that with Dalvik.

That would probably not help with the purported patent infringements.

Re:Time to ditch Java (the language)?

[sproketboy]

LOL how the fuck did this get modded up?

Re:Can't they technically fork it?

[Xyrus]

In essence Google has created, in Orifice's...er...Oracle's eyes, an "almost" Java. An "almost" Java does not enjoy the protections the open Java does, according to them. That means they think they can go after Google for patent infringement.

This "almost" makes sense.

Re:Can't they technically fork it?

[VGPowerlord]

It's all particularly annoying since, post-iPhone, Java ME has slipped into irrelevancy.

That's funny... since RIM uses JavaME in Blackberry, the most widely sold smartphone brand on the market.

GCJ is a joke!

[tomhudson]

Did you bother looking at their FAQ? Obviously not. GCJ DOESN'T WORK.

Their "mostly-completed" target is JDK 1.1 - you know, released February 1997.

No AWT.

No Swing.

Good luck with anyone taking that seriously.

Re:GCJ is a joke!

[Abcd1234]

Ahh, shifting the goalposts when you're wrong... truly the mark of a sophisticated mind.

Re:GCJ is a joke!

[tomhudson]

Ahh, shifting the goalposts when you're wrong... truly the mark of a sophisticated mind.

The AWT was part of the original , very first, public Java release - then called Oak - back in January of 1996. 14 years later, the gcj faq states that gcj still doesn't support the AWT. In other words, gcj doesn't support ANY version of Java. The only "moving of goalposts" is by you. No AWT support means it's not Java, same as if I write a compiler that can only process printf statements, I can't call it a c compiler.

Lying about it when you're caught at being wrong - truly the mark of a Java-damaged mind. You should run your garbage-collector.

Java has its place, but it's not a silver bullet - in fact, it's quite the opposite. It has led to a lost decade in terms of programmers with robust skillsets.

Re:GCJ is a joke!

[Glock27]

GCJ DOESN'T WORK.

Nice job moving the goalposts. I referenced gcj because it's a real, live example of a native Java compiler, and a Gnu project to boot (no pun intended).

gcj ended up being targeted at embedded applications, more or less, as I said above it hasn't competed very well against the Sun/IBM JREs. gcj is robust enough to compile Eclipse though, which is quite a non-trivial Java app. I'd say you should think a bit more before denigrating the hard work of a lot of dedicated people.

I mentioned the availability of commercial native compilers, obviously you didn't look into that. In particular there's Excelsior Jet, which claims to pass the Java 6 compatibility tests.

The point remains, there's nothing preventing Java from being "traditionally compiled", and such compilers are in fact available. They simply don't offer anything highly compelling for most Java users.

Re:GCJ is a joke!

[peppepz]

Apparently, you didn't bother reading that FAQ either, because just a couple of lines after the point you quoted, it clearly says that the FAQ refers to GCC 3.1. We're at 4.5.1 now, and GCJ supports AWT and Swing.

stop lying

[yyxx]

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.

Re:Can't they technically fork it?

[yyxx]

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).

And that means that Apache Harmony almost certainly violates Oracle's patents and can be sued into oblivion at any time.

GCJ is garbage that needs to be collected.

[tomhudson]

I guess you're too uninformed to know that one of the big reasons gcj hasn't taken off, is because the HotSpot type VMs outperform it a lot of the time?

No - the reason GCJ hasn't taken off is because, to date, they're still trying to get a complete implementation of JDK 1.1.

And no AWT, no Swing, etc.

So let's see - liggcj was released in 1999, and here we are more than 10 years later, and they still haven't caught up to JDK 1.1 (1997).

At that rate, you might get to a half-decent release (1.5) sometime around 2150.

Re:GCJ is garbage that needs to be collected.

[peppepz]

GCJ supports most of java 1.5 since version 4.3 (2007).

Re:GCJ is garbage that needs to be collected.

[tomhudson]

Instead of arguing, I'll provide proof. You're welcome to compile the source on your own machine to see that I'm not making things up. Java is SLOOOWWW even on code that it optimizes, because of the inherent overhead.

Real-word benchmark written just for you weekend Javanistas

1. Java is more than 20x slower than c in simple repetitive loops (gee, why didn't it optimize them to be "faster than c"?
2. "compiled" java is even slower - more than 100x slower.
3. The reason they stopped working on gcj is because it doesn't work - I compiled a swing app I wrote that works perfectly - the gcj "compiled" version threw errors with every mouse click.
4. An examination of the gcj "compiled code" shows that it's just a wrapper for the classes - it calls libgcj to interpret them at runtime. It does NOT generate native code.

If you want to use the term "supports" to mean "slow and doesn't work properly", then I guess you could say gcj "supports" java. But don't you think that's pushing it a bit?

Re:GCJ is garbage that needs to be collected.

[peppepz]

1. No, as the answer I posted on your benchmark shows, Java is almost as fast as C in low-level code. Benchmarking high level code would reveal that Java is *faster* in that field.
2. You really must have done something wrong to your GCJ. My gcj-compiled java example runs pretty much at the same speed as the C one.
3. The fact that gcj's standard library is not at par with the Sun one says nothing about the "compilability" of Java code. Perhaps it does show that Java code is easier to write, because IBM and ASF's Java runtime implementations are faring much better.
4. It's not so and I posted a disassembly of the generated code to show you. Perhaps gcj behaves that way if you feed it a .class file instead of a .java source file?

I do acknowledge that GCJ is not the most advanced Java implementation out there, but nobody has ever said that.

Re:GCJ is garbage that needs to be collected.

[tomhudson]

I fed it the source file - don't be silly. gcj 4.4 gives me the crap I wrote about, and as I pointed out, it doesn't support the GUI - every action throws an exception. That certainly is not "supporting java."

Then again, you're running Windows. Maybe it's that good old "write once for each platform" thing, because it sure doesn't work on my linux box.

Again, you only further prove my point - access via java objects sucks. You can get "close" to c performance by using primitives, but then you've eliminated java's overhead for accessing object methods and properties. You can't do that with most java code because most java classes don't have a corresponding "primitive" representation.

So no, higher-level code would run slower in java, because you are stuck at the higher level, when I avoid it. I don't have to wrap everything into classes. Sure, I use classes when necessary, but not necessarily classes. Not when a struct will do. Not when a nice chunk of uninitialized ram will do. Not when some pointer math will solve the problem quickly in one line.

Re:GCJ is garbage that needs to be collected.

[peppepz]

Then again, you're running Windows. Maybe it's that good old "write once for each platform" thing, because it sure doesn't work on my linux box.

No, I'm running Linux. GCJ must have been rewritten and redesigned from scratch between revision 4.4 and 4.5 and changed from a GIJ wrapper to a true compiler.

Again, you only further prove my point - access via java objects sucks. You can get "close" to c performance by using primitives, but then you've eliminated java's overhead for accessing object methods and properties. You can't do that with most java code because most java classes don't have a corresponding "primitive" representation.

Actually, accessing, maintaining and extending classes in Java will be faster and easier than any structure you might call an "object" in C.

So no, higher-level code would run slower in java, because you are stuck at the higher level, when I avoid it.

That's your preference. In Java you can easily invoke C code if you feel you need pointer math.

I don't have to wrap everything into classes.

You wrap everything into functions, because that's how C is designed. Every language invites you to use its native constructs.

Sure, I use classes when necessary, but not necessarily classes. Not when a struct will do.

What's a struct if not a class without methods?

Not when a nice chunk of uninitialized ram will do. Not when some pointer math will solve the problem quickly in one line.

What can you do with pointer math, that can't be done with indexes and arrays? Omitting pointers from the language allows for some optimizations.

Re:GCJ is garbage that needs to be collected.

[tomhudson]

A struct doesn't have the overhead of the virtual method table, for one. For another, I can define a union and access the struct in different ways directly, rather than having to use overloaded getters and setters. These are both ways to deal with data that are just darned convenient at times. It's also a lot easier to clone a struct than to do a deep copy of a class. Also, if I cast the struct, I can extend or shrink it as needed. And structs can hold pointers to functions (and if you remember to have an explicit "this", they can even operate like c++ classes). 99% of the time, this is completely useless, but that 1% makes up for it. And because there's no overhead for method lookup, it's the fastest implementation possible outside of assembler.

I can use c99-style variable arrays, but treat the data as one continuous chunk of memory, and use bsearch do do an almost instantaneous lookup. Much less overhead than a btree or other structure (100,000 lookups per second on a 1-million record dataset on my laptop when I tested it a couple of years ago for a project where even mysql's in-memory tables weren't fast enough).

Sure it requires more planning for things like marking "rows" as being available so that you don't have to dynamically sort, grow, or shrink the data all the time, but that's what finding the fastest solution is about.

Not REALLY "Java" though

[Dr.Dubious DDQ]

Something interesting I've learned since the lawsuit though, is that Dalvik is NOT actually a Java virtual machine. The "Java" code is converted to the native Dalvik bytecode rather than into Java bytecode. Hypothetically, Android could run ANY languages that had a converter, and I think the only reason Java was chosen as the first language to use was to tap the large population of people who are already used to programming for mobile devices running Java ME.

I wouldn't be at all surprised to see, for example, a converter for Googles "Go", or maybe even something that can handle a subset of Python or similarly popular interpreted language popping up as an alternative to writing in Java.

Re:Not REALLY "Java" though

[thePowerOfGrayskull]

Yes, seems to be the case. I'm guessing that they went with the Java syntax, packages et al since Java has some of the largest market share.

Re:Can't they technically fork it?

[segin]

RIM's JavaME implementation is hackish, at best, and even then, you're best off writing "native" BlackBerry code... which is STILL Java. J2ME support only exists in BlackBerry so that they can get away with doing essentially what Google is doing, except the core differences are that:

1. BlackBerry's OS's, at least on ARM-based handsets, the entire native code portion consists solely of the JVM and hardware drivers - all other code and APIs in the OS is Java bytecode and
2. BlackBerry uses Sun's JVM and Java bytecode.
3. Java ME-specific APIs (those not shared with Java SE), IIRC, are all I/O (user (javax.microedition.lcdui), file, network, etc.), are probably just implemented as wrappers to RIM's own Java APIs (net.rim.*)
4. There's more native code in a $5 featurephone or an Android device than in a BlackBerry.

P.S. Yes, RIM's earlier x86 BlackBerry handsets ran native code and had native code interfaces for third party apps, arguably a whole different OS, but those handsets are so old that their relevance is nil.

Loss of confidence in Novell's toxic code

[SgtChaireBourne]

Ximian, now Novell, did fork OO.o...

Microsoft's partner Novell forked the code because they are putting toxic elements that are unacceptable to the community at large. Novell is acting as Microshat's proxy to poison the code pool. They weren't allowed to shit in the core project so they made fork and are polluting that. I would say use at your own risk but by you using it, you make computing worse for the rest of us. So don't use anything from Novell.

Novell is putting one trojan horse after another into their fork on behalf of Microsoft. That's where the docx and vba turds are coming from. Even if only strategy rather than the technical and licensing inferiority are not enough to eschew Novell's fork, OpenDocument Format is the future as are scripting languages Javascript and Python. Upgrading to OpenOffice.org and carrying VBA baggage with just guarantees that the systems are out of date before they are deployed. That goes double for the file format, especially since the public sector around the world has been moving back to open formats and naming OpenDocument Format specifically along with HTML and PDF.

Quantity of work is not the same as quality, and goals and licensing are yet another pair of separate factors.

Re:Is English not your first language?

[mark-t]

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.

Re:Can't they technically fork it?

[PybusJ]

Well the Apache Harmony project have never made a stable release, so they've never got to stage where they have any users to sue[*], and without access to Oracle/Sun's Technology Compatibility Kit they probably won't.

If they could get certified as a conforming implementation then they would covered under the patent grant.

[*] I don't know of anyone actually using Harmony code for real -- apart from Google who use some of the class libraries on Android!

Re:Can't they technically fork it?

[yyxx]

If they could get certified as a conforming implementation then they would covered under the patent grant.

The problem with certification is that Sun/Oracle refuses to let them certify.

so they've never got to stage where they have any users to sue

And that's no coincidence; Sun/Oracle has made sure that the only Java implementation that anybody can use is theirs. That ensures that they stay in control and get licensing revenue from mobile and server implementations.

Re:Can't they technically fork it?

[peppepz]

The full Java SE is not appropriate for a mobile phone, far to heavyweight and full of APIs like the AWT, SWT etc.

The full Java SE ran at full speed on desktop computers that had a fraction of the computational power of today's mobile phones (think about 75 MHz Pentiums with 16 MB RAM). The cheapest smartphone of today could run Java SE with no problems. Except for the fact that many desktop-oriented APIs would make little sense on a phone (e.g. Swing UIs). SWT was never part of Java SE.

Java ME was created in a time when phones had alphanumeric, monochrome displays and CPUs without floating point math, so it was designed with a *very* minimalistic approach. That's why it really sucks for all purposes today.

Is this going to result in yet another VM?

[GWBasic]

So, apparently the backstory of C# / .Net is that Microsoft wanted to add some features to Java that Sun nixed. As a result, we ended up with a VM and language that's Java-like, (C#/.Net) but has some pretty cool features that weren't in Java at the time. These include AppDomains, improved garbage collection, better reflection, multicast events, delegates (similar to function pointers,) foreach (later copied in Java,) support for pointers in "unsafe" code, support for manual memory management, and an ability to directly call lower-level libraries. .Net on Windows even has a very nice ability to consume COM libraries and export itself as a COM library, thus making it very easy to interoperate with legacy systems.

What's my point? Multiple competing VMs are a good thing if the new VMs bring needed features.

Re:Can't they technically fork it?

[PybusJ]

The full Java SE ran at full speed on desktop computers that had a fraction of the computational power of today's mobile phones (think about 75 MHz Pentiums with 16 MB RAM). The cheapest smartphone of today could run Java SE with no problems. Except for the fact that many desktop-oriented APIs would make little sense on a phone (e.g. Swing UIs). SWT was never part of Java SE.

Oops, I did mean Swing rather than SWT.

Don't think "full java" has remained constant though. Java6 wouldn't get out of bed for 16Mb RAM. And remember it was the performance on pre-Ghz machines which gave Java its reputation for being dog slow.

Let me rephrase that - the latest gcj is garbage!

[tomhudson]

I have the latest and greatest c2j, so I "compiled" some of my java code.

I put "compiled" in quotes because a quick look with a hex editor into the resulting a.out shows that it is not "compiled native binary code" - it's a list of my classes, along with the java code that the runtime will further interpret - which the "compiled" code calls when you run it. So you not only don't have a stand-alone binary - you only have a wrapper around the gcj equivalent of java.class files. Same as when, back in the old days, we'd "compile" dbase programs by merging the dbase runtime with our .dbo files. The runtime still interprets them. Changing to Clipper made a huge difference in speed.

Now, back to compatibility - it's STILL garbage. My stupid demo program, which works perfectly when I run the class files, generates LOTS of errors with the c2j version. LOTS. It's garbage, and it's not even "compiled" garbage.

So the next step is to see just how big it would get with static linking.

gcj doesn't like that - it tells me "gcj: Java programs cannot be linked statically". I kind of expected as much, since it's not REALLY putting out native code.

Nice try. A real compiler would have first translated the classes into a series of native function calls, not just served as a wrapper to the java class files. There would have been NO trace of, and no need for, my original class files in a true compiled program. And you'd have the option of statically linking any libs used.

Bottom line: Your buggy "compiled" program is for the birds. It doesn't work! And even if it did, it doesn't really do what you claim it does - it does not produce native binaries. It calls an external library which interprets the code embedded in the file, same as the JVM does.

So, can we stop with the "gcj compiles java programs!" BS?

Re:Google built VM allegedly infring'g Oracle pate

[RocketRabbit]

Splitting that hair mighty thin. Using java at all, whatever they call it, was their main problem.

Re:Can't they technically fork it?

[peppepz]

Don't think "full java" has remained constant though. Java6 wouldn't get out of bed for 16Mb RAM.

But today's cheapest smartphone has 128 MB RAM, which I remember were enough to run Windows XP.

And remember it was the performance on pre-Ghz machines which gave Java its reputation for being dog slow.

An undeserved reputation. I can run Python applications on my 300 MHz smartphone, and Java is orders of magnitude faster than Python. I've never heard anybody lamenting Python's speed. Java does require more RAM tough.

Re:Let me rephrase that - the latest gcj is garbag

[peppepz]

First of all, you CAN statically link gcj programs (with a recent GCJ, 4.2 or later). Just try:
gcj -static-libgcj -o Foo --main=Foo Foo.java
But you will not WANT to do that, as you will lose some features, and obtain a HUGE executable.

On a side note, are you saying that static linking is the only form of compilation? Isn't "linking" a fully separate process from "compilation"?

If you do, then you're implying that 99% of existing code, being dynamically linked, is not compiled. I think my desktop system has less than twenty statically-linked binaries.

Also, static link has some limitations in modern systems. For instance, some pieces of glibc require, even when statically linked, the presence of the dynamic version (of the same release) of the library at runtime.

Re:Can't they technically fork it?

[segin]

I'm guessing that your phone is a Series 60 device. IYDK, Nokia ported Pythong to their Series 60 platform

Let me support your case better: I have a Nokia 6620, that has a 150MHz TI OMAP-1510 ARM-based SoC and it can run Python. I once had a Nokia 6600 (which has a 104MHz ARM9T and discrete motherboard components, not SoC) and it, too, can run Python.

Re:Let me rephrase that - the latest gcj is garbag

[tomhudson]

gcj under linux says you can't. I already tried that. Where do you think I got the error message from?

And no, I'm not saying that static linking is "the only form of compilation." Object code is the result of compilation. Whether you stick it into a lib or link it directly into your executable is irrelevant. I've been doing this for more than a quarter-century - I know the difference.

The only reason they would require the presence of libgcj (and why gcj refuses to statically link) is because it needs the interpreter at runtime; there's no other way to support reflection, for example, because Sun implemented it wrong.

Re:Let me rephrase that - the latest gcj is garbag

[peppepz]

http://gcc.gnu.org/wiki/Statically_linking_libgcj

Re:Let me rephrase that - the latest gcj is garbag

[tomhudson]

Doesn't work. Where do you think I got the instructions from originally? Geez, give it up already.

They abandoned all development on it last year for a reason. It doesn't support swing, and without swing support, it is of limited usefulness in today's world.

Look - I'm not saying that people should abandon Java. I *am* saying that Sun made some serious mistakes in the original design, and then kept everything so locked up that they couldn't be addressed. Java can stand to use a few improvements that would reduce bloat and make it more flexible if it's going to move forward.

Re: Python

[tomhudson]

I don't know why (inertia, I guess), but I usually reach for perl when I have to do some scripting.

So last Thursday, when perl was being its usual self, I decided to use python. Much cleaner code is the end result.

I've always liked python's "indenting counts!" model.