[commit-cp] [bugs #9846] FAQ does not mention that integrating Classpath in Sun's JVM is very hard.

[Patrik Reali]

This mail is an automated notification from the bugs tracker
 of the project: classpath.

/**************************************************************************/
[bugs #9846] Latest Modifications:

Changes by: 
                Patrik Reali <address@hidden>
'Date: 
                Wed 08/04/2004 at 21:06 (GMT)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Fixed
         Assigned to | None                      | patrik_reali
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
Added to the FAQ






/**************************************************************************/
[bugs #9846] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=9846>
Project: classpath
Submitted by: 0
On: Mon 08/02/2004 at 10:20

Category:  None
Severity:  5 - Average
Resolution:  Fixed
Assigned to:  patrik_reali
Status:  Closed
Platform Version:  None


Summary:  FAQ does not mention that integrating Classpath in Sun's JVM is very 
hard.

Original Submission:  I asked a FAQ in IRC, and the answer was non-trivial.
May be it could be added in the FAQ entry of the website.

The question is roughly:
"I wish I could help debug Classpath, but I use a proprietary VM. Is it 
possible to use Classpath in a prorietary VM?"

The answer is:
"Classpath is supposed to replicate rt.jar functionnalities. Unfortunately, 
those functionnalities rely on VM internals. 
Open-sources VMs have public documentation, so it is easy to integrate 
Classpath with them. Proprietary VMs work in their own (secret) way, and 
Classpath's developpers do not know how to use these internal functionnalities. 
Therefore, it is quite impossible for open-source developpers to make Classpath 
interact with proprietary VMs."

Follow-up Comments
------------------


-------------------------------------------------------
Date: Wed 08/04/2004 at 21:06       By: patrik_reali
Added to the FAQ

-------------------------------------------------------
Date: Mon 08/02/2004 at 12:45       By: robilad
My proposed answer would be:

"Only the proprietary VM's vendor can make it work with GNU Classpath, by the 
nature of the VM being proprietary. GNU Classpath provides well documented and 
widely used interfaces for interfacing with runtimes. It's up to proprietary VM 
vendors to make their products work with GNU Classpath, if they wish to do so. 
If you, as a customer, want the runtime to use GNU Classpath, please talk to 
your proprietary software vendor.

You can also try using a free runtime that supports GNU Classpath 
out-of-the-box instead."

This answer doesn't talk about rt.jar and such specifics of some particular 
proprietary runtime. It's more positive in tone, saying that it's possible, but 
up to the proprietary software vendor. Finally, it also points people to the 
'real' thing, runtimes already supporting GNU Classpath.

-------------------------------------------------------
Date: Mon 08/02/2004 at 12:06       By: None
It's not up to GNU Classpath to work with runtimes, it's up to runtime 
implementors to make their runtimes work with GNU Classpath. GNU Classpath has 
well documented, though still evolving, interfaces, which make it very easy to 
make all sorts of runtimes work with GNU Classpath. In fact it is so easy, that 
we seen numerous runtimes that interface GNU Classpath with non-mainstream 
platforms, like Oberon, JNode, or .net. On a side note, GNU Classpath is used 
by at least one non-free runtime, Jamaica, so it is very much possible for a 
proprietary runtime vendor to make their runtime work with GNU Classpath, if 
they desire to do so.

People who want to run proprietary runtimes with GNU Classpath should submit a 
bug report to their proprietary runtime vendors. Then these vendors can get 
their best hackers on it and do it, if they wish to do so. GNU Classpath 
developers can't do that job for them, because the  nature of proprietary 
software is that only the vendor can make changes to it.

it's like saying 'Why don't you GNU/Linux developers make GNU/Linux work on 
Microsoft Windows so that I can use Visual C++ to hack on my GNU/Linux 
applications?' It does not make much sense.

It's up to the proprietary software vendors to make sure their proprietary 
systems interoperate with the free solutions, not the other way round. By the 
nature of free software, they are able to do it. By the nature of being 
proprietary, they are the only ones who are allowed to do it.

cheers,
dalibor topic












For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=9846>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/