SimonH
JGO Strike Force  Posts: 896 Medals: 14
|
 |
«
Reply #60 on:
2010-04-18 11:07:10 » |
|
I got the same popup - seems it's an automatic security update for FF. As far as I can tell it doesn't break anything to have the JDT blocked, but I'm worried that users will think that all java has been blocked!
|
|
|
|
jojoh
JGO Ninja Posts: 554 Medals: 6
games4j.com
|
|
«
Reply #61 on:
2010-04-18 20:22:43 » |
|
But I doubt the average user would use the JDK, as long as the popup doesnt also apply for the JRE.
I don't think the java plugin is different depending on if a JDK is installed, so I would assume that this pop-up is not specific for dev nerds. I think that having the JDT blocked won't be a problem until Java 7 is out, but I think that this will help fuel "Java is dangerous voodoo" among average users. From the link: The Java Deployment Toolkit takes the guess work out of determining what versions of the Java Platform end users have installed on their PCs. It supplies Java based web applet/application deployers with a simple JavaScript interface. This greatly increases the ease of detections of users' Java environment, as well as the ease of Java Platform deployment. |
|
|
|
Momoko_Fan
Full Member Posts: 101 Medals: 3
|
|
«
Reply #62 on:
2010-04-19 02:33:20 » |
|
If you installed the u19 version it would show this. But most users I think would install the u20 one and wouldn't see it. Since lwjgl 2.4.2 was released I can't notice the difference between u20 and the others, it just shows the "confirm official certificate" dialolg as usual and then works fine, even with unsigned code and all. Some other applets/webstart on other sites that still use the old lwjgl will show the "block dangerous components" though  People should upgrade to 2.4.2 ASAP. |
|
|
|
|
Games published by our own members! Go get 'em! 
|
|
kappa
« League of Dukes » JGO Kernel  Posts: 2360 Medals: 59
★★★★★
|
|
«
Reply #63 on:
2010-04-21 09:12:09 » |
|
its official, mozilla is blocking all versions of the java plugin prior to Java 6u20. http://www.theregister.co.uk/2010/04/21/mozilla_blocks_java_plug_in/IMO it maybe bad for the overall java market share as people are likely to uninstall java altogether rather then update but also good to see what remains of the crappy java plugin1 being killed off by firefox. Java plugin1 will now no longer work in Firefox (already didn't work in chrome and new releases of opera). In the long term it should help java applets as the user experience is actually pretty good for java plugin2. Lets just hope Oracle don't do anymore major blunders with the plugin and continue working to improving it. |
|
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5871 Medals: 255
Hand over your head.
|
|
«
Reply #64 on:
2010-04-21 09:25:29 » |
|
its official, mozilla is blocking all versions of the java plugin prior to Java 6u20. http://www.theregister.co.uk/2010/04/21/mozilla_blocks_java_plug_in/IMO it maybe bad for the overall java market share as people are likely to uninstall java altogether rather then update but also good to see what remains of the crappy java plugin1 being killed off by firefox. Java plugin1 will now no longer work in Firefox (already didn't work in chrome and new releases of opera). In the long term it should help java applets as the user experience is actually pretty good for java plugin2. Lets just hope Oracle don't do anymore major blunders with the plugin and continue working to improving it. IMHO, both in the short and long term, this hurts Java. These security problems tend to be remembered for years, no matter how safe Java is right now. |
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
kappa
« League of Dukes » JGO Kernel Posts: 2360 Medals: 59
★★★★★
|
|
«
Reply #65 on:
2010-04-21 09:41:20 » |
|
IMHO, both in the short and long term, this hurts Java.
These security problems tend to be remembered for years, no matter how safe Java is right now.
Well its reputation can't get any worse then it is now right?  Apart from a massive chunk of java plugin installs now just silently no longer working on firefox, it can only get better right? This news was most likely only picked up by people who read tech sites and have an interest (or hatred ) for Java. People tend to have short memories and should forget in a few months (hopefully). Just look at how many vulnerabilities Flash has had (wonder why mozilla hasn't blocked those versions of the flash plugin?) |
|
|
|
|
|
DzzD
|
|
«
Reply #66 on:
2010-04-21 11:01:09 » |
|
I dont really like the idea of blocked plugins, those plugins have to be installed by the user so it sound really strange for me to block them, it shoud be to the responsability of the plugins vendors not mozilla...
|
|
|
|
Momoko_Fan
Full Member Posts: 101 Medals: 3
|
|
«
Reply #67 on:
2010-04-21 12:55:29 » |
|
Why do they block it like that though? I mean can't they just force you to update to u20, rather than showing all that security blocking thing?
|
|
|
|
|
trembovetski
JGO Strike Force Posts: 926
If only I knew what I'm talking about!
|
|
«
Reply #68 on:
2010-04-21 12:55:47 » |
|
its official, mozilla is blocking all versions of the java plugin prior to Java 6u20. http://www.theregister.co.uk/2010/04/21/mozilla_blocks_java_plug_in/IMO it maybe bad for the overall java market share as people are likely to uninstall java altogether rather then update but also good to see what remains of the crappy java plugin1 being killed off by firefox. Java plugin1 will now no longer work in Firefox (already didn't work in chrome and new releases of opera). In the long term it should help java applets as the user experience is actually pretty good for java plugin2. Lets just hope Oracle don't do anymore major blunders with the plugin and continue working to improving it. From what I can see FF only blocks the deployment toolkit, not the java plugin. Dmitri |
|
|
|
|
kappa
« League of Dukes » JGO Kernel Posts: 2360 Medals: 59
★★★★★
|
|
«
Reply #69 on:
2010-04-21 14:08:23 » |
|
From what I can see FF only blocks the deployment toolkit, not the java plugin.
Dmitri
ah, thx for clearing that up. What is Java Deployment Toolkit?
Since Java SE 6 Update 10, we have introduced new JavaScript functions for developers to easily detect users' Java environment and deploy their Java Applet and Java Web Start applications. The Java Deployment Toolkit includes:
Accurate detection of installed JREs
Seamless JRE installation
Complete applet launching (JRE detection and, if necessary, upgrading) in a single line of code
Complete Web Start program launching in a single line of code so guess it'll just break functionality without actually disabling the applet plugin. |
|
|
|
|
Games published by our own members! Go get 'em! 
|
|
trembovetski
JGO Strike Force Posts: 926
If only I knew what I'm talking about!
|
|
«
Reply #70 on:
2010-04-21 18:09:14 » |
|
ah, thx for clearing that up.
so guess it'll just break functionality without actually disabling the applet plugin.
Even that's not clear. Deployment toolkit is just a bunch of javascript code served from Oracle's website - the "plugin" isn't really needed for that. From what I recall the plugin just provides better jvm detection and stuff like that. The deployment toolkit should be able to function w/o the plugin. Dmitri |
|
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5871 Medals: 255
Hand over your head.
|
|
«
Reply #71 on:
2010-04-21 18:19:08 » |
|
Even that's not clear. Deployment toolkit is just a bunch of javascript code served from Oracle's website - the "plugin" isn't really needed for that. From what I recall the plugin just provides better jvm detection and stuff like that. The deployment toolkit should be able to function w/o the plugin.
Dmitri
How can a 'bunch of javascript code' served from Oracles site be considered a security hazard? That has absolutely nothing to do with the security holes in the plugin. |
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
jojoh
JGO Ninja Posts: 554 Medals: 6
games4j.com
|
|
«
Reply #72 on:
2010-04-21 22:32:01 » |
|
Yes, I would also think it is a little bit more than just a bunch of javascript, but I could be wrong. It could be that this name is used for more than one thing? The only useful link I found was this: http://www.kb.cert.org/vuls/id/886582 (Mentioning ActiveX and dll) Not even the Update Release Notes for 6u20 seemed to mention anything useful, which is a bit strange. |
|
|
|
endolf
« League of Dukes » JGO Kernel Posts: 1597 Medals: 2
Current project release date: sometime in 3003
|
|
«
Reply #73 on:
2010-04-22 01:59:55 » |
|
Reading the article on elreg, and the linked sites, it only blocks versions before u20, and if users click on the 'explain' link, it tells them so.
Most users won't read anything though.
Endolf
|
|
|
|
trembovetski
JGO Strike Force Posts: 926
If only I knew what I'm talking about!
|
|
«
Reply #74 on:
2010-04-22 13:09:44 » |
|
You could read this for yourself: here's the deployment toolkit's javascript file (in human readable form): http://www.java.com/js/deployJava.txtSee the references to the deployment toolkit plugin? Like this one: 1
2
3
4
5
6
7
8
9
10
11
12
| getJREs: function() {
var list = new Array();
if (deployJava.isPluginInstalled()) {
var plugin = deployJava.getPlugin();
var VMs = plugin.jvms;
for (var i = 0; i < VMs.getLength(); i++) {
list[i] = VMs.get(i).version;
}
} else {
var browser = deployJava.getBrowser();
if (browser == 'MSIE') { |
There's a bunch of other code which attempts to use the DT plugin first (for updating java and so forth), and if it's not available, works around it. |
|
|
|
|
trembovetski
JGO Strike Force Posts: 926
If only I knew what I'm talking about!
|
|
«
Reply #75 on:
2010-04-22 13:10:59 » |
|
Reading the article on elreg, and the linked sites, it only blocks versions before u20, and if users click on the 'explain' link, it tells them so.
Most users won't read anything though.
Endolf
Again, disabling the deployment toolkit plugin won't prevent them from running java applets. Unless they freak out and uninstall java completely (always possible). |
|
|
|
|
endolf
« League of Dukes » JGO Kernel Posts: 1597 Medals: 2
Current project release date: sometime in 3003
|
|
«
Reply #76 on:
2010-04-22 13:14:47 » |
|
Again, disabling the deployment toolkit plugin won't prevent them from running java applets. Unless they freak out and uninstall java completely (always possible).
I was just pointing out that the latest version of java have any components blocked. Eventually the problem solves itself Endolf |
|
|
|
pjt33
JGO Strike Force Posts: 914 Medals: 17
|
|
«
Reply #77 on:
2010-04-22 13:22:54 » |
|
Reading the article on elreg, and the linked sites, it only blocks versions before u20, and if users click on the 'explain' link, it tells them so.
I'm sure that when I clicked on the "explain" link it said <= u20. It didn't however, block u20 (or, come to that, u17, although it did block u16). |
|
|
|
|
Matzon
« League of Dukes » JGO Kernel Posts: 1805 Medals: 8
I'm gonna wring your pants!
|
|
«
Reply #78 on:
2010-04-26 17:57:15 » |
|
1
| Thread.currentThread().getContextClassLoader().getResource() |
Should work if they've implemented it as expected. There should be a delegating class loader across all the resource/code JARs that can be used to see all of them. In a JEE world you'd expect to see this classloader being passed around on the thread. works, however world + dog is using the "old" method - so they broke a shitload of stuff I think |
|
|
|
endolf
« League of Dukes » JGO Kernel Posts: 1597 Medals: 2
Current project release date: sometime in 3003
|
|
«
Reply #79 on:
2010-04-26 18:38:57 » |
|
On the other hand, it's been known for quite some time that you should use the context class loader. It's even in Kev's webstart guide (getting your resources), and thats ancient |
|
|
|
Matzon
« League of Dukes » JGO Kernel Posts: 1805 Medals: 8
I'm gonna wring your pants!
|
|
«
Reply #80 on:
2010-04-27 04:33:58 » |
|
this article goes a bit in-depth about the topic: http://www.javaworld.com/javaworld/javaqa/2003-06/01-qa-0606-load.htmlbut it doesn't make it THAT clear which to use am I correct in generalizing it into: if the resource is not in the same jar as the class - then use the context loader? - else use the classloader directly or should one just always use the context ? |
|
|
|
endolf
« League of Dukes » JGO Kernel Posts: 1597 Medals: 2
Current project release date: sometime in 3003
|
|
«
Reply #81 on:
2010-04-27 04:47:24 » |
|
I just always use the context one, whether that's correct or not I don't know, but it always seems to work Endolf |
|
|
|
|
