As a Java programmer, I'm used to thinking that there are two kinds of distributions of Java SE. First there is the JRE (Java Runtime Environment), which is the bare-minimum platform distribution of the virtual machine and class library (for the most part), and second, there's the JDK (Java Development Kit) a riff on the age-old standard term-of-art "SDK", where the JDK is a JRE plus common tools. I asked this question in my blog, but since no one reads it, I didn't get too many answers. :) So I'd like to ask the TSS community the same two simple questions:

1. Do you use "JDK" is a common term to describe the JRE + 'standard' tools?
2. Do you expect that you can get a JDK from any vendor, such as IBM, BEA, Sun, Apple?

1 - yes 2 - yes

Yes. But to be more precise, JDK is JRE + JavaC/JavaP for me (I don't use other tools (directly, say, from console), but I guess my IDE use them) No. Why should I think of other verdors if there is Sun? The JDK is free of charge, thats enought to me. I don't meet any other reasons except the price/availability/stability. Sun can give me that. Why would I (a regular developer) use IBM's or BEA's JDKs?

Why would I (a regular developer) use IBM's or BEA's JDKs?

Different JVMs have different properties. I don't know if this is still the case, but IBM's VMs used to have much better performance than Sun's in some cases, so when I was looking at numeric work, I would use IBM's product.

Why would I (a regular developer) use IBM's or BEA's JDKs?

Different JVMs have different properties. I don't know if this is still the case, but IBM's VMs used to have much better performance than Sun's in some cases, so when I was looking at numeric work, I would use IBM's product.

Why only numeric? Don't you want your other stuff to be fast too? :)

Why would I (a regular developer) use IBM's or BEA's JDKs?

Different JVMs have different properties. I don't know if this is still the case, but IBM's VMs used to have much better performance than Sun's in some cases, so when I was looking at numeric work, I would use IBM's product.

Why only numeric? Don't you want your other stuff to be fast too? :)

Well, at the time (years ago) IBM's JDK lagged behind Sun's. I wanted 1.4.x features, but IBM was at 1.3..

Don't forget that the IBM VM is based on J9, so in principle, you get all kinds of fancy stuff like JXE files (a kind of prelinked jars which can just be mem-mapped, allowing way faster class load), ahead of time compilation (AOT), hot code replacement beyond what Sun does, etc.etc...

Why would I (a regular developer) use IBM's or BEA's JDKs?

Different JVMs have different properties. I don't know if this is still the case, but IBM's VMs used to have much better performance than Sun's in some cases, so when I was looking at numeric work, I would use IBM's product.

The section you quoted is asking about a JDK and you respond about the JVM. It doesn't have anything to do with the question.

In addition to noted JDK vendors, I am looking forward the running Apache Symphony runtime + developer kit. How's that progressing? George

George :

In addition to noted JDK vendors, I am looking forward the running Apache Symphony runtime + developer kit. How's that progressing?

George

"Harmony"... Apache Harmony :) It's going well. We do have something called an "HDK", but that's actually a development kit for working in Harmony itself, as it makes it easy to just checkout one module in the classlibrary and work with that. Stay tuned :) geir

Yes and No.

Yes, and yes. (2) is very important for me.

1. Yes. 2. No, I don't expect it. I only expect to get a JDK from Sun. That being said, it's a nice bonus if I can get a JDK for my Mac.

