Does any existing linux-java group working on porting the complete API
from SUN?
The question I have is always down to what standard can we counting on.
If you pick
out the "Good" API from SUN and will that still being too "Large" for us
to bite it off.
I have a couple different VMs, different v
Does any existing linux-java group working on porting the complete API
from SUN?
The question I have is always down to what standard can we counting on.
If you pick
out the "Good" API from SUN and will that still being too "Large" for us
to bite it off.
I have a couple different VMs, different
> 3. Netscape: The BIG MYSTERY. Why does 4.7x still ship with
> JRE 1.1?!! Who even controls NS nowadays, Time Warner/
> AOL? (Translate as -- who do we bug to get this fixed?)
> Does Sun have some influence with Netscape? If so, why
> do they permit 4.7x to at
David Jardine wrote:
>
> > 2. Drop all Sun-deprecated classes and methods; conform only to the
> >latest non-deprecated version of an API spec
>
> But wouldn't a lot of browsers out there be unable to handle
> some of the "newer" things?
Browsers have been stuck at JRE 1.1 for years. Time t
> 3. Netscape: The BIG MYSTERY. Why does 4.7x still ship with
> JRE 1.1?!! Who even controls NS nowadays, Time Warner/
> AOL? (Translate as -- who do we bug to get this fixed?)
> Does Sun have some influence with Netscape? If so, why
> do they permit 4.7x to a
David Jardine wrote:
>
> > 2. Drop all Sun-deprecated classes and methods; conform only to the
> >latest non-deprecated version of an API spec
>
> But wouldn't a lot of browsers out there be unable to handle
> some of the "newer" things?
Browsers have been stuck at JRE 1.1 for years. Time
On Mon, May 13, 2002 at 09:21:00AM -0500, Rick Lutowski wrote:
> 2. Drop all Sun-deprecated classes and methods; conform only to the
>latest non-deprecated version of an API spec
But wouldn't a lot of browsers out there be unable to handle
some of the "newer" things?
David
--
To UNSUBSCR
On Mon, May 13, 2002 at 09:21:00AM -0500, Rick Lutowski wrote:
> 2. Drop all Sun-deprecated classes and methods; conform only to the
>latest non-deprecated version of an API spec
But wouldn't a lot of browsers out there be unable to handle
some of the "newer" things?
David
--
To UNSUBSC
Jim Pick wrote:
>
> Because the set of Java APIs is so large, trying to develop a set of
> class libraries that works as a drop in replacement for Sun's libraries
> is a very large task. In reality, it's going to be a long time before
> the free java class library projects manage to reimplement 1
On Sun, May 12, 2002 at 09:15:31PM -0700, Jim Pick wrote:
> I think the Debian Java policy, as currently stated, is slightly flawed,
> as it tries to satisfy two goals that aren't completely orthogonal:
>
> 1) To get as much free Java software into Debian as possible, that runs
> without non-
Jim Pick wrote:
>
> Because the set of Java APIs is so large, trying to develop a set of
> class libraries that works as a drop in replacement for Sun's libraries
> is a very large task. In reality, it's going to be a long time before
> the free java class library projects manage to reimplement
On Sun, May 12, 2002 at 09:15:31PM -0700, Jim Pick wrote:
> I think the Debian Java policy, as currently stated, is slightly flawed,
> as it tries to satisfy two goals that aren't completely orthogonal:
>
> 1) To get as much free Java software into Debian as possible, that runs
> without non
I think the Debian Java policy, as currently stated, is slightly flawed,
as it tries to satisfy two goals that aren't completely orthogonal:
1) To get as much free Java software into Debian as possible, that runs
without non-free software (eg. without Sun's JDK)
2) To put together a distrib
I think the Debian Java policy, as currently stated, is slightly flawed,
as it tries to satisfy two goals that aren't completely orthogonal:
1) To get as much free Java software into Debian as possible, that runs
without non-free software (eg. without Sun's JDK)
2) To put together a distri
14 matches
Mail list logo
