Another anti-Java FUD piece going the rounds on Twitter
Fernando Cassia
"Oracle’s Java runtime software is required to run Java applets on
websites and desktop software written in the Java programming
language. When you install Java, there are a few things you should
consider, especially regarding security. Java is used by an
ever-decreasing number of websites and is a frequent target of
attacks.
Most people could remove Java and not notice a difference."
(...)
"Do you use a specific website or program that requires Java? If not,
you don’t actually need it installed. Java just allows you to run
software written in Java, and you may be surprised by how few websites
and programs actually require Java.
If you’re not sure whether you need Java, try going without it for a
while. You may not notice the difference. As we’ll detail later, there
are good reasons not to have Java installed — if you can help it. Even
LibreOffice (formerly OpenOffice.org), doesn’t require Java for most
of its functionality."
What's missing is "This message is brought to you courtesy of
Microsoft and its associates. Tirelessly working against Java since
1997. It's for your own good. Visit http://ho.io/sunblock".
;-)
I wrote a nasty comment but I don't think he'll publish it. In the
meantime I pasted it into pastebin
http://pastebin.com/NuvqLWBW
FC
--
During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un
Acto Revolucionario
- George Orwell
Fabrizio Giudici
wrote:
> I wrote a nasty comment but I don't think he'll publish it. In the
> meantime I pasted it into pastebin
> http://pastebin.com/NuvqLWBW
Well, the truth is in the middle. The second part of your comment doesn't
hold as a valid objection, since you're mentioning the fact that Java is
being used to develop software. This is very true, but the OP was talking
about the _end user_'s perspective of Java, and honestly there's not _a
lot_ of thing. The first part of your comment is very good, because it
demonstrates that while there's not _a lot_ of Java in the end user's
perspective, is not that almost-zero level that many repeat. For the
record, a few days ago I subscribed to blurb.com, a service used to
publish printed books e.g. out of a PDF file, and the file uploader +
pre-verifier is, figure out, an applet (but there's a Flash alternative).
In the end, from the user perspective it's sadly true that Java is less
relevant. Unfortunately, stupid behaviours such as Apple posting so in
late a patch to a security flaw that was ready months earlier (at least
this is how I understood flashback's history) are just growing the
perception that Java is less and less useful and more and more dangerous.
In any case, this doesn't change a lot in my point of view. Desktop
applications can be distributed by embedding a Java runtime, so they are
not impaired by the fact that the user disables Java.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it
Josh Berry
<Fabrizio...@tidalwave.it> wrote:
> In any case, this doesn't change a lot in my point of view. Desktop
> applications can be distributed by embedding a Java runtime, so they are not
> impaired by the fact that the user disables Java.
I'm curious about the security implications of this practice. Seems
like this can make a bad problem worse.
Fernando Cassia
<Fabrizio...@tidalwave.it> wrote:
> In any case, this doesn't change a lot in my point of view. Desktop
> applications can be distributed by embedding a Java runtime, so they are not
> impaired by the fact that the user disables Java.
Embedding the Java runtime with each app dates back to the days when
Java as a platform was very buggy, and devs had to make sure the user
had 1.xsomething and not 1.xsomething-1 JRE installed.
It's a very very bad practive and I raise hell to any developer I see
embedding the JRE with his app.
Not to mention that uninstalling Java from systems renders Java Web
Start useless.
I think JWS is one of Java's hidden gems and should be promoted more, not less.
Fernando Cassia
> software. This is very true, but the OP was talking about the _end user_'s
> perspective
You're saying that because I mentioned jEdit and Netbeans in my list
of apps?. Remove those then. There's 15+ other flagship Java apps in
my list, and all are end-user related, not development tools.
FC
Fernando Cassia
> You're saying that because I mentioned jEdit and Netbeans in my list
> of apps?. Remove those then. There's 15+ other flagship Java apps in
> my list, and all are end-user related, not development tools.
Oh, and I forgot Jitsi... the FOSS skype killer... also a Java app...
http://jitsi.org/
FC
--
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell
Fabrizio Giudici
wrote:
> On Thu, Apr 12, 2012 at 12:42, Fabrizio Giudici
Do you have the figures of the spread of any of those applications?
Because I really don't see the typical end user (my parents, or my
nephews/nieces who aren't interested in programming) aware of most of them
(indeed, you could rather include Cyberduck which is a bit more popular).
I repeat: your list is a valid point that the end-user Java applications
are not *zero*, as many say, but unfortunately the real spread is not much
higher.
For what concerns embedding a JRE, I share many doubts with you (and yes,
Josh, it's a potential security issue all the way, even more complex, but
I understand that from a o.s. manufacturer point of view it's very
different to see people advicing "remove Java from Mac OS X because it's
dangerous", and then people blame Apple, rather than e.g. "remove
Cyberduck because it's dangerous", and then people blame the application
author), but as a matter of fact the JRE is no more in Windows since a
long time and if you want to distribute your stuff through the Apple Store
(which will become the most relevant software source for Mac end users)
you are *forced* to embed a JRE as per Apple's rules. Linux is 1% of
desktops, so it's clearly not relevant for end users.
Fabrizio Giudici
wrote:
> Embedding the Java runtime with each app dates back to the days when
> Java as a platform was very buggy, and devs had to make sure the user
> had 1.xsomething and not 1.xsomething-1 JRE installed.
And I have to add that this is still a potential problem and not really
related to "Java being very buggy" (if not in a probabilistic way). We
have already discussed here about applications that broke in the past
because of a system Java update of a *minor* version of Java.
phil swenson
disappeared from their machines.
In the real world, java is a server technology. Almost all UI use is
for tools/IDEs. On my box for example, the only Java UIs I use are
IDEs (Intellij/Eclipse/RubyMine/AppCode) and DB Visualizer.
> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
>
Mark Derricutt
future. Discussions are afoot on the Mac OSX port list for just this, as
well as the system JDK install, there'll be a way for applications to
bundle their own JDK. Which will be the preferred way. This will,
AFAIK allow OSX to sandbox an application completely - and also make it
available in the app store.
Mark Derricutt
The big "end user" app for me? Crashplan backups.
Fabrizio Giudici
> And welcome to how Java apps on OSX will be distributed in the near
> future. Discussions are afoot on the Mac OSX port list for just this, as
> well as the system JDK install, there'll be a way for applications to
> bundle their own JDK. Which will be the preferred way. This will,
> AFAIK allow OSX to sandbox an application completely - and also make it
> available in the app store.
In any case Apple just released another Java update that automatically
disables applet from being executed:
"This Java security update removes the most common variants of the
Flashback malware," Apple wrote in the support document for the update.
"This update also configures the Java web plug-in to disable the automatic
execution of Java applets. Users may re-enable automatic execution of Java
applets using the Java Preferences application. If the Java web plug-in
detects that no applets have been run for an extended period of time it
will again disable Java applets."
I suppose this will make a small-but-not-zero number of Java developers
angry.
Casper Bang
Fact 1: Very few end-users actually need a JRE to be installed. I
investigated this aspect for myself some years ago and came to the
conclusion that less than 1% (probably even less today) of websites
make use of Java as a client technology:
http://blog.bangbits.com/2008/08/myth-java-widely-used-on-web.html
Fact 2: The JRE is notorious for being a common attack vector for
malware, due to it's pervasive nature and relatively bad update
history (remember not all users have CS degrees). This vector has been
a concern by security analysts and tracked by the media for the last
couple of years:
http://www.darkreading.com/vulnerability-management/167901026/security/attacks-breaches/232200604/the-dark-side-of-java.html
/Casper
On Apr 12, 11:12 am, Fernando Cassia <fcas...@gmail.com> wrote:
> http://www.makeuseof.com/tag/top-6-install-java-software/
>
> "Oracle’s Java runtime software is required to run Java applets on
> websites and desktop software written in the Java programming
> language. When you install Java, there are a few things you should
> consider, especially regarding security. Java is used by an
> ever-decreasing number of websites and is a frequent target of
> attacks.
>
> Most people could remove Java and not notice a difference."
> (...)
> "Do you use a specific website or program that requires Java? If not,
> you don’t actually need it installed. Java just allows you to run
> software written in Java, and you may be surprised by how few websites
> and programs actually require Java.
>
> If you’re not sure whether you need Java, try going without it for a
> while. You may not notice the difference. As we’ll detail later, there
> are good reasons not to have Java installed — if you can help it. Even
> LibreOffice (formerly OpenOffice.org), doesn’t require Java for most
> of its functionality."
>
> What's missing is "This message is brought to you courtesy of
> Microsoft and its associates. Tirelessly working against Java since
> ;-)
>
> I wrote a nasty comment but I don't think he'll publish it. In the
vjosullivan
> On Thu, Apr 12, 2012 at 12:42, Fabrizio Giudici
>
> > since you're mentioning the fact that Java is being used to develop
> > software. This is very true, but the OP was talking about the _end user_'s
> > perspective
>
> You're saying that because I mentioned jEdit and Netbeans in my list
> of apps?. Remove those then. There's 15+ other flagship Java apps in
> my list, and all are end-user related, not development tools.
saying and, to a lesser extent, the original article. If those are
Java's flagship applications then Java, in the client environment, is
of little more than academic interest and most application end users
wouldn't notice if it wasn't there.
Despite being a Java application developer for more than a dozen
years, I can't say that I've heard of more than a couple of the
applications that you've listed and, personally, don't use any of
them.
I'll perform the Litmus Test, this weekend. Both of my teenage kids
have laptops which they use daily. Neither has any interest in
software development. I'm going to disable (with their consent) the
JREs on both machines and see if they notice. I'll report back next
week.
Mark Derricutt
THE F&***&****N web.
Crashplan runs java on the client, and backups are darn well important.
Remove java - and bang, there goes your backups.
I like my backups.
Casper Bang
I keep wanting to resist saying this but enough - the internet is NOT
THE F&***&****N web.
Crashplan runs java on the client, and backups are darn well important.
Remove java - and bang, there goes your backups.
I like my backups.
clay
Josh Berry
> Moving to a JRE as an embeddable library solves the security issue, solves
> the update nagging issues that users complain about, and solves user
> compliance issues of not choosing to install Java or not having a recent
> version of the JRE.
It only "solves" it by moving the issue to these applications. If
users do not update client applications that bundle a VM, then it
isn't like these problems just didn't happen.
Fabrizio Giudici
> It only "solves" it by moving the issue to these applications.
Yes, but this is the core of the point. You have security concerns on a
system just because it run software and whenever you download and install
something, you're increasing the risk anyway. Now, if a software app
called FooBar, embedding a JRE, is found to be a trojan, or exposing a
security issue, people will balme FooBar. After all, it't better for
Apple, it's better for Oracle and it's better of developers using Java and
producing safe applications.
Phil
>
> I'll perform the Litmus Test, this weekend. Both of my teenage kids
> have laptops which they use daily. Neither has any interest in
> software development. I'm going to disable (with their consent) the
> JREs on both machines and see if they notice. I'll report back next
> week.
pretty damn quickly.
Possibly the highest profile java application for the non tech
computer user, my kids are never off it and I know a few adults
(again, not working in tech) who play regularly.
Requires JRE 6+. Just thought I'd drop that into the discussion.
Simon Ochsenreither
Oh, the bitter irony.
Cédric Beust ♔
--
With other words: Keeping Notch programming is more relevant to Java's market share than pouring millions of dollars into JavaFX.
Oh, the bitter irony.
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/--h1m16RigkJ.
clay
clay
Ricky Clarkson
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/IpucLvTbUn8J.
vjosullivan
> > I'll perform the Litmus Test, this weekend. Both of my teenage kids
> > have laptops which they use daily. Neither has any interest in
> > software development. I'm going to disable (with their consent) the
> > JREs on both machines and see if they notice. I'll report back next
> > week.
>
> If either of them play minecraft, you'll be turning the JRE back on
> pretty damn quickly.
...the sun was shining all weekend and I never gave doing anything
with computers any thought. I will do it, though. Soon.
jwd
Possibly the best supported alternative to Quicken that Mac users interested in managing their personal finances eventually find (and who don't want their financial details out on the web ala Mint.) The Moneydance discussion boards lit up when Apple first announced they were ditching Java. (Also runs on other platforms supporting Java like Linxi and Windows, which is of course the whole point.)
Phil
Java for their live timing application. They originally dud this
primarily, I think, because it made it difficult to harvest the data.
However I'm now seeing alternative Live Timing applications in the
Google Play app store where people have reverse engineered the data
stream.
On Apr 18, 4:13 pm, jwd <jwd...@gmail.com> wrote:
> Yet another very popular end user application written in Java - MoneyDance
Fabrizio Giudici
wrote:
> As a big F1 fan I should have dropped this one in sooner - F1.com uses
> Java for their live timing application. They originally dud this
> primarily, I think, because it made it difficult to harvest the data.
be cracked by 1,000,000 of teenagers; in any case anything like that even
in Java is crackable by probably tens of thousands of teenagers. The end
result is that somebody cracks it anyway, so I wouldn't waste time picking
a technology only because a just smaller crowd can hack it.
Unfortunately I was involved with F1 only a couple of years ago when Java
was starting to make its way into telemetry and I don't know anything
since 2007 - and I admit I've never looked at the recent F1.com live
timing application and didn't think that it could be Java - but I suppose
this environment is one of those where Java delivers a better solution
even on the client.
BTW, LOL: https://discussions.apple.com/thread/2796553?start=0&tstart=0
> However I'm now seeing alternative Live Timing applications in the
> Google Play app store where people have reverse engineered the data
> stream.
Phil
my Mac, even with Lion.
The flip side of course is that it doesn't work on Android, and Bernie
god bless his gold-plated cotton socks discontinued the free live
timing app this year to allow SoftPauer, who presumably are paying a
hefty premium, to be the sole official provider of live timing on all
mobile platforms. Unfortunate then that they try to charge £20 for a
season... their free app has hugely negative feedback because it isn't
as much a free app as an advert for the paid app, and we don't like
the price.
I'd kill to do some work in F1. I've heard McLaren use Java a fair
bit, and I came close to getting involved in ECU programming relating
to the development of prototypes for the 2014 engines a year or so
back, but that particular fish got away, more's the pity.
On Apr 22, 4:32 pm, "Fabrizio Giudici" <Fabrizio.Giud...@tidalwave.it>
wrote:
> On Sun, 22 Apr 2012 15:54:03 +0200, Phil <p...@surfsoftconsulting.com>
Fabrizio Giudici
wrote:
> I've never had any problem getting the live timing applet to work on
> my Mac, even with Lion.
>
> The flip side of course is that it doesn't work on Android, and Bernie
> god bless his gold-plated cotton socks discontinued the free live
> timing app this year to allow SoftPauer, who presumably are paying a
> hefty premium, to be the sole official provider of live timing on all
> mobile platforms. Unfortunate then that they try to charge £20 for a
> season... their free app has hugely negative feedback because it isn't
> as much a free app as an advert for the paid app, and we don't like
> the price.
>
> I'd kill to do some work in F1. I've heard McLaren use Java a fair
> bit, and I came close to getting involved in ECU programming relating
> to the development of prototypes for the 2014 engines a year or so
> back, but that particular fish got away, more's the pity.
At the time I was referring I think we (Sun and Magneti Marelli)
introduced I think what was the first middleware for delivering telemetry
data in pure Java. Then came the rules about the single provider for
electronics and Mc Laren (if I recall correctly) started providing its own
systems to everybody. Is there any public information about current use of
Java (e.g. McLaren you referred) in F1? I'm not a F1 follower, but I'd
like to know how things have evolved. You know, in these years at
discussions about Java performance I'm extensively using the reference to
that project to shut up the casual "Java is slow" guy... :-) but I'd like
to have something more recent to cite.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
Casper Bang
At the time I was referring I think we (Sun and Magneti Marelli)
introduced I think what was the first middleware for delivering telemetry
data in pure Java. Then came the rules about the single provider for
electronics and Mc Laren (if I recall correctly) started providing its own
systems to everybody. Is there any public information about current use of
Java (e.g. McLaren you referred) in F1? I'm not a F1 follower, but I'd
like to know how things have evolved. You know, in these years at
discussions about Java performance I'm extensively using the reference to
that project to shut up the casual "Java is slow" guy... :-) but I'd like
to have something more recent to cite.
Fabrizio Giudici
wrote:
> I am just curious; how do people get the live telemetry into Java in the
> first place?! The RS-232 and USB support is third party and sucks
> butterballs. Which is why, when I wanted to extract live consumption from
> my electricity-, heat- and water meters, I went straight to .NET (the
> Mono
> impl) and its System.IO.Ports namespace.
were confidential - and I don't recall what was disclosable ;-). In any
case, surely I can say that at the time there was a proprietary chain
including digital radios feeding data from the car up to a device that
exposed an ethernet interface. We delivered data to clients by using a
small Java process running in background, that was queried by existing
desktop applications. With a custom protocol you could retrieve data. I
suppose thing haven't changed a lot since ethernet is still very fast, but
I bet the amount of exchanged data has increased a lot. For the record we
didn't use JMS, but plain multicast sockets (for non guaranteed delivery,
which in any case was hardly missing a few packets in a while) and a
customization of JGroups for guaranteed delivery. I suppose today people
could happily use a JMS based product.
PS Since I'm also interested in my consumption, how do your thing work?
What kind of device does the provider expose?
Casper Bang
A lot of years passed, still I must be careful not to reveal details that
were confidential - and I don't recall what was disclosable ;-). In any
case, surely I can say that at the time there was a proprietary chain
including digital radios feeding data from the car up to a device that
exposed an ethernet interface.
We delivered data to clients by using a
small Java process running in background, that was queried by existing
desktop applications. With a custom protocol you could retrieve data. I
suppose thing haven't changed a lot since ethernet is still very fast, but
I bet the amount of exchanged data has increased a lot.
PS Since I'm also interested in my consumption, how do your thing work?
What kind of device does the provider expose?
Fabrizio Giudici
wrote:
> And yet, I would think F1 people, eager to cut even a couple of ms off a
> time, would prefer native. I know that the various super-computers at
about Java being able to fulfill the job and we had the pleasure of
surprising them. We did it nicely and easily from the performance point of
view. The only important thing was object pooling (it was Java 1.4). We
never had to perform specific optimizations - I don't remember the exact
numbers, but something like 95%+ (precisely, it was near real time, not
pure real time) of data being delivered within I believe 0.1 sec. People
were worried about the impact of endpoints running in clients (data
analysis tools were and I suppose still are pretty CPU intensive and they
didn't want to suck CPU from them), but Java was running well below 10%.
Probably with some optimizations we could do more, but today with Java 6
it would be extremely faster without much hassle (and of course I would
get rid of the object pooling). The GC pauses were never a problem for
runs of a few hours (the system couldn't be absolutely stopped for two
hours, the typical race duration, but even during tests, which AFAIK last
all the day long, at least as far as there's sunlight, it was considered
an annoyance the need of a restart).
We had a very serious bug during the final tests that could have been a
showstopper, but it was due to an explosion of the number of sockets in
certain rare circumstances - nothing related to CPU or memory problems.
> Sadly, the utility provider does not expose anything and is really only
> interested in the billing aspect. I have installed a secondary
> electricity
> meter (3-phased Kamstrup 382), while the utility provider installed water
> and heat (hot water) meters (Kamstrup 61 and 610). Almost all modern
> meters
> have an optical interface (used for on-site installation, troubleshooting
> etc.). I build a simple RS-232 (though I access it over USB adaptor) IR
> circuit and started
> probing:
> https://fbcdn-sphotos-a.akamaihd.net/hphotos-ak-ash4/419319_3274289293197_1146362123_33320716_52584424_n.jpg
>
> The trick then is to figure out the right connection (parity, stop-bits,
> data-bits, handshaking, speed) and of course, the actual protocol itself
> (the hard part). By analyzing traffic dumps between the public available
> support application and the meter, it is possible to infer the
> interesting
> commands. I'm not there yet, but have plans to share everything when
> ready.
> It's a little off-topic for this forum, but if you'd like to know more,
> you
> are welcome to drop me a mail. :)
whether that product or a similar one is available on the market here.
Casper Bang
On Tuesday, April 24, 2012 9:26:14 PM UTC+2, fabrizio.giudici wrote:
Thanks for the info. Sure I'll do, in the meantime I'm going to see
whether that product or a similar one is available on the market here.