You can get a JDK from a few vendors; currently only those licensed by Sun. Once the JDK is completely opensourced next year, you should be able to get a fully open JDK as well (as long as Sun doesn't overcharge for the TCK...) The vendors I know of who have a licensed JDK, in addition to Sun, are IBM and BEA.

Apple.

1. Probably. I often use the expressions "Sun JRE" and "IBM JRE" since it's the current reality in the world that there's more than one widespread JRE. However, I typically only use Sun JDK for development, so I don't feel the need to qualify it with vendor name. OTOH, if other vendors would ship a JDK equivalent -- complete with rt.jar compiled with debug info + source of classes + java compiler -- I'd expect it should be allowed to be called "IBM JDK" or "FooBar JDK". 2. While I don't really expect it, I'd definitely say vendors should be allowed to create a full JDK. The question of course is what goal would a vendor possibly have with its own JDK? Please don't say "compiling for proprietary extensions in their own JRE" :-)

1. Probably. I often use the expressions "Sun JRE" and "IBM JRE" since it's the current reality in the world that there's more than one widespread JRE. However, I typically only use Sun JDK for development, so I don't feel the need to qualify it with vendor name. OTOH, if other vendors would ship a JDK equivalent -- complete with rt.jar compiled with debug info + source of classes + java compiler -- I'd expect it should be allowed to be called "IBM JDK" or "FooBar JDK".

2. While I don't really expect it, I'd definitely say vendors should be allowed to create a full JDK. The question of course is what goal would a vendor possibly have with its own JDK? Please don't say "compiling for proprietary extensions in their own JRE" :-)

Completeness - Get the JDK from the vendor that you get your JRE, so you can compile and test on the same JRE that you deploy to in production.

Get the JDK from the vendor that you get your JRE, so you can compile and test on the same JRE that you deploy to in production.

If you don't have a JDK from the vendor, you would not be compiling with it, production or otherwise. Why wouldn't you be able to test on a JRE?

Get the JDK from the vendor that you get your JRE, so you can compile and test on the same JRE that you deploy to in production.

If you don't have a JDK from the vendor, you would not be compiling with it, production or otherwise.

Why wouldn't you be able to test on a JRE?

Sorry - I wasn't clear. What I meant was that if you are developing software, and suppose your production JRE is JRockit, you'd probably like to have a JRockit-based JDK on the machine you develop on...

Get the JDK from the vendor that you get your JRE, so you can compile and test on the same JRE that you deploy to in production.

If you don't have a JDK from the vendor, you would not be compiling with it, production or otherwise.

Why wouldn't you be able to test on a JRE?

Sorry - I wasn't clear. What I meant was that if you are developing software, and suppose your production JRE is JRockit, you'd probably like to have a JRockit-based JDK on the machine you develop on...

Is it going to compile the code differently? It seems to me the important thing is that your testing be against the JRockit JRE. I guess I agree with your basic premise, though. In most cases I would prefer to have the JDK at least approved by the vendor even though it goes against the Java ethos.

Is it going to compile the code differently?

Actually, Java compilers don't perform a lot of work at all. The optimize switches have been deprecated for ages (are a no-op in all current java compilers) and optimizations are left to the JIT compiler, which means the runtime environment. So, there is not really a lot of room for Java compilers to do things really differently.

Get the JDK from the vendor that you get your JRE, so you can compile and test on the same JRE that you deploy to in production.

If you don't have a JDK from the vendor, you would not be compiling with it, production or otherwise.

Why wouldn't you be able to test on a JRE?

Sorry - I wasn't clear. What I meant was that if you are developing software, and suppose your production JRE is JRockit, you'd probably like to have a JRockit-based JDK on the machine you develop on...

Is it going to compile the code differently? It seems to me the important thing is that your testing be against the JRockit JRE. I guess I agree with your basic premise, though. In most cases I would prefer to have the JDK at least approved by the vendor even though it goes against the Java ethos.

Well, people choose JDKs for all sorts of reasons, such as performance, stability under their workloads, fancy GC, whatever. I'm familiar with people choosing a VM and sticking with it. Of course, you can get the JDK from Sun, and your JRE of choice, and install both. Seems like a PITA though. geir

Well, people choose JDKs for all sorts of reasons, such as performance, stability under their workloads, fancy GC, whatever. I'm familiar with people choosing a VM and sticking with it.

This is where you are losing me. The VM is associated with the JRE, not the JDK. GC is defined by the JRE. The compiler and associated tools are what your JDK defines.

Of course, you can get the JDK from Sun, and your JRE of choice, and install both.

Seems like a PITA though.

I can't imagine there are a significant number of Java developers that don't have at least one Sun JDK installed. I usually have 6 or so JDKs on a given machine.

yes yes

Interesting. Why do you ask (if I may be so bold)?

so many terms so little time

stork club movie

i do use the term   to  describe JRE + tools

 buffalo freelance website designer