Java Trial Support Coming In Linux Standard Base

LinuxScribe writes "Java isn't in the LSB — yet. It's been a hard target to hit: which version gets standardized? How will test suites work? But the new version of LSB will take the first steps towards Java inclusion in standardized Linux development by introducing trial support for the language."

Will this FINALLY mean...

[Anonymous Coward]

I can fucking run browser applets on 64-bit Linux?

So annoying... home is dual 32-bit so I can run TD Ameritrade with no problems---it flies.

Then at work which is quad-64 bit, in order to get any java applets to work I'd have to bastardize my browser down to 32-bit so nsplugin can launch them---and when OpenSuSE releases an update on YaST--it blows this setup away since it sees "aha, you're on 64-bit, buddy!"

Sun not supporting 64-bit applets in their runtime is a travesty. Fix it!

Re:Will this FINALLY mean...

[crow]

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695 [sun.com]

Really? It looks like Sun has been sitting on this bug for several years, and is finally doing something, but doesn't expect it until JRE 6u12.

The only 64-bit Java plugin that I can get to run is Iced Tea.

http://www.iced-tea.org/wiki/Main_Page [iced-tea.org]

Unfortunately, that doesn't work with the one site that I've found that still uses Java (the horrid ADP timesheet site that my company just outsourced to).

GPL!!!

[FranTaylor]

The only Java implementation released under the GPL is 1.6.

I think that's a pretty overwhelming reason.

Re:GNU java is not java

[Benanov]

Sun Java 1.6 was released under the GPL. GP is not talking about GNU Java.

Ther are no patent encumberances on Java

[FranTaylor]

Unlike mono.

Java is standard in ways that mono will never be.

"Anonymous Coward" is a really accurate description of your attitude.

Re:Every language is an emulator

[jlarocco]

For the virtual environment that it presents to the application developer.

What? That's simply not true. An emulator is a program that imitates a piece of hardware in order to execute programs originally intended to run on the hardware. Which is exactly what the Java VIRTUAL MACHINE (JVM) does.

Programming languages hide hardware details using abstraction, but they don't emulate anything.

Apparently you failed computer science.

I guess he's not the only one.

Re:Source

[J.Y.Kelly]

I believe it's slower because RPM has finer-grained package management (which is probably useless to most people). Someone can correct me on this, but I think RPM's dependencies are handled by file name, rather than by package name. The dependency checks tend to take longer, consequently.

Dependencies in rpm can either be on a package name or a file - the packager can choose which makes more sense.

The main thing which makes yum seem slower than apt is that by default yum checks the server for an updated package list each time it is run, whereas apt has separate update and upgrade steps. If you run yum with -C (to force it to run from cache), it's about the same speed as apt-get.

Re:Source

[Schraegstrichpunkt]

But seriously, I don't see that yum is inferior to apt.

Press Ctrl-C sometime.

Re:Source

[ivan256]

I'm laughing at the sheer incompetence the loudest mouthed RPM-bashers are exhibiting in this thread.

Now, who should we thank for attracting an audience of clueless amateurs into the Linux world?

People in glass houses... Etc, etc...

Apt is merely a tool. People misattributed the benefits of debian to the Apt tool, when the benefit was really in the repository. Apt "for RPMs" is basically useless without a unified repository. Or at least several repositories that are linked against the same libraries and share dependency hierarchies.

The benefits of DEB over RPM have nothing to do with the tool, either. They have to do with how the two formats handle configuration (Or in the case of RPM, how they *don't*).